Hi Cedric, Philippe > Subject: Re: [PATCH v4 06/10] hw/arm/aspeed: Add support for loading > vbootrom image via "-bios" > > On 28/4/25 09:54, Jamin Lin wrote: > > Hi Cedric, > > > >> Subject: Re: [PATCH v4 06/10] hw/arm/aspeed: Add support for loading > >> vbootrom image via "-bios" > >> > >> Hello Jamin, > >> > >> + Phil. > >> > >> On 4/23/25 09:02, Jamin Lin wrote: > >>> Hi Cedric, > >>> > >>>> Cc: Troy Lee <troy_...@aspeedtech.com>; nabiheste...@google.com > >>>> Subject: Re: [PATCH v4 06/10] hw/arm/aspeed: Add support for > >>>> loading vbootrom image via "-bios" > >>>> > >>>> Hello Jamin, > >>>> > >>>>> Based on the design of aspeed_install_boot_rom, users can place > >>>>> their ROM code at the top of the image-bmc, and this function will > >>>>> install image-bmc which included the user's ROM IMAGE at the > >>>>> ASPEED_DEV_SPI_BOOT address. For AST2600, users typically set the > >>>>> boot address to 0x0 and boot directly from there. > >>>>> > >>>>> For AST2700, we introduced a vbootrom to simulate the ROM code and > >>>>> the BOOTMCU SPL (RISC-V). > >>>> > >>>> Side question, is anyone working on the BOOTMCU SPL (RISC-V) models ? > >>>> heterogeneous machines should be supported one day. > >>>> > >>> > >>> Troy developed an initial implementation, but testing has not yet > >>> been performed due to uncertainty around "how to share DRAM memory > >>> and > >> controllers registers" between the RISC-V and the Cortex-A35 cores. > >>> Furthermore, RISC-V interrupt support is currently not implemented. > >> Could you explain a bit more the issues you are facing ? Single QEMU > >> binary is expected to become a reality in the near future and the > >> ast2700 models could benefit from it. > >> > > There is a BootMCU which is a 32-bit RISC-V CPU, and its DRAM start > address is 0x80000000 (32-bit address space). > > The primary CPU is a Cortex-A35, and its DRAM start address is > 0x400000000 (64-bit address space). > > > > If the BootMCU writes 0x12345678 to address 0x80000000, the Cortex-A35 > should be able to read 0x12345678 from address 0x400000000. > > Similarly, if the Cortex-A35 writes 0x00ABCDEF to address 0x400000000, the > BootMCU should be able to read 0x00ABCDEF from address 0x80000000. > > This shouldn't be a problem, the raspi machines have something similar. > > I remember having an issue when displaying the address spaces on the monitor, > using your example, if you start mapping the dram on the rv core, then the AS > has some internal offset, and when you map it on the arm cluster, the offset > persists and you'd see it mapped at > 0x3_8000_0000 while being at 0x4_0000_0000 (it is a bug). However the > accesses from the arm cores really hit 0x4_0000_0000 base: it is just a > display > problem IIRC. > > Maybe the thread around this issue was this one: > https://lore.kernel.org/qemu-devel/20210421144846.GI4440@xz-x1/
Thanks for your reply. After QEMU adds support for a "single binary and this issue is resolved", I will study the single binary design and plan to enable the AST2700 to boot starting from the "BOOTMCU (RISC-V 32-bit)". This is our long-term goal. Jamin
