On 1/7/23 19:55, Simon Glass wrote:
Hi Jerome,
On Thu, 22 Dec 2022 at 15:20, Jerome Forissier jerome.forissier@linaro.org wrote:
On 12/22/22 21:23, Simon Glass wrote:
(dropping the two bounces from cc)
On Thu, 22 Dec 2022 at 13:18, Simon Glass sjg@chromium.org wrote:
Hi Jerome,
On Thu, 22 Dec 2022 at 08:36, Jerome Forissier jerome.forissier@linaro.org wrote:
On 12/22/22 00:07, Simon Glass wrote:
OP-TEE has a format with a binary header that can be used instead of the ELF file. With newer versions of OP-TEE this may be required on some platforms.
Add support for this in binman. First, add a method to obtain the ELF sections from an entry, then use that in the FIT support. We then end up with the ability to support both types of OP-TEE files, depending on which one is passed in with the entry argument (TEE=xxx in the U-Boot build).
So, with:
BL31=/path/to/bl31.elf TEE=/path/to/tee.bin make -C u-boot \ CROSS_COMPILE=aarch64-linux-gnu- CC=aarch64-linux-gnu-gcc \ HOSTCC=gcc BINMAN_DEBUG=1 BINMAN_VERBOSE=4
...I get:
Entry '/binman/simple-bin/fit/images/@tee-SEQ/tee-os' marked absent: uses v1 format which must be in a FIT
OK, this is expected. It means that the contents are not provided. I will add some more comments.
We can refine this later, but we are a year into this conversion of rk3399 to binman and I really want to land this right away before I lose interest and it sits here for another year.
I commented that in my other reply. That would break my use case.
Do you have an influence on OP-TEE?
I am one of the core maintainers ;)
I think the way they are adding a header here is a really back idea. We should look at packaging these blobs in a FIT complete with all the metadata that is needed, with a standard schema.
Isn't that what this patch series is trying to accomplish? Using a different tool (binman instead of a custom python script) to package a blob into a FIT? As I said in my other reply, tee.bin is the output of the OP-TEE build, it has to be loaded in memory at a specific address, that you can discover be reading the binary itself -- no need for metadata... How infrequent is such a use case for a bootloader? to deal with? :O
Thanks,