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.
