[PATCH] mkimage: Add support for bundling TEE in mkimage -f auto

[Quentin Schulz]

Hi Marek,

On 11/25/25 3:20 PM, Marek Vasut wrote:
> On 11/25/25 11:07 AM, 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.
>>>
>>
>> Must be documented then please.
> 
> Where would you document this ? In the manpage ? Elsewhere ?
> 

Wherever the user can see it when using the tool. The manpage for sure 
yes. Maybe in the mkimage usage help string but I'm worried it'll make 
it harder to read.

Also, turns out that one really is supposed to use the raw binary format 
for OP-TEE OS (since 3.8.0). I had missed that part so it kinda makes 
sense to only support that, after all 3.8.0 is already 6 years old! 
Blobs from Rockchip do have a .bin extension so I assume they are raw 
binaries.

>>> [...]
>>>
>>>> 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?
>>>
>>
>> Same binary split.
>>

[...]

> 
> Neither of the binaries listed above is TEE ?
> 

Oopsies. Got distracted by reviewing both tf-a (already merged) and tee 
support in mkimage -f auto. So this applies to TF-A part only, where we 
(Rockchip) use the ELF file (for Rockchip blobs; maybe upstream TF-A is 
loadable in raw binary form as well?) and that is split by binman. Since 
one is supposed to use the raw bin for OP-TEE OS and that binman doesn't 
actually split this into multiple entries, this doesn't apply, sorry for 
the noise.

> I can imagine you can have tee header and something else bundled in the 
> fitImage, but for such more complex case, better use .its file to 
> describe it.

Fair.

Quentin