summaryrefslogtreecommitdiffstats
path: root/hw/arm/aspeed_ast10x0.c
Commit message (Collapse)AuthorAgeFilesLines
* aspeed: Refactor UART init for multi-SoC machinesPeter Delevoryas2022-07-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* aspeed: Create SRAM name from first CPU indexPeter Delevoryas2022-07-141-1/+4
| | | | | | | | | | | | | | | | | | To support multiple SoC's running simultaneously, we need a unique name for each RAM region. DRAM is created by the machine, but SRAM is created by the SoC, since in hardware it is part of the SoC's internals. We need a way to uniquely identify each SRAM region though, for VM migration. Since each of the SoC's CPU's has an index which identifies it uniquely from other CPU's in the machine, we can use the index of any of the CPU's in the SoC to uniquely identify differentiate the SRAM name from other SoC SRAM's. In this change, I just elected to use the index of the first CPU in each SoC. Signed-off-by: Peter Delevoryas <peter@pjd.dev> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220705191400.41632-3-peter@pjd.dev> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw/misc/aspeed: Add PECI controllerPeter Delevoryas2022-06-301-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces a really basic PECI controller that responses to commands by always setting the response code to success and then raising an interrupt to indicate the command is done. This helps avoid getting hit with constant errors if the driver continuously attempts to send a command and keeps timing out. The AST2400 and AST2500 only included registers up to 0x5C, not 0xFC. They supported PECI 1.1, 2.0, and 3.0. The AST2600 and AST1030 support PECI 4.0, which includes more read/write buffer registers from 0x80 to 0xFC to support 64-byte mode. This patch doesn't attempt to handle that, or to create a different version of the controller for the different generations, since it's only implementing functionality that is common to all generations. The basic sequence of events is that the firmware will read and write to various registers and then trigger a command by setting the FIRE bit in the command register (similar to the I2C controller). Then the firmware waits for an interrupt from the PECI controller, expecting the interrupt status register to be filled in with info on what happened. If the command was transmitted and received successfully, then response codes from the host CPU will be found in the data buffer registers. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220630045133.32251-12-me@pjd.dev> [ clg: s/sysbus_mmio_map/aspeed_mmio_map/ ] Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed: Map unimplemented devices in SoC memoryPeter Delevoryas2022-06-301-6/+10
| | | | | | | Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220624003701.1363500-5-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed: Remove usage of sysbus_mmio_mapPeter Delevoryas2022-06-301-12/+13
| | | | | | | | | | | | | | | sysbus_mmio_map maps devices into "get_system_memory()". With the new SoC memory attribute, we want to make sure that each device is mapped into the SoC memory. In single SoC machines, the SoC memory is the same as "get_system_memory()", but in multi SoC machines it will be different. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220624003701.1363500-4-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed: Add memory property to Aspeed SoCPeter Delevoryas2022-06-301-3/+2Star
| | | | | | | | | | Multi-SoC machines can use this property to specify a memory container for each SoC. Single SoC machines will just specify get_system_memory(). Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220624003701.1363500-3-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed: Add I2C buses to AST1030 modelTroy Lee2022-06-221-0/+18
| | | | | | | | | | | | | | | Instantiate the I2C buses in AST1030 model and create two slave device for ast1030-evb. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Joel Stanley <joel@jms.id.au> [ clg : - adapted to current AST1030 upstream models - changed AST2600 to AST1030 in comment - fixed typo in commit log ] Message-Id: <20220324100439.478317-3-troy_lee@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw/gpio: Add ASPEED GPIO model for AST1030Jamin Lin2022-05-251-0/+11
| | | | | | | | | | | | AST1030 integrates one set of Parallel GPIO Controller with maximum 151 control pins, which are 21 groups (A~U, exclude pin: M6 M7 Q5 Q6 Q7 R0 R1 R4 R5 R6 R7 S0 S3 S4 S5 S6 S7 ) and the group T and U are input only. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220525053444.27228-3-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw: aspeed: Introduce common UART init functionPeter Delevoryas2022-05-251-5/+2Star
| | | | | | | Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220516062328.298336-5-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw: aspeed: Ensure AST1030 respects uart-defaultPeter Delevoryas2022-05-251-3/+3
| | | | | | | | | | | | | | The AST1030 machine initialization was not respecting the Aspeed SoC property "uart-default", which specifies which UART should be connected to the first serial device, it was just always connecting UART5. This doesn't change any behavior, because the default value for "uart-default" is UART5, but it makes it possible to override this in new machine definitions using the AST1030. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220516062328.298336-4-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw: aspeed: Add uarts_num SoC attributePeter Delevoryas2022-05-251-0/+1
| | | | | | | | | AST2400 and AST2500 have 5 UART's, while the AST2600 and AST1030 have 13. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220516062328.298336-3-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* hw: aspeed: Add missing UART'sPeter Delevoryas2022-05-251-0/+24
| | | | | | | | | | | | | | This adds the missing UART memory and IRQ mappings for the AST2400, AST2500, AST2600, and AST1030. This also includes the new UART interfaces added in the AST2600 and AST1030 from UART6 to UART13. The addresses and interrupt numbers for these two later chips are identical. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220516062328.298336-2-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed: Introduce a get_irq AspeedSoCClass methodCédric Le Goater2022-05-251-2/+3
| | | | | | | | | | | | and make routine aspeed_soc_get_irq() common to all SoCs. This will be useful to share code. Cc: Jamin Lin <jamin_lin@aspeedtech.com> Cc: Peter Delevoryas <pdel@fb.com> Reviewed-by: Peter Delevoryas <pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220516055620.2380197-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
* aspeed/soc : Add AST1030 supportSteven Lee2022-05-021-0/+299
The embedded core of AST1030 SoC is ARM Coretex M4. It is hard to be integrated in the common Aspeed Soc framework. We introduce a new ast1030 class with instance_init and realize handlers. Signed-off-by: Troy Lee <troy_lee@aspeedtech.com> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Steven Lee <steven_lee@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> [ clg: rename aspeed_ast10xx.c to aspeed_ast10x0.c to match zephyr ] Message-Id: <20220401083850.15266-8-jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>