RD-1AE
This article explains how to upload firmware for the RD-1AE board in Arm Virtual Hardware.
Building
Follow instructions outlined in the documentation for building the Yocto-based firmware.
Assembly
The AVH "coreimg" is a simple ZIP archive that represents the firmware for a VM. The RD-1 AE is a complete architecture model that begins execution in the ROM, and as such requires all firmware elements as produced by the Yocto build. The relevant components of the build can be found at:
build/tmp_$type/deploy/images/fvp-rd-kronos/
Where $type is one of baremetal, virtualization, or systemready-glibc depending on which of the firmware use-cases targets was selected at build time. Within this directory you will find a host of useful build products, but the relevant ones for assembling the firmware are:
rss-flash-image-fvp-rd-kronos.wic | RSS boot flash
ap-flash-image-fvp-rd-kronos.wic | AP Flash
mmc-image-fvp-rd-kronos.wic | SD card
rss-nvm-image.bin | Lifecycle Manager OTP
$type-image-fvp-rd-kronos.wic / arm-systemready-ir-acs-fvp-rd-kronos.wic | System storage
encrypted_dm_provisioning_bundle.bin | DM provisioning firmware
encrypted_cm_provisioning_bundle_0.bin | CM provisioning firmware
rss-rom-image-fvp-rd-kronos.wic.nopt | RSS ROM
Each of these components plays a critical role in the boot architecture of the RD-1 AE. For more information about each element please see the official documentation linked above.
Download an official coreimg firmware container from AVH via the UI. This ZIP archive will be used as a starting point for updating with custom firmware. To do this, select the RD-1 AE in the AVH UI, select the firmware base you would like to use, and then select
Source Imageto download the archive. For the purposes of this document the downloaded file will be referred to asbaremetal-critical-application-monitoring-1.0.coreimg.Collect and rename the Yocto build products according to the following mapping
rss-flash-image-fvp-rd-kronos.wic | boot_flash
ap-flash-image-fvp-rd-kronos.wic | ap_flash
mmc-image-fvp-rd-kronos.wic | sdcard
rss-nvm-image.bin | lcm_otp
$type-image-fvp-rd-kronos.wic / arm-systemready-ir-acs-fvp-rd-kronos.wic | virtio_0
encrypted_dm_provisioning_bundle.bin | <unchanged>
encrypted_cm_provisioning_bundle_0.bin | <unchanged>
rss-rom-image-fvp-rd-kronos.wic.nopt | <unchanged>
The `mmc-*` file may be present only for certain firmware use-case targets. If not available then create an arbitrarily sized sdcard up to 4GiB. e.g.:
`$ truncate -s4GiB sdcard`
First, we need to pack the ROM and the CM/DM provisioning firmware bundles into a nested archive. These firmware components of the RD-1 AE are expected to be loaded into memory at specific addresses by a "debugger", or by the platform model. This nested archive contains scatter-gather instructions for how and where to load the relevant components. The resulting archive is just called `firmware`.
```text
$ zip firmware encrypted_cm_provisioning_bundle_0.bin encrypted_dm_provisioning_bundle.bin rss-rom-image-fvp-rd-kronos.wic.nopt
adding: encrypted_cm_provisioning_bundle_0.bin (deflated 79%)
adding: encrypted_dm_provisioning_bundle.bin (deflated 95%)
adding: rss-rom-image-fvp-rd-kronos.wic.nopt (deflated 67%)
Finally, collect the downloaded coreimg, the firmware archive we just created, and the renamed build products into the same directory and use zip to update the contents of the relevant files within the parent container.
$ zip baremetal-critical-application-monitoring-1.0.coreimg firmware ap_flash boot_flash virtio_0 sdcard lcm_otp
updating: firmware (deflated 2%)
updating: sdcard (deflated 98%)
updating: virtio_0 (deflated 85%)
updating: boot_flash (deflated 98%)
updating: ap_flash (deflated 98%)
updating: lcm_otp (deflated 100%)
If desired, you may change the metadata contents of the Info.json file (see zip -l <*.coreimg>). Most of the elements in this file should not be changed, but feel free to edit either Build and/or Version as you see fit. These changes are observable in the UI dashboard for your VM instance.
Known issues
The model presently must be built without SVE support as the underlying hardware AVH runs on is not yet compatible. To do this, apply the following patch to your RD-1 AE Yocto firmware checkout before building.
diff --git a/yocto/kas/base.yml b/yocto/kas/base.yml
index cc2481d..f985f3c 100644
--- a/yocto/kas/base.yml
+++ b/yocto/kas/base.yml
@@ -50,7 +50,7 @@ repos:
env:
TESTIMAGE_AUTO:
- SVE_DISABLE_FLAG:
+ SVE_DISABLE_FLAG: "1"
local_conf_header:
meta-kronos-error-qa: |
In addition, apply the following patch to disable PCI passthrough of an unmodeled AHCI PCI device. This is relevant only for the virtualization firmware targets.
diff --git a/yocto/meta-kronos/recipes-core/domu-package/domu-envs.inc b/yocto/meta-kronos/recipes-core/domu-package/domu-envs.inc
index 6ba5380..0367462 100644
--- a/yocto/meta-kronos/recipes-core/domu-package/domu-envs.inc
+++ b/yocto/meta-kronos/recipes-core/domu-package/domu-envs.inc
@@ -35,7 +35,7 @@ DOMU1_NUMBER_OF_CPUS ?= "2"
DOMU1_VCPU_PIN ?= "cpus = [\"1-2\"]"
DOMU1_MPAM ?= "mpam = [\"slc=0xc0\"]"
DOMU1_SVE ?= "sve = \"${DOMU_SVE_SETTING}\""
-DOMU1_PCI_PASSTHROUGH ?= "pci = [\"${DOMU1_PCI_ID}\"]"
+DOMU1_PCI_PASSTHROUGH ?= ""
DOMU1_EXTRA ?= "${DOMU1_BRIDGES}\\n${DOMU1_VCPU_PIN}\\n${DOMU1_MPAM}\\n${DOMU1_SVE}\\n${DOMU1_PCI_PASSTHROUGH}\\n"
DOMU2_BRIDGES ?= "vif = ['script=vif-openvswitch,bridge=ovsbr0,vifname=domu2.ext0', 'script=vif-openvswitch,bridge=brsi0.100,vifname=domu2.ethsi0', 'script=vif-openvswitch,bridge=brsi1.200,vifname=domu2.ethsi1', 'script=vif-openvswitch,bridge=brsi2.300,vifname=domu2.ethsi2']"