[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