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/
