All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/8] aspeed: Add multi-SoC machine
@ 2022-06-24  0:36 Peter Delevoryas
  2022-06-24  0:36 ` [PATCH v2 1/8] aspeed: Set CPU memory property explicitly Peter Delevoryas
                   ` (7 more replies)
  0 siblings, 8 replies; 20+ messages in thread
From: Peter Delevoryas @ 2022-06-24  0:36 UTC (permalink / raw)
  Cc: pdel, clg, peter.maydell, qemu-devel, qemu-arm

v2:
- Rebased on upstream/master + v2 of Cedric's DRAM mapping change:
  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



^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-06-28  7:44 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-24  0:36 [PATCH v2 0/8] aspeed: Add multi-SoC machine Peter Delevoryas
2022-06-24  0:36 ` [PATCH v2 1/8] aspeed: Set CPU memory property explicitly Peter Delevoryas
2022-06-24  6:36   ` Cédric Le Goater
2022-06-24  6:55     ` Cédric Le Goater
2022-06-24 14:00       ` Peter Delevoryas
2022-06-24  0:36 ` [PATCH v2 2/8] aspeed: Add memory property to Aspeed SoC Peter Delevoryas
2022-06-24  6:40   ` Cédric Le Goater
2022-06-24  0:36 ` [PATCH v2 3/8] aspeed: Remove usage of sysbus_mmio_map Peter Delevoryas
2022-06-24  6:56   ` Cédric Le Goater
2022-06-24  0:36 ` [PATCH v2 4/8] aspeed: Map unimplemented devices in SoC memory Peter Delevoryas
2022-06-24  6:58   ` Cédric Le Goater
2022-06-24  0:36 ` [PATCH v2 5/8] aspeed: Remove use of qemu_get_cpu Peter Delevoryas
2022-06-24  6:58   ` Cédric Le Goater
2022-06-24  0:36 ` [PATCH v2 6/8] aspeed: Add fby35 skeleton Peter Delevoryas
2022-06-24  7:00   ` Cédric Le Goater
2022-06-24  0:37 ` [PATCH v2 7/8] aspeed: Make aspeed_board_init_flashes public Peter Delevoryas
2022-06-28  5:03   ` Cédric Le Goater
2022-06-24  0:37 ` [PATCH v2 8/8] aspeed: Add AST2600 (BMC) to fby35 Peter Delevoryas
2022-06-28  5:01   ` Cédric Le Goater
2022-06-28  6:55     ` Peter Delevoryas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.