2016-03-16 20:06:00 +03:00
|
|
|
/*
|
2016-09-22 20:13:05 +03:00
|
|
|
* ASPEED SoC family
|
2016-03-16 20:06:00 +03:00
|
|
|
*
|
|
|
|
|
* Andrew Jeffery <andrew@aj.id.au>
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2016 IBM Corp.
|
|
|
|
|
*
|
|
|
|
|
* This code is licensed under the GPL version 2 or later. See
|
|
|
|
|
* the COPYING file in the top-level directory.
|
|
|
|
|
*/
|
|
|
|
|
|
2016-09-22 20:13:05 +03:00
|
|
|
#ifndef ASPEED_SOC_H
|
|
|
|
|
#define ASPEED_SOC_H
|
2016-03-16 20:06:00 +03:00
|
|
|
|
2019-09-25 17:32:43 +03:00
|
|
|
#include "hw/cpu/a15mpcore.h"
|
2022-05-02 18:03:03 +03:00
|
|
|
#include "hw/arm/armv7m.h"
|
2016-03-16 20:06:00 +03:00
|
|
|
#include "hw/intc/aspeed_vic.h"
|
2024-06-04 08:44:34 +03:00
|
|
|
#include "hw/intc/aspeed_intc.h"
|
2016-06-27 17:37:33 +03:00
|
|
|
#include "hw/misc/aspeed_scu.h"
|
2021-10-12 09:20:08 +03:00
|
|
|
#include "hw/adc/aspeed_adc.h"
|
2016-09-06 21:52:17 +03:00
|
|
|
#include "hw/misc/aspeed_sdmc.h"
|
2019-07-01 19:26:18 +03:00
|
|
|
#include "hw/misc/aspeed_xdma.h"
|
2016-03-16 20:06:00 +03:00
|
|
|
#include "hw/timer/aspeed_timer.h"
|
2019-10-04 02:04:01 +03:00
|
|
|
#include "hw/rtc/aspeed_rtc.h"
|
2016-06-06 18:59:29 +03:00
|
|
|
#include "hw/i2c/aspeed_i2c.h"
|
2022-01-11 11:45:46 +03:00
|
|
|
#include "hw/misc/aspeed_i3c.h"
|
2016-07-04 15:06:37 +03:00
|
|
|
#include "hw/ssi/aspeed_smc.h"
|
2021-05-01 11:03:51 +03:00
|
|
|
#include "hw/misc/aspeed_hace.h"
|
2022-02-18 11:18:10 +03:00
|
|
|
#include "hw/misc/aspeed_sbc.h"
|
2024-06-04 08:44:34 +03:00
|
|
|
#include "hw/misc/aspeed_sli.h"
|
2017-02-07 21:29:59 +03:00
|
|
|
#include "hw/watchdog/wdt_aspeed.h"
|
2017-04-14 11:35:02 +03:00
|
|
|
#include "hw/net/ftgmac100.h"
|
2019-08-12 08:23:31 +03:00
|
|
|
#include "target/arm/cpu.h"
|
2019-09-04 10:04:58 +03:00
|
|
|
#include "hw/gpio/aspeed_gpio.h"
|
2019-09-25 17:32:27 +03:00
|
|
|
#include "hw/sd/aspeed_sdhci.h"
|
2020-02-06 21:34:37 +03:00
|
|
|
#include "hw/usb/hcd-ehci.h"
|
2020-09-03 23:43:22 +03:00
|
|
|
#include "qom/object.h"
|
2021-03-09 14:01:28 +03:00
|
|
|
#include "hw/misc/aspeed_lpc.h"
|
2022-06-30 10:21:13 +03:00
|
|
|
#include "hw/misc/unimp.h"
|
2022-06-30 10:21:14 +03:00
|
|
|
#include "hw/misc/aspeed_peci.h"
|
hw/arm: Hook up FSI module in AST2600
This patchset introduces IBM's Flexible Service Interface(FSI).
Time for some fun with inter-processor buses. FSI allows a service
processor access to the internal buses of a host POWER processor to
perform configuration or debugging.
FSI has long existed in POWER processes and so comes with some baggage,
including how it has been integrated into the ASPEED SoC.
Working backwards from the POWER processor, the fundamental pieces of
interest for the implementation are:
1. The Common FRU Access Macro (CFAM), an address space containing
various "engines" that drive accesses on buses internal and external
to the POWER chip. Examples include the SBEFIFO and I2C masters. The
engines hang off of an internal Local Bus (LBUS) which is described
by the CFAM configuration block.
2. The FSI slave: The slave is the terminal point of the FSI bus for
FSI symbols addressed to it. Slaves can be cascaded off of one
another. The slave's configuration registers appear in address space
of the CFAM to which it is attached.
3. The FSI master: A controller in the platform service processor (e.g.
BMC) driving CFAM engine accesses into the POWER chip. At the
hardware level FSI is a bit-based protocol supporting synchronous and
DMA-driven accesses of engines in a CFAM.
4. The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
POWER processors. This now makes an appearance in the ASPEED SoC due
to tight integration of the FSI master IP with the OPB, mainly the
existence of an MMIO-mapping of the CFAM address straight onto a
sub-region of the OPB address space.
5. An APB-to-OPB bridge enabling access to the OPB from the ARM core in
the AST2600. Hardware limitations prevent the OPB from being directly
mapped into APB, so all accesses are indirect through the bridge.
The implementation appears as following in the qemu device tree:
(qemu) info qtree
bus: main-system-bus
type System
...
dev: aspeed.apb2opb, id ""
gpio-out "sysbus-irq" 1
mmio 000000001e79b000/0000000000001000
bus: opb.1
type opb
dev: fsi.master, id ""
bus: fsi.bus.1
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.1
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
bus: opb.0
type opb
dev: fsi.master, id ""
bus: fsi.bus.0
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.0
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
The LBUS is modelled to maintain the qdev bus hierarchy and to take
advantage of the object model to automatically generate the CFAM
configuration block. The configuration block presents engines in the
order they are attached to the CFAM's LBUS. Engine implementations
should subclass the LBusDevice and set the 'config' member of
LBusDeviceClass to match the engine's type.
CFAM designs offer a lot of flexibility, for instance it is possible for
a CFAM to be simultaneously driven from multiple FSI links. The modeling
is not so complete; it's assumed that each CFAM is attached to a single
FSI slave (as a consequence the CFAM subclasses the FSI slave).
As for FSI, its symbols and wire-protocol are not modelled at all. This
is not necessary to get FSI off the ground thanks to the mapping of the
CFAM address space onto the OPB address space - the models follow this
directly and map the CFAM memory region into the OPB's memory region.
Future work includes supporting more advanced accesses that drive the
FSI master directly rather than indirectly via the CFAM mapping, which
will require implementing the FSI state machine and methods for each of
the FSI symbols on the slave. Further down the track we can also look at
supporting the bitbanged SoftFSI drivers in Linux by extending the FSI
slave model to resolve sequences of GPIO IRQs into FSI symbols, and
calling the associated symbol method on the slave to map the access onto
the CFAM.
Testing:
Tested by reading cfam config address 0 on rainier machine type.
root@p10bmc:~# pdbg -a getcfam 0x0
p0: 0x0 = 0xc0022d15
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-01-26 13:49:53 +03:00
|
|
|
#include "hw/fsi/aspeed_apb2opb.h"
|
2024-09-05 10:38:32 +03:00
|
|
|
#include "hw/char/serial-mm.h"
|
2024-06-04 08:44:34 +03:00
|
|
|
#include "hw/intc/arm_gicv3.h"
|
2016-03-16 20:06:00 +03:00
|
|
|
|
2016-10-17 21:22:16 +03:00
|
|
|
#define ASPEED_SPIS_NUM 2
|
2020-02-06 21:34:37 +03:00
|
|
|
#define ASPEED_EHCIS_NUM 2
|
2024-06-04 08:44:34 +03:00
|
|
|
#define ASPEED_WDTS_NUM 8
|
|
|
|
|
#define ASPEED_CPUS_NUM 4
|
2019-09-25 17:32:46 +03:00
|
|
|
#define ASPEED_MACS_NUM 4
|
aspeed: Refactor UART init for multi-SoC machines
This change moves the code that connects the SoC UART's to serial_hd's
to the machine.
It makes each UART a proper child member of the SoC, and then allows the
machine to selectively initialize the chardev for each UART with a
serial_hd.
This should preserve backwards compatibility, but also allow multi-SoC
boards to completely change the wiring of serial devices from the
command line to specific SoC UART's.
This also removes the uart-default property from the SoC, since the SoC
doesn't need to know what UART is the "default" on the machine anymore.
I tested this using the images and commands from the previous
refactoring, and another test image for the ast1030:
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/fuji.mtd
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/wedge100.mtd
wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf
Fuji uses UART1:
qemu-system-arm -machine fuji-bmc \
-drive file=fuji.mtd,format=raw,if=mtd \
-nographic
ast2600-evb uses uart-default=UART5:
qemu-system-arm -machine ast2600-evb \
-drive file=fuji.mtd,format=raw,if=mtd \
-serial null -serial mon:stdio -display none
Wedge100 uses UART3:
qemu-system-arm -machine palmetto-bmc \
-drive file=wedge100.mtd,format=raw,if=mtd \
-serial null -serial null -serial null \
-serial mon:stdio -display none
AST1030 EVB uses UART5:
qemu-system-arm -machine ast1030-evb \
-kernel Y35BCL.elf -nographic
Fixes: 6827ff20b2975 ("hw: aspeed: Init all UART's with serial devices")
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-4-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-07-14 17:24:38 +03:00
|
|
|
#define ASPEED_UARTS_NUM 13
|
2023-02-07 11:02:05 +03:00
|
|
|
#define ASPEED_JTAG_NUM 2
|
2016-10-17 21:22:16 +03:00
|
|
|
|
2020-09-03 23:43:22 +03:00
|
|
|
struct AspeedSoCState {
|
2016-03-16 20:06:00 +03:00
|
|
|
DeviceState parent;
|
|
|
|
|
|
2022-06-30 10:21:13 +03:00
|
|
|
MemoryRegion *memory;
|
2019-11-19 17:11:57 +03:00
|
|
|
MemoryRegion *dram_mr;
|
2022-06-30 10:21:13 +03:00
|
|
|
MemoryRegion dram_container;
|
2016-12-27 17:59:27 +03:00
|
|
|
MemoryRegion sram;
|
2023-03-02 15:57:50 +03:00
|
|
|
MemoryRegion spi_boot_container;
|
|
|
|
|
MemoryRegion spi_boot;
|
2024-06-04 08:44:36 +03:00
|
|
|
AddressSpace dram_as;
|
2019-07-01 19:26:16 +03:00
|
|
|
AspeedRtcState rtc;
|
2016-03-16 20:06:00 +03:00
|
|
|
AspeedTimerCtrlState timerctrl;
|
2016-06-06 18:59:29 +03:00
|
|
|
AspeedI2CState i2c;
|
2022-01-11 11:45:46 +03:00
|
|
|
AspeedI3CState i3c;
|
2016-06-27 17:37:33 +03:00
|
|
|
AspeedSCUState scu;
|
2024-06-04 08:44:34 +03:00
|
|
|
AspeedSCUState scuio;
|
2021-05-01 11:03:51 +03:00
|
|
|
AspeedHACEState hace;
|
2019-07-01 19:26:18 +03:00
|
|
|
AspeedXDMAState xdma;
|
2021-10-12 09:20:08 +03:00
|
|
|
AspeedADCState adc;
|
2016-10-17 21:22:16 +03:00
|
|
|
AspeedSMCState fmc;
|
2016-10-17 21:22:16 +03:00
|
|
|
AspeedSMCState spi[ASPEED_SPIS_NUM];
|
2020-02-06 21:34:37 +03:00
|
|
|
EHCISysBusState ehci[ASPEED_EHCIS_NUM];
|
2022-02-18 11:18:10 +03:00
|
|
|
AspeedSBCState sbc;
|
2024-06-04 08:44:34 +03:00
|
|
|
AspeedSLIState sli;
|
|
|
|
|
AspeedSLIState sliio;
|
hw/arm/aspeed_ast10x0: Map the secure SRAM
Some SRAM appears to be used by the Secure Boot unit and
crypto accelerators. Name it 'secure sram'.
Note, the SRAM base address was already present but unused
(the 'SBC' index is used for the MMIO peripheral).
Interestingly using CFLAGS=-Winitializer-overrides reports:
../hw/arm/aspeed_ast10x0.c:32:30: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ASPEED_DEV_SBC] = 0x7E6F2000,
^~~~~~~~~~
../hw/arm/aspeed_ast10x0.c:24:30: note: previous initialization is here
[ASPEED_DEV_SBC] = 0x79000000,
^~~~~~~~~~
This fixes with Zephyr:
uart:~$ rsa test
rsa test vector[0]:
[00:00:26.156,000] <err> os: ***** BUS FAULT *****
[00:00:26.157,000] <err> os: Precise data bus error
[00:00:26.157,000] <err> os: BFAR Address: 0x79000000
[00:00:26.158,000] <err> os: r0/a1: 0x79000000 r1/a2: 0x00000000 r2/a3: 0x00001800
[00:00:26.158,000] <err> os: r3/a4: 0x79001800 r12/ip: 0x00000800 r14/lr: 0x0001098d
[00:00:26.158,000] <err> os: xpsr: 0x81000000
[00:00:26.158,000] <err> os: Faulting instruction address (r15/pc): 0x0001e1bc
[00:00:26.158,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:26.158,000] <err> os: Current thread: 0x38248 (shell_uart)
[00:00:26.165,000] <err> os: Halting system
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
[ clg: Fixed size of Secure Boot Controller Memory ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07 11:02:05 +03:00
|
|
|
MemoryRegion secsram;
|
2022-06-30 10:21:13 +03:00
|
|
|
UnimplementedDeviceState sbc_unimplemented;
|
2016-09-06 21:52:17 +03:00
|
|
|
AspeedSDMCState sdmc;
|
2017-07-11 13:21:26 +03:00
|
|
|
AspeedWDTState wdt[ASPEED_WDTS_NUM];
|
2019-07-01 19:26:16 +03:00
|
|
|
FTGMAC100State ftgmac100[ASPEED_MACS_NUM];
|
2019-09-25 17:32:47 +03:00
|
|
|
AspeedMiiState mii[ASPEED_MACS_NUM];
|
2019-09-04 10:04:58 +03:00
|
|
|
AspeedGPIOState gpio;
|
2019-09-25 17:32:43 +03:00
|
|
|
AspeedGPIOState gpio_1_8v;
|
2019-09-25 17:32:27 +03:00
|
|
|
AspeedSDHCIState sdhci;
|
2020-01-30 19:02:02 +03:00
|
|
|
AspeedSDHCIState emmc;
|
2021-03-09 14:01:28 +03:00
|
|
|
AspeedLPCState lpc;
|
2022-06-30 10:21:14 +03:00
|
|
|
AspeedPECIState peci;
|
aspeed: Refactor UART init for multi-SoC machines
This change moves the code that connects the SoC UART's to serial_hd's
to the machine.
It makes each UART a proper child member of the SoC, and then allows the
machine to selectively initialize the chardev for each UART with a
serial_hd.
This should preserve backwards compatibility, but also allow multi-SoC
boards to completely change the wiring of serial devices from the
command line to specific SoC UART's.
This also removes the uart-default property from the SoC, since the SoC
doesn't need to know what UART is the "default" on the machine anymore.
I tested this using the images and commands from the previous
refactoring, and another test image for the ast1030:
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/fuji.mtd
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/wedge100.mtd
wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf
Fuji uses UART1:
qemu-system-arm -machine fuji-bmc \
-drive file=fuji.mtd,format=raw,if=mtd \
-nographic
ast2600-evb uses uart-default=UART5:
qemu-system-arm -machine ast2600-evb \
-drive file=fuji.mtd,format=raw,if=mtd \
-serial null -serial mon:stdio -display none
Wedge100 uses UART3:
qemu-system-arm -machine palmetto-bmc \
-drive file=wedge100.mtd,format=raw,if=mtd \
-serial null -serial null -serial null \
-serial mon:stdio -display none
AST1030 EVB uses UART5:
qemu-system-arm -machine ast1030-evb \
-kernel Y35BCL.elf -nographic
Fixes: 6827ff20b2975 ("hw: aspeed: Init all UART's with serial devices")
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-4-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-07-14 17:24:38 +03:00
|
|
|
SerialMM uart[ASPEED_UARTS_NUM];
|
2022-05-02 18:03:03 +03:00
|
|
|
Clock *sysclk;
|
2022-06-30 10:21:13 +03:00
|
|
|
UnimplementedDeviceState iomem;
|
|
|
|
|
UnimplementedDeviceState video;
|
|
|
|
|
UnimplementedDeviceState emmc_boot_controller;
|
|
|
|
|
UnimplementedDeviceState dpmcu;
|
2023-02-07 11:02:05 +03:00
|
|
|
UnimplementedDeviceState pwm;
|
|
|
|
|
UnimplementedDeviceState espi;
|
|
|
|
|
UnimplementedDeviceState udc;
|
|
|
|
|
UnimplementedDeviceState sgpiom;
|
|
|
|
|
UnimplementedDeviceState jtag[ASPEED_JTAG_NUM];
|
hw/arm: Hook up FSI module in AST2600
This patchset introduces IBM's Flexible Service Interface(FSI).
Time for some fun with inter-processor buses. FSI allows a service
processor access to the internal buses of a host POWER processor to
perform configuration or debugging.
FSI has long existed in POWER processes and so comes with some baggage,
including how it has been integrated into the ASPEED SoC.
Working backwards from the POWER processor, the fundamental pieces of
interest for the implementation are:
1. The Common FRU Access Macro (CFAM), an address space containing
various "engines" that drive accesses on buses internal and external
to the POWER chip. Examples include the SBEFIFO and I2C masters. The
engines hang off of an internal Local Bus (LBUS) which is described
by the CFAM configuration block.
2. The FSI slave: The slave is the terminal point of the FSI bus for
FSI symbols addressed to it. Slaves can be cascaded off of one
another. The slave's configuration registers appear in address space
of the CFAM to which it is attached.
3. The FSI master: A controller in the platform service processor (e.g.
BMC) driving CFAM engine accesses into the POWER chip. At the
hardware level FSI is a bit-based protocol supporting synchronous and
DMA-driven accesses of engines in a CFAM.
4. The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
POWER processors. This now makes an appearance in the ASPEED SoC due
to tight integration of the FSI master IP with the OPB, mainly the
existence of an MMIO-mapping of the CFAM address straight onto a
sub-region of the OPB address space.
5. An APB-to-OPB bridge enabling access to the OPB from the ARM core in
the AST2600. Hardware limitations prevent the OPB from being directly
mapped into APB, so all accesses are indirect through the bridge.
The implementation appears as following in the qemu device tree:
(qemu) info qtree
bus: main-system-bus
type System
...
dev: aspeed.apb2opb, id ""
gpio-out "sysbus-irq" 1
mmio 000000001e79b000/0000000000001000
bus: opb.1
type opb
dev: fsi.master, id ""
bus: fsi.bus.1
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.1
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
bus: opb.0
type opb
dev: fsi.master, id ""
bus: fsi.bus.0
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.0
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
The LBUS is modelled to maintain the qdev bus hierarchy and to take
advantage of the object model to automatically generate the CFAM
configuration block. The configuration block presents engines in the
order they are attached to the CFAM's LBUS. Engine implementations
should subclass the LBusDevice and set the 'config' member of
LBusDeviceClass to match the engine's type.
CFAM designs offer a lot of flexibility, for instance it is possible for
a CFAM to be simultaneously driven from multiple FSI links. The modeling
is not so complete; it's assumed that each CFAM is attached to a single
FSI slave (as a consequence the CFAM subclasses the FSI slave).
As for FSI, its symbols and wire-protocol are not modelled at all. This
is not necessary to get FSI off the ground thanks to the mapping of the
CFAM address space onto the OPB address space - the models follow this
directly and map the CFAM memory region into the OPB's memory region.
Future work includes supporting more advanced accesses that drive the
FSI master directly rather than indirectly via the CFAM mapping, which
will require implementing the FSI state machine and methods for each of
the FSI symbols on the slave. Further down the track we can also look at
supporting the bitbanged SoftFSI drivers in Linux by extending the FSI
slave model to resolve sequences of GPIO IRQs into FSI symbols, and
calling the associated symbol method on the slave to map the access onto
the CFAM.
Testing:
Tested by reading cfam config address 0 on rainier machine type.
root@p10bmc:~# pdbg -a getcfam 0x0
p0: 0x0 = 0xc0022d15
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-01-26 13:49:53 +03:00
|
|
|
AspeedAPB2OPBState fsi[2];
|
2020-09-03 23:43:22 +03:00
|
|
|
};
|
2016-03-16 20:06:00 +03:00
|
|
|
|
2016-09-22 20:13:05 +03:00
|
|
|
#define TYPE_ASPEED_SOC "aspeed-soc"
|
2020-09-16 21:25:18 +03:00
|
|
|
OBJECT_DECLARE_TYPE(AspeedSoCState, AspeedSoCClass, ASPEED_SOC)
|
2016-03-16 20:06:00 +03:00
|
|
|
|
2023-10-24 19:24:18 +03:00
|
|
|
struct Aspeed2400SoCState {
|
|
|
|
|
AspeedSoCState parent;
|
2023-10-24 19:24:22 +03:00
|
|
|
|
|
|
|
|
ARMCPU cpu[ASPEED_CPUS_NUM];
|
|
|
|
|
AspeedVICState vic;
|
2023-10-24 19:24:18 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define TYPE_ASPEED2400_SOC "aspeed2400-soc"
|
|
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed2400SoCState, ASPEED2400_SOC)
|
|
|
|
|
|
2023-10-24 19:24:17 +03:00
|
|
|
struct Aspeed2600SoCState {
|
|
|
|
|
AspeedSoCState parent;
|
2023-10-24 19:24:21 +03:00
|
|
|
|
|
|
|
|
A15MPPrivState a7mpcore;
|
|
|
|
|
ARMCPU cpu[ASPEED_CPUS_NUM]; /* XXX belong to a7mpcore */
|
2023-10-24 19:24:17 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define TYPE_ASPEED2600_SOC "aspeed2600-soc"
|
|
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed2600SoCState, ASPEED2600_SOC)
|
|
|
|
|
|
2024-06-04 08:44:34 +03:00
|
|
|
struct Aspeed27x0SoCState {
|
|
|
|
|
AspeedSoCState parent;
|
|
|
|
|
|
|
|
|
|
ARMCPU cpu[ASPEED_CPUS_NUM];
|
|
|
|
|
AspeedINTCState intc;
|
|
|
|
|
GICv3State gic;
|
2024-06-04 08:44:36 +03:00
|
|
|
MemoryRegion dram_empty;
|
2024-06-04 08:44:34 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define TYPE_ASPEED27X0_SOC "aspeed27x0-soc"
|
|
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed27x0SoCState, ASPEED27X0_SOC)
|
|
|
|
|
|
2023-10-24 19:24:16 +03:00
|
|
|
struct Aspeed10x0SoCState {
|
|
|
|
|
AspeedSoCState parent;
|
2023-10-24 19:24:20 +03:00
|
|
|
|
|
|
|
|
ARMv7MState armv7m;
|
2023-10-24 19:24:16 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define TYPE_ASPEED10X0_SOC "aspeed10x0-soc"
|
|
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed10x0SoCState, ASPEED10X0_SOC)
|
|
|
|
|
|
2020-09-03 23:43:22 +03:00
|
|
|
struct AspeedSoCClass {
|
2019-09-25 17:32:42 +03:00
|
|
|
DeviceClass parent_class;
|
|
|
|
|
|
2016-09-22 20:13:05 +03:00
|
|
|
const char *name;
|
2024-01-25 08:55:44 +03:00
|
|
|
/** valid_cpu_types: NULL terminated array of a single CPU type. */
|
|
|
|
|
const char * const *valid_cpu_types;
|
2016-09-22 20:13:05 +03:00
|
|
|
uint32_t silicon_rev;
|
2016-12-27 17:59:27 +03:00
|
|
|
uint64_t sram_size;
|
hw/arm/aspeed_ast10x0: Map the secure SRAM
Some SRAM appears to be used by the Secure Boot unit and
crypto accelerators. Name it 'secure sram'.
Note, the SRAM base address was already present but unused
(the 'SBC' index is used for the MMIO peripheral).
Interestingly using CFLAGS=-Winitializer-overrides reports:
../hw/arm/aspeed_ast10x0.c:32:30: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ASPEED_DEV_SBC] = 0x7E6F2000,
^~~~~~~~~~
../hw/arm/aspeed_ast10x0.c:24:30: note: previous initialization is here
[ASPEED_DEV_SBC] = 0x79000000,
^~~~~~~~~~
This fixes with Zephyr:
uart:~$ rsa test
rsa test vector[0]:
[00:00:26.156,000] <err> os: ***** BUS FAULT *****
[00:00:26.157,000] <err> os: Precise data bus error
[00:00:26.157,000] <err> os: BFAR Address: 0x79000000
[00:00:26.158,000] <err> os: r0/a1: 0x79000000 r1/a2: 0x00000000 r2/a3: 0x00001800
[00:00:26.158,000] <err> os: r3/a4: 0x79001800 r12/ip: 0x00000800 r14/lr: 0x0001098d
[00:00:26.158,000] <err> os: xpsr: 0x81000000
[00:00:26.158,000] <err> os: Faulting instruction address (r15/pc): 0x0001e1bc
[00:00:26.158,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:26.158,000] <err> os: Current thread: 0x38248 (shell_uart)
[00:00:26.165,000] <err> os: Halting system
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
[ clg: Fixed size of Secure Boot Controller Memory ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07 11:02:05 +03:00
|
|
|
uint64_t secsram_size;
|
2016-10-17 21:22:16 +03:00
|
|
|
int spis_num;
|
2020-02-06 21:34:37 +03:00
|
|
|
int ehcis_num;
|
2017-07-11 13:21:26 +03:00
|
|
|
int wdts_num;
|
2019-09-25 17:32:46 +03:00
|
|
|
int macs_num;
|
2022-05-25 11:31:33 +03:00
|
|
|
int uarts_num;
|
2024-02-15 10:53:30 +03:00
|
|
|
int uarts_base;
|
2019-07-01 19:26:15 +03:00
|
|
|
const int *irqmap;
|
2019-07-01 19:26:15 +03:00
|
|
|
const hwaddr *memmap;
|
2019-07-01 19:26:16 +03:00
|
|
|
uint32_t num_cpus;
|
2022-05-25 11:31:33 +03:00
|
|
|
qemu_irq (*get_irq)(AspeedSoCState *s, int dev);
|
2024-07-17 09:30:18 +03:00
|
|
|
bool (*boot_from_emmc)(AspeedSoCState *s);
|
2020-09-03 23:43:22 +03:00
|
|
|
};
|
2016-09-22 20:13:05 +03:00
|
|
|
|
2024-01-25 08:55:43 +03:00
|
|
|
const char *aspeed_soc_cpu_type(AspeedSoCClass *sc);
|
2016-03-16 20:06:00 +03:00
|
|
|
|
2019-07-01 19:26:15 +03:00
|
|
|
enum {
|
2023-03-02 15:57:50 +03:00
|
|
|
ASPEED_DEV_SPI_BOOT,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_IOMEM,
|
2024-02-15 10:53:30 +03:00
|
|
|
ASPEED_DEV_UART0,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_UART1,
|
|
|
|
|
ASPEED_DEV_UART2,
|
|
|
|
|
ASPEED_DEV_UART3,
|
|
|
|
|
ASPEED_DEV_UART4,
|
|
|
|
|
ASPEED_DEV_UART5,
|
2022-05-25 11:31:33 +03:00
|
|
|
ASPEED_DEV_UART6,
|
|
|
|
|
ASPEED_DEV_UART7,
|
|
|
|
|
ASPEED_DEV_UART8,
|
|
|
|
|
ASPEED_DEV_UART9,
|
|
|
|
|
ASPEED_DEV_UART10,
|
|
|
|
|
ASPEED_DEV_UART11,
|
|
|
|
|
ASPEED_DEV_UART12,
|
|
|
|
|
ASPEED_DEV_UART13,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_VUART,
|
|
|
|
|
ASPEED_DEV_FMC,
|
2024-06-04 08:44:34 +03:00
|
|
|
ASPEED_DEV_SPI0,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_SPI1,
|
|
|
|
|
ASPEED_DEV_SPI2,
|
|
|
|
|
ASPEED_DEV_EHCI1,
|
|
|
|
|
ASPEED_DEV_EHCI2,
|
|
|
|
|
ASPEED_DEV_VIC,
|
2024-06-04 08:44:34 +03:00
|
|
|
ASPEED_DEV_INTC,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_SDMC,
|
|
|
|
|
ASPEED_DEV_SCU,
|
|
|
|
|
ASPEED_DEV_ADC,
|
2022-02-18 11:18:10 +03:00
|
|
|
ASPEED_DEV_SBC,
|
hw/arm/aspeed_ast10x0: Map the secure SRAM
Some SRAM appears to be used by the Secure Boot unit and
crypto accelerators. Name it 'secure sram'.
Note, the SRAM base address was already present but unused
(the 'SBC' index is used for the MMIO peripheral).
Interestingly using CFLAGS=-Winitializer-overrides reports:
../hw/arm/aspeed_ast10x0.c:32:30: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[ASPEED_DEV_SBC] = 0x7E6F2000,
^~~~~~~~~~
../hw/arm/aspeed_ast10x0.c:24:30: note: previous initialization is here
[ASPEED_DEV_SBC] = 0x79000000,
^~~~~~~~~~
This fixes with Zephyr:
uart:~$ rsa test
rsa test vector[0]:
[00:00:26.156,000] <err> os: ***** BUS FAULT *****
[00:00:26.157,000] <err> os: Precise data bus error
[00:00:26.157,000] <err> os: BFAR Address: 0x79000000
[00:00:26.158,000] <err> os: r0/a1: 0x79000000 r1/a2: 0x00000000 r2/a3: 0x00001800
[00:00:26.158,000] <err> os: r3/a4: 0x79001800 r12/ip: 0x00000800 r14/lr: 0x0001098d
[00:00:26.158,000] <err> os: xpsr: 0x81000000
[00:00:26.158,000] <err> os: Faulting instruction address (r15/pc): 0x0001e1bc
[00:00:26.158,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:26.158,000] <err> os: Current thread: 0x38248 (shell_uart)
[00:00:26.165,000] <err> os: Halting system
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Delevoryas <peter@pjd.dev>
[ clg: Fixed size of Secure Boot Controller Memory ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-02-07 11:02:05 +03:00
|
|
|
ASPEED_DEV_SECSRAM,
|
2022-05-02 18:03:02 +03:00
|
|
|
ASPEED_DEV_EMMC_BC,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_VIDEO,
|
|
|
|
|
ASPEED_DEV_SRAM,
|
|
|
|
|
ASPEED_DEV_SDHCI,
|
|
|
|
|
ASPEED_DEV_GPIO,
|
|
|
|
|
ASPEED_DEV_GPIO_1_8V,
|
|
|
|
|
ASPEED_DEV_RTC,
|
|
|
|
|
ASPEED_DEV_TIMER1,
|
|
|
|
|
ASPEED_DEV_TIMER2,
|
|
|
|
|
ASPEED_DEV_TIMER3,
|
|
|
|
|
ASPEED_DEV_TIMER4,
|
|
|
|
|
ASPEED_DEV_TIMER5,
|
|
|
|
|
ASPEED_DEV_TIMER6,
|
|
|
|
|
ASPEED_DEV_TIMER7,
|
|
|
|
|
ASPEED_DEV_TIMER8,
|
|
|
|
|
ASPEED_DEV_WDT,
|
|
|
|
|
ASPEED_DEV_PWM,
|
|
|
|
|
ASPEED_DEV_LPC,
|
|
|
|
|
ASPEED_DEV_IBT,
|
|
|
|
|
ASPEED_DEV_I2C,
|
2022-06-30 10:21:14 +03:00
|
|
|
ASPEED_DEV_PECI,
|
2020-08-25 22:20:02 +03:00
|
|
|
ASPEED_DEV_ETH1,
|
|
|
|
|
ASPEED_DEV_ETH2,
|
|
|
|
|
ASPEED_DEV_ETH3,
|
|
|
|
|
ASPEED_DEV_ETH4,
|
|
|
|
|
ASPEED_DEV_MII1,
|
|
|
|
|
ASPEED_DEV_MII2,
|
|
|
|
|
ASPEED_DEV_MII3,
|
|
|
|
|
ASPEED_DEV_MII4,
|
|
|
|
|
ASPEED_DEV_SDRAM,
|
|
|
|
|
ASPEED_DEV_XDMA,
|
|
|
|
|
ASPEED_DEV_EMMC,
|
2021-03-09 14:01:28 +03:00
|
|
|
ASPEED_DEV_KCS,
|
2021-05-01 11:03:51 +03:00
|
|
|
ASPEED_DEV_HACE,
|
2022-01-07 20:07:57 +03:00
|
|
|
ASPEED_DEV_DPMCU,
|
|
|
|
|
ASPEED_DEV_DP,
|
2022-01-11 11:45:46 +03:00
|
|
|
ASPEED_DEV_I3C,
|
2023-02-07 11:02:05 +03:00
|
|
|
ASPEED_DEV_ESPI,
|
|
|
|
|
ASPEED_DEV_UDC,
|
|
|
|
|
ASPEED_DEV_SGPIOM,
|
|
|
|
|
ASPEED_DEV_JTAG0,
|
|
|
|
|
ASPEED_DEV_JTAG1,
|
hw/arm: Hook up FSI module in AST2600
This patchset introduces IBM's Flexible Service Interface(FSI).
Time for some fun with inter-processor buses. FSI allows a service
processor access to the internal buses of a host POWER processor to
perform configuration or debugging.
FSI has long existed in POWER processes and so comes with some baggage,
including how it has been integrated into the ASPEED SoC.
Working backwards from the POWER processor, the fundamental pieces of
interest for the implementation are:
1. The Common FRU Access Macro (CFAM), an address space containing
various "engines" that drive accesses on buses internal and external
to the POWER chip. Examples include the SBEFIFO and I2C masters. The
engines hang off of an internal Local Bus (LBUS) which is described
by the CFAM configuration block.
2. The FSI slave: The slave is the terminal point of the FSI bus for
FSI symbols addressed to it. Slaves can be cascaded off of one
another. The slave's configuration registers appear in address space
of the CFAM to which it is attached.
3. The FSI master: A controller in the platform service processor (e.g.
BMC) driving CFAM engine accesses into the POWER chip. At the
hardware level FSI is a bit-based protocol supporting synchronous and
DMA-driven accesses of engines in a CFAM.
4. The On-Chip Peripheral Bus (OPB): A low-speed bus typically found in
POWER processors. This now makes an appearance in the ASPEED SoC due
to tight integration of the FSI master IP with the OPB, mainly the
existence of an MMIO-mapping of the CFAM address straight onto a
sub-region of the OPB address space.
5. An APB-to-OPB bridge enabling access to the OPB from the ARM core in
the AST2600. Hardware limitations prevent the OPB from being directly
mapped into APB, so all accesses are indirect through the bridge.
The implementation appears as following in the qemu device tree:
(qemu) info qtree
bus: main-system-bus
type System
...
dev: aspeed.apb2opb, id ""
gpio-out "sysbus-irq" 1
mmio 000000001e79b000/0000000000001000
bus: opb.1
type opb
dev: fsi.master, id ""
bus: fsi.bus.1
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.1
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
bus: opb.0
type opb
dev: fsi.master, id ""
bus: fsi.bus.0
type fsi.bus
dev: cfam.config, id ""
dev: cfam, id ""
bus: fsi.lbus.0
type lbus
dev: scratchpad, id ""
address = 0 (0x0)
The LBUS is modelled to maintain the qdev bus hierarchy and to take
advantage of the object model to automatically generate the CFAM
configuration block. The configuration block presents engines in the
order they are attached to the CFAM's LBUS. Engine implementations
should subclass the LBusDevice and set the 'config' member of
LBusDeviceClass to match the engine's type.
CFAM designs offer a lot of flexibility, for instance it is possible for
a CFAM to be simultaneously driven from multiple FSI links. The modeling
is not so complete; it's assumed that each CFAM is attached to a single
FSI slave (as a consequence the CFAM subclasses the FSI slave).
As for FSI, its symbols and wire-protocol are not modelled at all. This
is not necessary to get FSI off the ground thanks to the mapping of the
CFAM address space onto the OPB address space - the models follow this
directly and map the CFAM memory region into the OPB's memory region.
Future work includes supporting more advanced accesses that drive the
FSI master directly rather than indirectly via the CFAM mapping, which
will require implementing the FSI state machine and methods for each of
the FSI symbols on the slave. Further down the track we can also look at
supporting the bitbanged SoftFSI drivers in Linux by extending the FSI
slave model to resolve sequences of GPIO IRQs into FSI symbols, and
calling the associated symbol method on the slave to map the access onto
the CFAM.
Testing:
Tested by reading cfam config address 0 on rainier machine type.
root@p10bmc:~# pdbg -a getcfam 0x0
p0: 0x0 = 0xc0022d15
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2024-01-26 13:49:53 +03:00
|
|
|
ASPEED_DEV_FSI1,
|
|
|
|
|
ASPEED_DEV_FSI2,
|
2024-06-04 08:44:34 +03:00
|
|
|
ASPEED_DEV_SCUIO,
|
|
|
|
|
ASPEED_DEV_SLI,
|
|
|
|
|
ASPEED_DEV_SLIIO,
|
|
|
|
|
ASPEED_GIC_DIST,
|
|
|
|
|
ASPEED_GIC_REDIST,
|
2019-07-01 19:26:15 +03:00
|
|
|
};
|
|
|
|
|
|
2022-05-25 11:31:33 +03:00
|
|
|
qemu_irq aspeed_soc_get_irq(AspeedSoCState *s, int dev);
|
aspeed: Refactor UART init for multi-SoC machines
This change moves the code that connects the SoC UART's to serial_hd's
to the machine.
It makes each UART a proper child member of the SoC, and then allows the
machine to selectively initialize the chardev for each UART with a
serial_hd.
This should preserve backwards compatibility, but also allow multi-SoC
boards to completely change the wiring of serial devices from the
command line to specific SoC UART's.
This also removes the uart-default property from the SoC, since the SoC
doesn't need to know what UART is the "default" on the machine anymore.
I tested this using the images and commands from the previous
refactoring, and another test image for the ast1030:
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/fuji.mtd
wget https://github.com/facebook/openbmc/releases/download/v2021.49.0/wedge100.mtd
wget https://github.com/peterdelevoryas/OpenBIC/releases/download/oby35-cl-2022.13.01/Y35BCL.elf
Fuji uses UART1:
qemu-system-arm -machine fuji-bmc \
-drive file=fuji.mtd,format=raw,if=mtd \
-nographic
ast2600-evb uses uart-default=UART5:
qemu-system-arm -machine ast2600-evb \
-drive file=fuji.mtd,format=raw,if=mtd \
-serial null -serial mon:stdio -display none
Wedge100 uses UART3:
qemu-system-arm -machine palmetto-bmc \
-drive file=wedge100.mtd,format=raw,if=mtd \
-serial null -serial null -serial null \
-serial mon:stdio -display none
AST1030 EVB uses UART5:
qemu-system-arm -machine ast1030-evb \
-kernel Y35BCL.elf -nographic
Fixes: 6827ff20b2975 ("hw: aspeed: Init all UART's with serial devices")
Signed-off-by: Peter Delevoryas <peter@pjd.dev>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220705191400.41632-4-peter@pjd.dev>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
2022-07-14 17:24:38 +03:00
|
|
|
bool aspeed_soc_uart_realize(AspeedSoCState *s, Error **errp);
|
|
|
|
|
void aspeed_soc_uart_set_chr(AspeedSoCState *s, int dev, Chardev *chr);
|
2022-06-30 10:21:13 +03:00
|
|
|
bool aspeed_soc_dram_init(AspeedSoCState *s, Error **errp);
|
2022-06-30 10:21:13 +03:00
|
|
|
void aspeed_mmio_map(AspeedSoCState *s, SysBusDevice *dev, int n, hwaddr addr);
|
2022-06-30 10:21:13 +03:00
|
|
|
void aspeed_mmio_map_unimplemented(AspeedSoCState *s, SysBusDevice *dev,
|
|
|
|
|
const char *name, hwaddr addr,
|
|
|
|
|
uint64_t size);
|
2022-07-14 17:24:38 +03:00
|
|
|
void aspeed_board_init_flashes(AspeedSMCState *s, const char *flashtype,
|
|
|
|
|
unsigned int count, int unit0);
|
2022-05-25 11:31:33 +03:00
|
|
|
|
2024-02-15 10:53:30 +03:00
|
|
|
static inline int aspeed_uart_index(int uart_dev)
|
|
|
|
|
{
|
|
|
|
|
return uart_dev - ASPEED_DEV_UART0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int aspeed_uart_first(AspeedSoCClass *sc)
|
|
|
|
|
{
|
|
|
|
|
return aspeed_uart_index(sc->uarts_base);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int aspeed_uart_last(AspeedSoCClass *sc)
|
|
|
|
|
{
|
|
|
|
|
return aspeed_uart_first(sc) + sc->uarts_num - 1;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-22 20:13:05 +03:00
|
|
|
#endif /* ASPEED_SOC_H */
|