Introduce "aspeed_load_vbootrom()" to support loading a virtual boot ROM image
into the vbootrom memory region, using the "-bios" command-line option.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Tested-by: Nabih Estefan <nabihestefan@google.com>
---
 include/hw/arm/aspeed.h |  1 +
 hw/arm/aspeed.c         | 36 ++++++++++++++++++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h
index 973277bea6..2b8332a7d7 100644
--- a/include/hw/arm/aspeed.h
+++ b/include/hw/arm/aspeed.h
@@ -41,6 +41,7 @@ struct AspeedMachineClass {
     uint32_t uart_default;
     bool sdhci_wp_inverted;
     bool vbootrom;
+    const char *vbootrom_name;
 };
 
 
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index b70a120e62..7f11371f02 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -27,6 +27,7 @@
 #include "system/reset.h"
 #include "hw/loader.h"
 #include "qemu/error-report.h"
+#include "qemu/datadir.h"
 #include "qemu/units.h"
 #include "hw/qdev-clock.h"
 #include "system/system.h"
@@ -305,6 +306,34 @@ static void aspeed_install_boot_rom(AspeedMachineState *bmc, BlockBackend *blk,
                    rom_size, &error_abort);
 }
 
+/*
+ * This function locates the vbootrom image file specified via the command line
+ * using the -bios option. It loads the specified image into the vbootrom
+ * memory region and handles errors if the file cannot be found or loaded.
+ */
+static void aspeed_load_vbootrom(MachineState *machine, uint64_t rom_size,
+                                 Error **errp)
+{
+    AspeedMachineState *bmc = ASPEED_MACHINE(machine);
+    AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(machine);
+    const char *bios_name = machine->firmware ?: amc->vbootrom_name;
+    g_autofree char *filename = NULL;
+    AspeedSoCState *soc = bmc->soc;
+    int ret;
+
+    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+    if (!filename) {
+        error_setg(errp, "Could not find vbootrom image '%s'", bios_name);
+        return;
+    }
+
+    ret = load_image_mr(filename, &soc->vbootrom);
+    if (ret < 0) {
+        error_setg(errp, "Failed to load vbootrom image '%s'", bios_name);
+        return;
+    }
+}
+
 void aspeed_board_init_flashes(AspeedSMCState *s, const char *flashtype,
                                       unsigned int count, int unit0)
 {
@@ -483,6 +512,11 @@ static void aspeed_machine_init(MachineState *machine)
         }
     }
 
+    if (amc->vbootrom) {
+        rom_size = memory_region_size(&bmc->soc->vbootrom);
+        aspeed_load_vbootrom(machine, rom_size, &error_abort);
+    }
+
     arm_load_kernel(ARM_CPU(first_cpu), machine, &aspeed_board_binfo);
 }
 
@@ -1691,6 +1725,7 @@ static void aspeed_machine_ast2700a0_evb_class_init(ObjectClass *oc, void *data)
     amc->uart_default = ASPEED_DEV_UART12;
     amc->i2c_init  = ast2700_evb_i2c_init;
     amc->vbootrom = true;
+    amc->vbootrom_name = "ast27x0_bootrom.bin";
     mc->auto_create_sdcard = true;
     mc->default_ram_size = 1 * GiB;
     aspeed_machine_class_init_cpus_defaults(mc);
@@ -1712,6 +1747,7 @@ static void aspeed_machine_ast2700a1_evb_class_init(ObjectClass *oc, void *data)
     amc->uart_default = ASPEED_DEV_UART12;
     amc->i2c_init  = ast2700_evb_i2c_init;
     amc->vbootrom = true;
+    amc->vbootrom_name = "ast27x0_bootrom.bin";
     mc->auto_create_sdcard = true;
     mc->default_ram_size = 1 * GiB;
     aspeed_machine_class_init_cpus_defaults(mc);
-- 
2.43.0

