Files
qemu/include/hw/arm/aspeed_soc.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

235 lines
6.0 KiB
C
Raw Normal View History

/*
* ASPEED SoC family
*
* 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.
*/
#ifndef ASPEED_SOC_H
#define ASPEED_SOC_H
#include "hw/cpu/a15mpcore.h"
#include "hw/arm/armv7m.h"
#include "hw/intc/aspeed_vic.h"
#include "hw/misc/aspeed_scu.h"
#include "hw/adc/aspeed_adc.h"
#include "hw/misc/aspeed_sdmc.h"
#include "hw/misc/aspeed_xdma.h"
#include "hw/timer/aspeed_timer.h"
#include "hw/rtc/aspeed_rtc.h"
#include "hw/i2c/aspeed_i2c.h"
#include "hw/misc/aspeed_i3c.h"
#include "hw/ssi/aspeed_smc.h"
#include "hw/misc/aspeed_hace.h"
#include "hw/misc/aspeed_sbc.h"
#include "hw/watchdog/wdt_aspeed.h"
#include "hw/net/ftgmac100.h"
#include "target/arm/cpu.h"
#include "hw/gpio/aspeed_gpio.h"
#include "hw/sd/aspeed_sdhci.h"
#include "hw/usb/hcd-ehci.h"
#include "qom/object.h"
#include "hw/misc/aspeed_lpc.h"
#include "hw/misc/unimp.h"
hw/misc/aspeed: Add PECI controller 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>
2022-06-30 09:21:14 +02:00
#include "hw/misc/aspeed_peci.h"
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 16:24:38 +02:00
#include "hw/char/serial.h"
#define ASPEED_SPIS_NUM 2
#define ASPEED_EHCIS_NUM 2
#define ASPEED_WDTS_NUM 4
#define ASPEED_CPUS_NUM 2
#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 16:24:38 +02:00
#define ASPEED_UARTS_NUM 13
#define ASPEED_JTAG_NUM 2
struct AspeedSoCState {
DeviceState parent;
MemoryRegion *memory;
MemoryRegion *dram_mr;
MemoryRegion dram_container;
MemoryRegion sram;
MemoryRegion spi_boot_container;
MemoryRegion spi_boot;
AspeedRtcState rtc;
AspeedTimerCtrlState timerctrl;
AspeedI2CState i2c;
AspeedI3CState i3c;
AspeedSCUState scu;
AspeedHACEState hace;
AspeedXDMAState xdma;
AspeedADCState adc;
AspeedSMCState fmc;
AspeedSMCState spi[ASPEED_SPIS_NUM];
EHCISysBusState ehci[ASPEED_EHCIS_NUM];
AspeedSBCState 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 09:02:05 +01:00
MemoryRegion secsram;
UnimplementedDeviceState sbc_unimplemented;
AspeedSDMCState sdmc;
AspeedWDTState wdt[ASPEED_WDTS_NUM];
FTGMAC100State ftgmac100[ASPEED_MACS_NUM];
AspeedMiiState mii[ASPEED_MACS_NUM];
AspeedGPIOState gpio;
AspeedGPIOState gpio_1_8v;
AspeedSDHCIState sdhci;
AspeedSDHCIState emmc;
AspeedLPCState lpc;
hw/misc/aspeed: Add PECI controller 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>
2022-06-30 09:21:14 +02: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 16:24:38 +02:00
SerialMM uart[ASPEED_UARTS_NUM];
Clock *sysclk;
UnimplementedDeviceState iomem;
UnimplementedDeviceState video;
UnimplementedDeviceState emmc_boot_controller;
UnimplementedDeviceState dpmcu;
UnimplementedDeviceState pwm;
UnimplementedDeviceState espi;
UnimplementedDeviceState udc;
UnimplementedDeviceState sgpiom;
UnimplementedDeviceState jtag[ASPEED_JTAG_NUM];
};
#define TYPE_ASPEED_SOC "aspeed-soc"
OBJECT_DECLARE_TYPE(AspeedSoCState, AspeedSoCClass, ASPEED_SOC)
struct Aspeed2400SoCState {
AspeedSoCState parent;
ARMCPU cpu[ASPEED_CPUS_NUM];
AspeedVICState vic;
};
#define TYPE_ASPEED2400_SOC "aspeed2400-soc"
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed2400SoCState, ASPEED2400_SOC)
struct Aspeed2600SoCState {
AspeedSoCState parent;
A15MPPrivState a7mpcore;
ARMCPU cpu[ASPEED_CPUS_NUM]; /* XXX belong to a7mpcore */
};
#define TYPE_ASPEED2600_SOC "aspeed2600-soc"
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed2600SoCState, ASPEED2600_SOC)
struct Aspeed10x0SoCState {
AspeedSoCState parent;
ARMv7MState armv7m;
};
#define TYPE_ASPEED10X0_SOC "aspeed10x0-soc"
OBJECT_DECLARE_SIMPLE_TYPE(Aspeed10x0SoCState, ASPEED10X0_SOC)
struct AspeedSoCClass {
DeviceClass parent_class;
const char *name;
/** valid_cpu_types: NULL terminated array of a single CPU type. */
const char * const *valid_cpu_types;
uint32_t silicon_rev;
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 09:02:05 +01:00
uint64_t secsram_size;
int spis_num;
int ehcis_num;
int wdts_num;
int macs_num;
int uarts_num;
const int *irqmap;
const hwaddr *memmap;
uint32_t num_cpus;
qemu_irq (*get_irq)(AspeedSoCState *s, int dev);
};
const char *aspeed_soc_cpu_type(AspeedSoCClass *sc);
enum {
ASPEED_DEV_SPI_BOOT,
ASPEED_DEV_IOMEM,
ASPEED_DEV_UART1,
ASPEED_DEV_UART2,
ASPEED_DEV_UART3,
ASPEED_DEV_UART4,
ASPEED_DEV_UART5,
ASPEED_DEV_UART6,
ASPEED_DEV_UART7,
ASPEED_DEV_UART8,
ASPEED_DEV_UART9,
ASPEED_DEV_UART10,
ASPEED_DEV_UART11,
ASPEED_DEV_UART12,
ASPEED_DEV_UART13,
ASPEED_DEV_VUART,
ASPEED_DEV_FMC,
ASPEED_DEV_SPI1,
ASPEED_DEV_SPI2,
ASPEED_DEV_EHCI1,
ASPEED_DEV_EHCI2,
ASPEED_DEV_VIC,
ASPEED_DEV_SDMC,
ASPEED_DEV_SCU,
ASPEED_DEV_ADC,
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 09:02:05 +01:00
ASPEED_DEV_SECSRAM,
ASPEED_DEV_EMMC_BC,
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,
hw/misc/aspeed: Add PECI controller 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>
2022-06-30 09:21:14 +02:00
ASPEED_DEV_PECI,
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,
ASPEED_DEV_KCS,
ASPEED_DEV_HACE,
ASPEED_DEV_DPMCU,
ASPEED_DEV_DP,
ASPEED_DEV_I3C,
ASPEED_DEV_ESPI,
ASPEED_DEV_UDC,
ASPEED_DEV_SGPIOM,
ASPEED_DEV_JTAG0,
ASPEED_DEV_JTAG1,
};
#define ASPEED_SOC_SPI_BOOT_ADDR 0x0
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 16:24:38 +02:00
bool aspeed_soc_uart_realize(AspeedSoCState *s, Error **errp);
void aspeed_soc_uart_set_chr(AspeedSoCState *s, int dev, Chardev *chr);
bool aspeed_soc_dram_init(AspeedSoCState *s, Error **errp);
void aspeed_mmio_map(AspeedSoCState *s, SysBusDevice *dev, int n, hwaddr addr);
void aspeed_mmio_map_unimplemented(AspeedSoCState *s, SysBusDevice *dev,
const char *name, hwaddr addr,
uint64_t size);
void aspeed_board_init_flashes(AspeedSMCState *s, const char *flashtype,
unsigned int count, int unit0);
#endif /* ASPEED_SOC_H */