| Message ID | 20260228-fit_loadables-v1-0-3027ec37930d@valla.it |
|---|---|
| Headers | show |
| Series | fitimage: add ability to include arbitrary loadables | expand |
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.
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. Regards, Francesco Valla [1] https://embedded-recipes.org/2025/images/slides/er-2025-vasut.pdf Signed-off-by: Francesco Valla <francesco@valla.it> --- Francesco Valla (2): oe-selftest: fitimage: allow relaxed node checks kernel-fit-image: support arbitrary loadables meta/classes-recipe/kernel-fit-image.bbclass | 33 ++++++++++++++++++ meta/conf/image-fitimage.conf | 18 ++++++++++ meta/lib/oe/fitimage.py | 30 +++++++++++++++++ meta/lib/oeqa/selftest/cases/fitimage.py | 50 +++++++++++++++++++++++++++- 4 files changed, 130 insertions(+), 1 deletion(-) --- base-commit: be8cdcf13a658e9e81ff2f7b71d1c8c37a920ce7 change-id: 20260227-fit_loadables-1f93b9c7a7f2 Best regards,