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
