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.
We use aspeed_install_boot_rom to load the image-bmc at the FMC CS0
memory-mapped I/O address, so we set ASPEED_DEV_SPI_BOOT to
0x100000000.
We load the vbootrom image into the vbootrom memory region at
address 0x0 and start execution from there.
The guest OS first enters the vbootrom. From there, it can easily
access the flash data (image-bmc) at 0x100000000, since vbootrom
itself doesn’t require SPI/flash/emmc host drivers.
To support future eMMC booting, we also plan to install the eMMC
image at the ASPEED_DEV_SPI_BOOT address.
https://github.com/qemu/qemu/blob/master/hw/arm/aspeed.c#L477
ok.
It is fully supported to have both options. If users want to include
their own ROM code within image-bmc, they can set the program
counter (PC) to 0x100000000, just like how a manual loader set it to
0x43000000 (e.g., to jump directly to BL31). This allows users to
bypass the vbootrom if desired.
ok.
However, I believe this use case will be rare, as the vbootrom
design should be able to satisfy most, if not all, user
requirements.
We need to be careful about what we offer the user in terms of boot
method. It's difficult to maintain on the long term. Let's recap.
For the AST2[456]00 machines, we have :
1. kernel boot
2. flash device boot with or without "execute-in-place" machine
option
and this could work for AST2700 machines with some loader magic.
It would be good to decide to or not to support it. If not supported,
let's inform the user asap.
For the AST2600 ast2600evb and rainier machines only, we have :
3. emmc device boot
and we plan to extend it for AST2700 machines.
For the AST2700 machines, we have :
4. manual loader boot (this could work for the other SoCs, although
we have never tried)
5. firmware boot
We need to define a priority between these methods too (the list
above is more or less ordered, apart from 4.) and handle conflicts.
All of which is to say that the piece of code below will require
some care:
if (!bmc->mmio_exec) {
DeviceState *dev = ssi_get_cs(bmc->soc->fmc.spi, 0);
BlockBackend *fmc0 = dev ? m25p80_get_blk(dev) : NULL;
if (fmc0 && !boot_emmc) {
rom_size = memory_region_size(&bmc->soc->spi_boot);
aspeed_install_boot_rom(bmc, fmc0, rom_size);
} else if (emmc0) {
aspeed_install_boot_rom(bmc, blk_by_legacy_dinfo(emmc0), 64 * KiB);
}
}
if (amc->vbootrom) {
rom_size = memory_region_size(&bmc->soc->vbootrom);
aspeed_load_vbootrom(machine, rom_size, &error_abort);
}
Thanks,
C.
