| Message ID | 20171013142852.916-2-clg@kaod.org |
|---|---|
| State | New |
| Headers | show |
| Series | aspeed: add a witherspoon-bmc machine | expand |
On 13 October 2017 at 15:28, Cédric Le Goater <clg@kaod.org> wrote: > The Witherspoon boards are OpenPOWER system hosting POWER9 Processors. > Let's add support for their BMC including a couple of I2C devices as > found on real HW. > > Signed-off-by: Cédric Le Goater <clg@kaod.org> > Reviewed-by: Andrew Jeffery <andrew@aj.id.au> > --- > > Changes since v2: > > - removed 'ignore_memory_transaction_failures' flag on the machine. > Will require a couple of fixes in the legacy U-Boot accessing wrongly > the bss before the DRAM is initialized. > > The HW drops the write access surely because the SMC controller is > configured in autoread mode by default. I don't know how to model > this behavior in QEMU. I think we would need suppport to boot from > a MMIO region. It is actually possible now -- see hw/ssi/xilinx_spips.c and the request_mmio_ptr code. It's a bit experimental at the moment though (in particular it breaks migration, a thing which we seem to have forgotten to fix for this release cycle :-( ) The other similar thing we have is the flash devices, which allow execution, but requires that the guest doesn't try to execute at the same time as it's put the flash into reads-like-a-device mode. How are you modelling this bit of the address space at the moment? A "reads like RAM but writes are ignored" lump of memory is easy... In any case we can deal with this as a later patchset. thanks -- PMM
On 10/17/2017 05:39 PM, Peter Maydell wrote: > On 13 October 2017 at 15:28, Cédric Le Goater <clg@kaod.org> wrote: >> The Witherspoon boards are OpenPOWER system hosting POWER9 Processors. >> Let's add support for their BMC including a couple of I2C devices as >> found on real HW. >> >> Signed-off-by: Cédric Le Goater <clg@kaod.org> >> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> >> --- >> >> Changes since v2: >> >> - removed 'ignore_memory_transaction_failures' flag on the machine. >> Will require a couple of fixes in the legacy U-Boot accessing wrongly >> the bss before the DRAM is initialized. >> >> The HW drops the write access surely because the SMC controller is >> configured in autoread mode by default. I don't know how to model >> this behavior in QEMU. I think we would need suppport to boot from >> a MMIO region. > > It is actually possible now -- see hw/ssi/xilinx_spips.c and the > request_mmio_ptr code. It's a bit experimental at the moment > though (in particular it breaks migration, a thing which we > seem to have forgotten to fix for this release cycle :-( ) I see. So the Aspeed SMC model would have to maintain a cache area of the flash device contents to satisfy the request_ptr() call ? > The other similar thing we have is the flash devices, which > allow execution, but requires that the guest doesn't try to > execute at the same time as it's put the flash into > reads-like-a-device mode. > > How are you modelling this bit of the address space at the moment? The different flash devices are mapped on the AHB bus in ranges depending on the controller (and the SoC). For the AST2500, which is the witherspoon SoC, we have : [2000:0000-2FFF:FFFF] BMC SPI Flash Memory [3000:0000-37FF:FFFF] SPI1 Flash Memory [3800:0000-3FFF:FFFF] SPI2 Flash Memory The SoC boots from CS0 of the BMC SPI Controller which is also mapped at : [0000:0000-0FFF:FFFF] Firmware SPI Memory (boot-up default) Today, we have created a ROM region which is filled with the CS0 flash content. See commit d769a1da342d ("aspeed: use first FMC flash as a boot ROM") So we end up with address-space memory like this : 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-0000000007ffffff (prio 0, rom): aspeed.boot_rom ... 0000000020000000-000000002fffffff (prio 0, i/o): aspeed.smc.ast2500-fmc.flash 0000000020000000-0000000027ffffff (prio 0, i/o): aspeed.smc.ast2500-fmc.0 0000000028000000-0000000029ffffff (prio 0, i/o): aspeed.smc.ast2500-fmc.1 000000002a000000-000000002bffffff (prio 0, i/o): aspeed.smc.ast2500-fmc.2 0000000030000000-0000000037ffffff (prio 0, i/o): aspeed.smc.ast2500-spi1.flash ... This is a bit brutal, but it boots from the flash device. Booting from the MMIO region would be much better. I will take a look at it, but after some PPC work. > A "reads like RAM but writes are ignored" lump of memory is easy... yes. It seems but I haven't found my way through :/ a stack trace of the failure looks like this : #0 0x00005555558c1680 in arm_cpu_do_transaction_failed (cs=0x5555568cfc00, physaddr=537117152, addr=209376, size=4, access_type=MMU_DATA_STORE, mmu_idx=3, attrs=..., response=2, retaddr=140737054425367) at target/arm/op_helper.c:241 #1 0x00005555557e36c6 in cpu_transaction_failed (retaddr=140737054425367, response=2, attrs=..., mmu_idx=3, access_type=MMU_DATA_STORE, size=4, addr=209376, physaddr=537117152, cpu=0x5555568cfc00) at include/qom/cpu.h:895 #2 0x00005555557e36c6 in io_writex (env=env@entry=0x5555568d7e90, iotlbentry=<optimized out>, mmu_idx=mmu_idx@entry=3, val=val@entry=4294967, addr=addr@entry=209376, retaddr=retaddr@entry=140737054425367, size=4) at accel/tcg/cputlb.c:825 #3 0x00005555557e73ef in io_writel (retaddr=140737054425367, addr=209376, val=4294967, index=204, mmu_idx=3, env=0x5555568d7e90) at accel/tcg/softmmu_template.h:265 #4 0x00005555557e73ef in helper_le_stl_mmu (env=0x5555568d7e90, addr=<optimized out>, val=4294967, oi=35, retaddr=140737054425367) at accel/tcg/softmmu_template.h:300 #5 0x00007fffe622c117 in code_gen_buffer () #6 0x00005555557eef8c in cpu_tb_exec (itb=<optimized out>, itb=<optimized out>, cpu=0x5555568d7e90) > In any case we can deal with this as a later patchset. Well, I would prefer fixing that little issue above with a workaround region. Thanks, C.
On 18 October 2017 at 17:10, Cédric Le Goater <clg@kaod.org> wrote: > On 10/17/2017 05:39 PM, Peter Maydell wrote: >> A "reads like RAM but writes are ignored" lump of memory is easy... > > yes. It seems but I haven't found my way through :/ memory_region_init_rom_device() creates a memory region which is backed by RAM for reads (and for debug writes, like ELF file loading), but backed by the usual device callback functions for writes. So I think you should just be able to use one of those but with the write functions doing nothing (or warning about unimp. behaviour, assuming that your flash devices actually have some kind of command behaviour for writes). This is how we implement the flash device with actual behaviour behind them. hw/mips/boston.c actually has an example of doing a dummy flash device like this (though it uses memory_region_init_rom_device_nomigrate(), which is a bug because your memory contents won't get migrated if you do that. Use the plain function instead.) thanks -- PMM
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index ab895ad490af..5e0b9a184b9c 100644 --- a/hw/arm/aspeed.c +++ b/hw/arm/aspeed.c @@ -46,6 +46,7 @@ enum { PALMETTO_BMC, AST2500_EVB, ROMULUS_BMC, + WITHERSPOON_BMC, }; /* Palmetto hardware value: 0x120CE416 */ @@ -83,8 +84,12 @@ enum { SCU_AST2500_HW_STRAP_ACPI_ENABLE | \ SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER)) +/* Witherspoon hardware value: 0xF10AD216 (but use romulus definition) */ +#define WITHERSPOON_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1 + static void palmetto_bmc_i2c_init(AspeedBoardState *bmc); static void ast2500_evb_i2c_init(AspeedBoardState *bmc); +static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc); static const AspeedBoardConfig aspeed_boards[] = { [PALMETTO_BMC] = { @@ -110,6 +115,14 @@ static const AspeedBoardConfig aspeed_boards[] = { .spi_model = "mx66l1g45g", .num_cs = 2, }, + [WITHERSPOON_BMC] = { + .soc_name = "ast2500-a1", + .hw_strap1 = WITHERSPOON_BMC_HW_STRAP1, + .fmc_model = "mx25l25635e", + .spi_model = "mx66l1g45g", + .num_cs = 2, + .i2c_init = witherspoon_bmc_i2c_init, + }, }; #define FIRMWARE_ADDR 0x0 @@ -337,11 +350,47 @@ static const TypeInfo romulus_bmc_type = { .class_init = romulus_bmc_class_init, }; +static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc) +{ + AspeedSoCState *soc = &bmc->soc; + + i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 4), "tmp423", 0x4c); + i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 5), "tmp423", 0x4c); + + /* The Witherspoon expects a TMP275 but a TMP105 is compatible */ + i2c_create_slave(aspeed_i2c_get_bus(DEVICE(&soc->i2c), 9), "tmp105", 0x4a); +} + +static void witherspoon_bmc_init(MachineState *machine) +{ + aspeed_board_init(machine, &aspeed_boards[WITHERSPOON_BMC]); +} + +static void witherspoon_bmc_class_init(ObjectClass *oc, void *data) +{ + MachineClass *mc = MACHINE_CLASS(oc); + + mc->desc = "OpenPOWER Witherspoon BMC (ARM1176)"; + mc->init = witherspoon_bmc_init; + mc->max_cpus = 1; + mc->no_sdcard = 1; + mc->no_floppy = 1; + mc->no_cdrom = 1; + mc->no_parallel = 1; +} + +static const TypeInfo witherspoon_bmc_type = { + .name = MACHINE_TYPE_NAME("witherspoon-bmc"), + .parent = TYPE_MACHINE, + .class_init = witherspoon_bmc_class_init, +}; + static void aspeed_machine_init(void) { type_register_static(&palmetto_bmc_type); type_register_static(&ast2500_evb_type); type_register_static(&romulus_bmc_type); + type_register_static(&witherspoon_bmc_type); } type_init(aspeed_machine_init)