Hi Jerome,
On Fri, 9 Dec 2022 at 06:55, Jerome Forissier jerome.forissier@linaro.org wrote:
On 12/9/22 15:24, Quentin Schulz wrote:
Hi Simon,
On 12/8/22 18:32, Simon Glass wrote:
Hi Xavier,
On Fri, 9 Dec 2022 at 03:25, Xavier Drudis Ferran xdrudis@tinet.cat wrote:
El Thu, Dec 08, 2022 at 08:56:57AM +1300, Simon Glass deia:
@tee-SEQ {fit,operation = "split-elf";description = "TEE";type = "tee";arch = "arm64";os = "tee";compression = "none";fit,load;fit,entry;fit,data;tee-os {};};I don't know, I may likely have missed something here, but are you sure you're taking Jerome into account ?
https://urldefense.com/v3/__https://lists.denx.de/pipermail/u-boot/2022-July... https://urldefense.com/v3/__https://lists.denx.de/pipermail/u-boot/2022-Nove...
No, I have not done that. The patches mentioned are additions to a deprecated script!
I think there's a a possible misunderstanding here. I believe Jerome pointed out that make_fit_atf.py currently supports two formats for the tee binary and is asking if the implementation you're suggesting take care of that.
Yes, and I suspect the answer is no ;)
It introduces a new binary format which binman needs to decode...
Correct, but this was done to fix an assumption that has never been true in the first place: that OP-TEE's tee.elf file could be used by bootloaders as the TEE image. It happened to work in the past and it may still work depending on config options, but as described in [1], the introduction of ASLR broke that assumption. Here I am speaking only for OP-TEE, other TEEs may very well be supplied as ELF files of course.
[1] 348310233dac ("mach-rockchip: make_fit_atf.py: support OP-TEE tee.bin v1 format")
that will need to be added as a new type, I think, since it seems to use the filename suffix to decide what format it is in.
The suffix is a quick way to tell formats apart but some more precise detection code could be used instead if needed (telling if a file is ELF or is OP-TEE .bin can done by looking at the header). Or perhaps this information should be provided by the user?
If my aforementioned assumption is correct, that unfortunately would make this patch series a regression, making it a blocker.
Agreed. Unfortunately I am not familiar *at all* with binman (or u-boot in general), so I am not sure how I can help other than with testing. Or maybe someone can propose some rough patch and I would insert the missing bits? (i.e., parsing the OP-TEE header).
Hmm, OK. I will have to think of a sensible way to add this to binman.
I believe we should start thinking about standard ways to package these blobs, with the metadata needed to process them. It would be better than every project adding its own custom binary header IMO.
Regards, Simon