[PATCH] mkimage: Add support for bundling TEE in mkimage -f auto
Marek Vasut
marek.vasut at mailbox.org
Mon Nov 24 20:23:58 CET 2025
On 11/24/25 4:05 PM, Quentin Schulz wrote:
Hello Quentin,
>> Example invocation:
>> "
>> $ mkimage -E -A arm -C none -e 0xc0008000 -a 0xc0008000 -f auto \
>> -d arch/arm/boot/zImage \
>> -b arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dtb \
>> -z ../optee_os/out/arm-plat-stm32mp1/core/tee-raw.bin \
>> -Z 0xde000000 \
>> /path/to/output/fitImage
>> "
...
> Which formats are supported for the --tee-file parameter? OP-TEE OS
> itself has multiple versions for the binary header (v1 and v2?) and we
> can pass either a binary (tee.bin) or an ELF (tee.elf) in binman, c.f.
> tools/binman/etype/tee_os.py
The raw binary only, see the example invocation above.
[...]
> OK so... On Rockchip we have TF-A and OP-TEE OS split in multiple
> entries with different load addresses (see @atf-seq and @tee-seq in
> arch/arm/dts/rockchip-u-boot.dtsi). I guess this means we wouldn't be
> able to use this auto FIT?
Are those multiple "versions" of these binaries or are those really
separate parts of a single binary ? The later seems a bit odd. Do you
have an example of such configuration?
Note that you could include multiple TFA BL31/TEE binaries in fitImage,
but to support that from command line would probably be overloading
mkimage -f auto already.
...
The rest, I hope, is addressed in V2.
More information about the U-Boot
mailing list