@@ -458,7 +458,10 @@ EOF
};
EOF
if [ "${UBOOT_FIT_TEE}" = "1" ] ; then
- conf_loadables="\"tee\", ${conf_loadables}"
+ # Listed behind U-Boot: an SPL handing off to the ARM Trusted
+ # Firmware only describes the images it loaded to the next stage
+ # once it has loaded the one it appends the device tree to.
+ conf_loadables="${conf_loadables}, \"tee\""
uboot_fitimage_tee
fi
@@ -1798,7 +1798,7 @@ class UBootFitImageTests(FitImageTestCase):
'entry = <%s>;' % bb_vars['UBOOT_FIT_TEE_ENTRYPOINT'],
'compression = "none";',
]
- loadables.insert(0, "tee")
+ loadables.append("tee")
if bb_vars['UBOOT_FIT_ARM_TRUSTED_FIRMWARE'] == "1":
its_field_check += [
'description = "ARM Trusted Firmware";',
@@ -1850,7 +1850,7 @@ class UBootFitImageTests(FitImageTestCase):
}
}
if bb_vars['UBOOT_FIT_TEE'] == "1":
- loadables.insert(0, "tee")
+ loadables.append("tee")
req_sections['tee'] = {
"Type": "Trusted Execution Environment Image",
# "Load Address": bb_vars['UBOOT_FIT_TEE_LOADADDRESS'], not printed by mkimage?
uboot_fitimage_assemble() prepends the TEE image to the "loadables" property of the configuration, which puts it ahead of U-Boot. That order is not only cosmetic. An SPL that hands off to the ARM Trusted Firmware (CONFIG_SPL_ATF) describes the images it loaded to the next stage through the /fit-images node of the device tree it passes on, and common/spl/spl_fit.c only records a loadable there once spl_image->fdt_addr is set. That happens when it loads an image os_takes_devicetree() accepts, which is U-Boot. Images listed ahead of U-Boot are therefore loaded but never described, and spl_invoke_atf() in common/spl/spl_atf.c, which looks up the BL32 entry point by searching /fit-images for an IH_OS_TEE image, finds nothing. BL31 is then entered without a BL32 entry point and OP-TEE is never started. Append the TEE image instead, so that the assembled order becomes "atf", "uboot", "tee". This does not regress the configurations that work today: - Where U-Boot is the image selected as firmware, it is loaded before the loop over the loadables runs, so the device tree is already in place and every loadable is recorded whatever its position. This is the shape of the FIT that arch/arm/dts/imx8mm-u-boot.dtsi describes, with firmware = "uboot" and loadables = "atf", "tee". - Where the ARM Trusted Firmware is the firmware, U-Boot has to come first among the loadables, which is what this change produces. The binman description in arch/arm/dts/rockchip-u-boot.dtsi already ends up in that order: it selects fit,firmware = "atf-1", "u-boot" and generates the loadables from its images node, where the U-Boot entry precedes the OP-TEE one. - Nothing else in the SPL depends on the position of the TEE image. An arm32 OP-TEE image is recorded by spl_fit_image_record_arm32_optee() wherever it appears, and the fallback that takes the entry point from the first loadable only applies when the image selected as firmware carries none, while every image generated here is emitted with one. The images in the FIT and their contents are unchanged; only the order in which they are named in the property differs. Update the order the selftest expects accordingly. AI-Generated: Uses Claude Code Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com> --- meta/classes-recipe/uboot-sign.bbclass | 5 ++++- meta/lib/oeqa/selftest/cases/fitimage.py | 4 ++-- 2 files changed, 6 insertions(+), 3 deletions(-)