v2:
- Rebased on upstream/master + v2 of Cedric's DRAM mapping change:
https://patchwork.ozlabs.org/project/qemu-devel/patch/20220623202123.3972977-1-...@kaod.org/
- Got rid of all the sysbus patches, not needed (I can send the dead code
cleanup separately).
- Changed "system-memory" to "memory".
- Moved SoC unimplemented devices into AspeedSoCState, initialized and
mapped them like normal peripheral devices.
- Added one more patch that removes 1 qemu_get_cpu call in aspeed_ast2600.c
- Kept the aspeed_board_init_flashes change: if you'd like, feel free
to drop that patch and the one after it, I can work on refactoring
them more to avoid that.
A few problems I still have before I can add the additional SoC and fix the
boot rom initialization:
1.
We want to use '-device loader' to load firmware into 0x0000_0000, but
that's not really how the SoC works. The SoC reads from SPI flash. It
would be great if I could do '-device
loader,file=firmware,addr=0x2000_0000',
and 0x2000_0000 is the firmware controller's mmio region and it would
store the file into the SPI flash device and the boot ROM (0x0000_0000)
automatically, but I don't think that's possible right?
It seems like what I'll need to do is make '-drive' the source of truth,
and initialize the boot rom from that, similar to the existing code in
aspeed.c with "write_boot_rom".
2.
Right now the SoC doesn't initialize the boot rom memory region, the
machine does it. Perhaps I should fix that, like the DRAM change Cedric
made?
3.
Each SoC creates its own SRAM memory with "memory_region_init_ram", so
the machine doesn't know the name of it.
Memory regions like that need to have a unique name for vm migration,
but each SoC just gives it a generic one, "aspeed.sram". If you try to
run multiple SoC's, the names collide.
How is an SoC supposed to produce a unique name for each memory region
it has, so that it doesn't collide with other SoC's?
Should the machine provide the SRAM region and select a name that
doesn't collide with other SoC's in the machine?
That seems weird, because the SRAM is internal to the SoC. It has a size
and mmio address that's internal to the SoC.
4.
Lastly, I don't know a good way to allocate serial devices to the SoC
UART's.
Perhaps I can make each serial device specify the UART it should connect
to? Like "-serial stdio,uart=bmc.uart5".
Maybe I can create a subclass of the normal serial devices for this?
I'm also not sure how the naming scheme would work. Probably just
decided by the machine?
Note: I've reduced the number of emails cc'd in this series because I was
having trouble with the mail filter at work. Hopefully this goes through
properly.
Thanks,
Peter
Peter Delevoryas (8):
aspeed: Set CPU memory property explicitly
aspeed: Add memory property to Aspeed SoC
aspeed: Remove usage of sysbus_mmio_map
aspeed: Map unimplemented devices in SoC memory
aspeed: Remove use of qemu_get_cpu
aspeed: Add fby35 skeleton
aspeed: Make aspeed_board_init_flashes public
aspeed: Add AST2600 (BMC) to fby35
MAINTAINERS | 1 +
hw/arm/aspeed.c | 29 ++--------
hw/arm/aspeed_ast10x0.c | 46 ++++++++-------
hw/arm/aspeed_ast2600.c | 84 +++++++++++++++------------
hw/arm/aspeed_soc.c | 110 +++++++++++++++++++++++++++---------
hw/arm/fby35.c | 93 ++++++++++++++++++++++++++++++
hw/arm/meson.build | 3 +-
include/hw/arm/aspeed_soc.h | 13 +++++
8 files changed, 269 insertions(+), 110 deletions(-)
create mode 100644 hw/arm/fby35.c
--
2.30.2
