[U-Boot] [PATCH v4 08/12] doc: TEE: Add documentation describing TEE in u-boot

Dr. Philipp Tomsich philipp.tomsich at theobroma-systems.com
Mon Feb 26 14:56:02 UTC 2018


Bryan,

> On 26 Feb 2018, at 15:39, Bryan O'Donoghue <bryan.odonoghue at linaro.org> wrote:
> 
> 
> 
> On 26/02/18 13:53, Dr. Philipp Tomsich wrote:
>>> +  To identify this type of image to u-boot you should use mkimage like this:
>>> +
>>> +  mkimage -A arm -T tee -C none -d tee-image.bin uTee-standalone
>> The type should be “tee-standalone” to avoid confusion with the boot-through
>> variety.
> 
> Eh, I actually agree with you.
> 
> I was thinking that making the change from "tee" to "tee-standalone" and might break things for people with their continuous-integration jobs/scripts etc.
> 
> So I was going to send out an "RFC" patch changing "tee" to "tee-standalone".
> 
> I'm just as happy to make the name change in this set if it's an agreed thing with Tom and Andrew though.
> 
>>> +
>>> +- "tee-bootable"
>>> +
>>> +  mkimage -A arm -T tee-bootable -C none -d tee.bin uTee-bootable
> 
>> Bootable doesn’t really describe this: both the -standalone and this version of
>> the OPTEE are bootable, but the difference is that this variant also contains the
>> next-stage payload. Either we keep Tom’s proposed -combo naming or we can
>> try to describe this as a “tee-with-payload” type.
> 
> Hmm - I thought Tom had suggested
> 
> "tee" - stays as is because that's what it's already called.
> "tee-standalone" - which I've called "tee-bootable"
> 
> and then there was a potential addition "tee-combo" covering what Kever may or may not do with his SPL implementation.
> 
> but I opted for "tee-bootable" instead of "tee-standalone"..
> 
> I think we need two decisions here:
> 
> #1 Exiting:
> "tee" - stay as
> "tee-standalone" - new name more obvious - adds churn into mkimage namespace
> 
> #2 Bootable OPTEE (chainload):
> "tee-bootable"
> "tee-chainload"
> "tee-with-payload" (not so sure about this myself)
> 
> Tom, Philipp, Andrew ?

Now, I am confused.

I thought there’s only two different paths: the one where the TEE is “installed” as
a secure OS (and then returns control to the bootloader) and the other one where
control os passed to the TEE and it “boot-through" into a next stage (whether a full
U-Boot or Linux).

The “boot-through” approach would be similar to what ATF does ...

Regards,
Philipp.



More information about the U-Boot mailing list