On 4/17/25 05:12, Jamin Lin wrote:
> Introduce "aspeed_load_vbootrom()" to support loading a virtual boot ROM image
> into the vbootrom memory region, using the "-bios" command-line option.
> 
> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
> Reviewed-by: Nabih Estefan <nabihestefan@google.com>
> Tested-by: Nabih Estefan <nabihestefan@google.com>
> ---
>   include/hw/arm/aspeed.h |  1 +
>   hw/arm/aspeed.c         | 36 ++++++++++++++++++++++++++++++++++++
>   2 files changed, 37 insertions(+)
> 
> diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h
> index 973277bea6..2b8332a7d7 100644
> --- a/include/hw/arm/aspeed.h
> +++ b/include/hw/arm/aspeed.h
> @@ -41,6 +41,7 @@ struct AspeedMachineClass {
>       uint32_t uart_default;
>       bool sdhci_wp_inverted;
>       bool vbootrom;
> +    const char *vbootrom_name;

I don't think adding a class attribute for the default firmware
image file is that useful. A define should be enough :

     #define VBOOTROM_FILE_NAME  "ast27x0_bootrom.bin"

and use VBOOTROM_FILE_NAME when defining the bios_name variable.

Unless you already plan to have different default firmware files
for the ast27* machines ?


>   };
>   
>   
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index b70a120e62..7f11371f02 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -27,6 +27,7 @@
>   #include "system/reset.h"
>   #include "hw/loader.h"
>   #include "qemu/error-report.h"
> +#include "qemu/datadir.h"
>   #include "qemu/units.h"
>   #include "hw/qdev-clock.h"
>   #include "system/system.h"
> @@ -305,6 +306,34 @@ static void aspeed_install_boot_rom(AspeedMachineState *bmc, BlockBackend *blk,
>                      rom_size, &error_abort);
>   }
>   
> +/*
> + * This function locates the vbootrom image file specified via the command line
> + * using the -bios option. It loads the specified image into the vbootrom
> + * memory region and handles errors if the file cannot be found or loaded.
> + */
> +static void aspeed_load_vbootrom(MachineState *machine, uint64_t rom_size,
> +                                 Error **errp)
> +{
> +    AspeedMachineState *bmc = ASPEED_MACHINE(machine);
> +    AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(machine);
> +    const char *bios_name = machine->firmware ?: amc->vbootrom_name;
> +    g_autofree char *filename = NULL;
> +    AspeedSoCState *soc = bmc->soc;
> +    int ret;
> +
> +    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
> +    if (!filename) {
> +        error_setg(errp, "Could not find vbootrom image '%s'", bios_name);
> +        return;
> +    }
> +
> +    ret = load_image_mr(filename, &soc->vbootrom);
> +    if (ret < 0) {
> +        error_setg(errp, "Failed to load vbootrom image '%s'", bios_name);
> +        return;
> +    }
> +}
> +
>   void aspeed_board_init_flashes(AspeedSMCState *s, const char *flashtype,
>                                         unsigned int count, int unit0)
>   {
> @@ -483,6 +512,11 @@ static void aspeed_machine_init(MachineState *machine)
>           }
>       }
>   
> +    if (amc->vbootrom) {

what about the "aspeed.boot_rom" region ? Is it ok to have both ?


Thanks,

C.



> +        rom_size = memory_region_size(&bmc->soc->vbootrom);
> +        aspeed_load_vbootrom(machine, rom_size, &error_abort);
> +    }
> +
>       arm_load_kernel(ARM_CPU(first_cpu), machine, &aspeed_board_binfo);
>   }
>   
> @@ -1691,6 +1725,7 @@ static void aspeed_machine_ast2700a0_evb_class_init(ObjectClass *oc, void *data)
>       amc->uart_default = ASPEED_DEV_UART12;
>       amc->i2c_init  = ast2700_evb_i2c_init;
>       amc->vbootrom = true;
> +    amc->vbootrom_name = "ast27x0_bootrom.bin";
>       mc->auto_create_sdcard = true;
>       mc->default_ram_size = 1 * GiB;
>       aspeed_machine_class_init_cpus_defaults(mc);
> @@ -1712,6 +1747,7 @@ static void aspeed_machine_ast2700a1_evb_class_init(ObjectClass *oc, void *data)
>       amc->uart_default = ASPEED_DEV_UART12;
>       amc->i2c_init  = ast2700_evb_i2c_init;
>       amc->vbootrom = true;
> +    amc->vbootrom_name = "ast27x0_bootrom.bin";
>       mc->auto_create_sdcard = true;
>       mc->default_ram_size = 1 * GiB;
>       aspeed_machine_class_init_cpus_defaults(mc);

Hi Cedric, 

> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com
> Subject: Re: [PATCH v4 06/10] hw/arm/aspeed: Add support for loading
> vbootrom image via "-bios"
> 
> On 4/17/25 05:12, Jamin Lin wrote:
> > Introduce "aspeed_load_vbootrom()" to support loading a virtual boot
> > ROM image into the vbootrom memory region, using the "-bios"
> command-line option.
> >
> > Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
> > Reviewed-by: Nabih Estefan <nabihestefan@google.com>
> > Tested-by: Nabih Estefan <nabihestefan@google.com>
> > ---
> >   include/hw/arm/aspeed.h |  1 +
> >   hw/arm/aspeed.c         | 36
> ++++++++++++++++++++++++++++++++++++
> >   2 files changed, 37 insertions(+)
> >
> > diff --git a/include/hw/arm/aspeed.h b/include/hw/arm/aspeed.h index
> > 973277bea6..2b8332a7d7 100644
> > --- a/include/hw/arm/aspeed.h
> > +++ b/include/hw/arm/aspeed.h
> > @@ -41,6 +41,7 @@ struct AspeedMachineClass {
> >       uint32_t uart_default;
> >       bool sdhci_wp_inverted;
> >       bool vbootrom;
> > +    const char *vbootrom_name;
> 
> I don't think adding a class attribute for the default firmware image file is that
> useful. A define should be enough :
> 
>      #define VBOOTROM_FILE_NAME  "ast27x0_bootrom.bin"
> 
> and use VBOOTROM_FILE_NAME when defining the bios_name variable.
> 
> Unless you already plan to have different default firmware files for the ast27*
> machines ?
> 

If we plan to support the vbootrom feature for multiple ASPEED SoCs such as the AST28x0 series, it seems that the current default define
for the image name cannot be reused for both AST27x0 and future ASPEED SoCs. This is because the vbootrom file names differ between the two series.
That’s the reason I introduced a machine class attribute — to allow flexibility in specifying the correct vbootrom name for each SoC family.
I will use the DEFINE for now in the v5 patch. When we plan to support vbootrom for new SoCs in the future, we can revisit and discuss the appropriate default naming convention at that time.

> 
> >   };
> >
> >
> > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index
> > b70a120e62..7f11371f02 100644
> > --- a/hw/arm/aspeed.c
> > +++ b/hw/arm/aspeed.c
> > @@ -27,6 +27,7 @@
> >   #include "system/reset.h"
> >   #include "hw/loader.h"
> >   #include "qemu/error-report.h"
> > +#include "qemu/datadir.h"
> >   #include "qemu/units.h"
> >   #include "hw/qdev-clock.h"
> >   #include "system/system.h"
> > @@ -305,6 +306,34 @@ static void
> aspeed_install_boot_rom(AspeedMachineState *bmc, BlockBackend *blk,
> >                      rom_size, &error_abort);
> >   }
> >
> > +/*
> > + * This function locates the vbootrom image file specified via the
> > +command line
> > + * using the -bios option. It loads the specified image into the
> > +vbootrom
> > + * memory region and handles errors if the file cannot be found or loaded.
> > + */
> > +static void aspeed_load_vbootrom(MachineState *machine, uint64_t
> rom_size,
> > +                                 Error **errp) {
> > +    AspeedMachineState *bmc = ASPEED_MACHINE(machine);
> > +    AspeedMachineClass *amc =
> ASPEED_MACHINE_GET_CLASS(machine);
> > +    const char *bios_name = machine->firmware ?:
> amc->vbootrom_name;
> > +    g_autofree char *filename = NULL;
> > +    AspeedSoCState *soc = bmc->soc;
> > +    int ret;
> > +
> > +    filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
> > +    if (!filename) {
> > +        error_setg(errp, "Could not find vbootrom image '%s'",
> bios_name);
> > +        return;
> > +    }
> > +
> > +    ret = load_image_mr(filename, &soc->vbootrom);
> > +    if (ret < 0) {
> > +        error_setg(errp, "Failed to load vbootrom image '%s'",
> bios_name);
> > +        return;
> > +    }
> > +}
> > +
> >   void aspeed_board_init_flashes(AspeedSMCState *s, const char
> *flashtype,
> >                                         unsigned int count, int
> unit0)
> >   {
> > @@ -483,6 +512,11 @@ static void aspeed_machine_init(MachineState
> *machine)
> >           }
> >       }
> >
> > +    if (amc->vbootrom) {
> 
> what about the "aspeed.boot_rom" region ? Is it ok to have both ?
> 
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).
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

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.
However, I believe this use case will be rare, as the vbootrom design should be able to satisfy most, if not all, user requirements.

Thanks-Jamin

> 
> Thanks,
> 
> C.
> 
> 
> 
> > +        rom_size = memory_region_size(&bmc->soc->vbootrom);
> > +        aspeed_load_vbootrom(machine, rom_size, &error_abort);
> > +    }
> > +
> >       arm_load_kernel(ARM_CPU(first_cpu), machine,
> &aspeed_board_binfo);
> >   }
> >
> > @@ -1691,6 +1725,7 @@ static void
> aspeed_machine_ast2700a0_evb_class_init(ObjectClass *oc, void *data)
> >       amc->uart_default = ASPEED_DEV_UART12;
> >       amc->i2c_init  = ast2700_evb_i2c_init;
> >       amc->vbootrom = true;
> > +    amc->vbootrom_name = "ast27x0_bootrom.bin";
> >       mc->auto_create_sdcard = true;
> >       mc->default_ram_size = 1 * GiB;
> >       aspeed_machine_class_init_cpus_defaults(mc);
> > @@ -1712,6 +1747,7 @@ static void
> aspeed_machine_ast2700a1_evb_class_init(ObjectClass *oc, void *data)
> >       amc->uart_default = ASPEED_DEV_UART12;
> >       amc->i2c_init  = ast2700_evb_i2c_init;
> >       amc->vbootrom = true;
> > +    amc->vbootrom_name = "ast27x0_bootrom.bin";
> >       mc->auto_create_sdcard = true;
> >       mc->default_ram_size = 1 * GiB;
> >       aspeed_machine_class_init_cpus_defaults(mc);

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.

Hi Cedric,

> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@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.
> 

Hello Jamin,

+ Phil.

On 4/23/25 09:02, Jamin Lin wrote:
> Hi Cedric,
> 
>> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@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.


Thanks,

C.

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_lee@aspeedtech.com>; nabihestefan@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.

Thanks-Jamin

> 
> Thanks,
> 
> C.
> 
> 

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_lee@aspeedtech.com>; nabihestefan@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/

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_lee@aspeedtech.com>; nabihestefan@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