On 11/25/25 4:18 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.
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.
Done in V3
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.
[...]
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.
No worries, thank you for checking !
