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. > > 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 AST2700, I am currently considering support for the following boot methods only: 1. eMMC device boot 2. UFS device boot (Note: QEMU currently only supports PCI-based UFS and does not support platform-based UFS. This remains a long-term goal) 3. Firmware boot using vbootrom 4. Firmware boot using a manual loader The boot flow for the AST2700’s Cortex-A35 should follow this sequence: BL31 (Trusted Firmware-A) → BL32 (OP-TEE OS) → BL33 (U-Boot) I don't think we should support direct kernel boot , as I don't know how to start execution directly from the kernel. By the way, AST2700 support to boot from either EMMC or UFS. I am considering to read OTP configs and strap instead of command line. Ex: we used bootmmc=true to change hardstrap. It just my briefly plane and future goal. Thanks-Jamin > 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. >
