[PATCH v2 0/8] aspeed: Add multi-SoC machine

[Peter Delevoryas]

v2:
- Rebased on upstream/master + v2 of Cedric's DRAM mapping change:
  
20220623202123.3972977-1-clg@kaod.org/">https://patchwork.ozlabs.org/project/qemu-devel/patch/20220623202123.3972977-1-clg@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