Hi Francesco,
Thanks for the patches!
On 2/28/26 12:37 AM, Francesco Valla wrote:
Hello,
this patchset adds the possibility to include arbitrary loadables in a
kernel FIT image and to define all associated parameters (description,
compression, type, arch, os, load address and entry address) through
variables.
Patch 1 simply extends the fitimage test infrastructure to allow
checking for existence of node properties regardless of their values,
while patch 2 contains the new functionality and associated tests,
The idea behind the proposal is to be able to generate FIT images for
complex boot flows, in which components beyond the Linux kernel, its FDT
and an initramfs need to be loaded before the aforementioned Linux
kernel is up and running.
As an example, the setup propose by Marek Vasut in [1] (boot of the
kernel through OP-TEE, with both components being loaded from a single
FIT by U-Boot) could be simply obtained with:
FIT_LOADABLES = "tee"
FIT_LOADABLE_DESCRIPTION[tee] = "OP-TEE"
FIT_LOADABLE_TYPE[tee] = "tee"
FIT_LOADABLE_ARCH = "arm"
FIT_LOADABLE_OS[tee] = "tee"
FIT_LOADABLE_LOADADDRESS[tee] = "0xde000000"
FIT_LOADABLE_ENTRYPOINT[tee] = "0xde000000"
while a more complex flow I'm experimenting on (boot of the OP-TEE and
the kernel through TF-A on the i.MX93, with all components being loaded
from a single FIT by U-Boot SPL after verification) as:
FIT_LOADABLES = "atf tee"
FIT_LOADABLE_FILENAME[atf] = "bl31-imx93.bin"
FIT_LOADABLE_DESCRIPTION[atf] = "TF-A Firmware"
FIT_LOADABLE_TYPE[atf] = "tfa-bl31"
FIT_LOADABLE_OS[atf] = "arm-trusted-firmware"
FIT_LOADABLE_LOADADDRESS[atf] = "0x204E0000"
FIT_LOADABLE_FILENAME[tee] = "tee.bin"
FIT_LOADABLE_DESCRIPTION[tee] = "OP-TEE"
FIT_LOADABLE_TYPE[tee] = "tee"
FIT_LOADABLE_OS[tee] = "tee"
FIT_LOADABLE_LOADADDRESS[tee] = "0x96000000"
Being inside the FIT image, and part of all configurations, the
loadables can be in this way hashed and (optionally) signed and/or
encrypted with the same flow and key(s) already in place for the kernel.
The generated FIT image is compatible with the U-Boot FIT "full" boot
flow, which loads any component part of the "loadables" group after the
kernel, the fdt and the initramfs.
This looks good!
I guess, I could use this mechanism to replace my "boot-bundle" recipe
in meta-riscv
(https://github.com/riscv/meta-riscv/blob/master/recipes-bsp/u-boot/boot-bundle.bb).
The idea implemented by this recipe is to add the compressed kernel and
DTB to the FIT image loaded by the first stage bootloader (SPL), when
using a vendor SPL with MMC support and a mainline U-Boot that doesn't
have storage support yet. This way, the kernel and DTB are preloaded in
RAM by the SPL.
Using your mechanism, I should be able to add the bootloader binaries to
the kernel FIT image, to achieve the same result, but without a custom
recipe :)
Thanks
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#232133):
https://lists.openembedded.org/g/openembedded-core/message/232133
Mute This Topic: https://lists.openembedded.org/mt/118051508/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
