All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Opdenacker <michael.opdenacker@rootcommit.com>
To: Francesco Valla <francesco@valla.it>,
	openembedded-core@lists.openembedded.org,
	Adrian Freihofer <adrian.freihofer@siemens.com>
Cc: michael.opdenacker@rootcommit.com,
	Marek Vasut <marek.vasut@mailbox.org>,
	Usama Arif <usama.arif@arm.com>
Subject: Re: [PATCH 0/2] fitimage: add ability to include arbitrary loadables
Date: Sun,  1 Mar 2026 10:44:55 +0000 (UTC)	[thread overview]
Message-ID: <d92e89bc-9abc-4a59-a59a-18de25747ee9@rootcommit.com> (raw)
In-Reply-To: <20260228-fit_loadables-v1-0-3027ec37930d@valla.it>

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



      parent reply	other threads:[~2026-03-01 10:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27 23:37 [PATCH 0/2] fitimage: add ability to include arbitrary loadables Francesco Valla
2026-02-27 23:37 ` [PATCH 1/2] oe-selftest: fitimage: allow relaxed node checks Francesco Valla
2026-03-01 14:20   ` [OE-core] " adrian.freihofer
2026-03-01 19:31     ` Francesco Valla
2026-02-27 23:37 ` [PATCH 2/2] kernel-fit-image: support arbitrary loadables Francesco Valla
2026-03-01 14:29   ` [OE-core] " adrian.freihofer
2026-03-01 10:44 ` Michael Opdenacker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d92e89bc-9abc-4a59-a59a-18de25747ee9@rootcommit.com \
    --to=michael.opdenacker@rootcommit.com \
    --cc=adrian.freihofer@siemens.com \
    --cc=francesco@valla.it \
    --cc=marek.vasut@mailbox.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=usama.arif@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.