Re: [PATCH v4 06/10] hw/arm/aspeed: Add support for loading vbootrom image via "-bios"

["Cédric Le Goater" <clg@kaod.org>]

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.