[U-Boot] [PATCH v2 6/9] tools: mkimage: add optee image type

[Bryan O'Donoghue]

On 19/01/18 20:14, Andrew F. Davis wrote:
> On 01/19/2018 01:43 PM, Bryan O'Donoghue wrote:
>> This patch adds support for bootable OPTEE images to mkimage. Currently
>> there is a (Trusted Execution Environment) TEE image type, the TEE image
>> type is installed to a memory location with u-boot continuing to own the
>> boot process whereas the OPTEE image type defined here is a bootable image,
>> which typically wants to live at a defined location in memory. Defining a
>> new image type allows us to pull out the load address and entry point
>> defined in the OPTEE header and having a separate image type lays the
>> foundation for a subsequent patch to validate the OPTEE memory defined in a
>> board-port matches the link location specified in the OPTEE bootable
>> image.
>>
>> example usage:
>>

>> uTee.optee
>>
>> making a separate image type means you don't need to specify things like
>> entry point and load address as you would if you were defining the OPTEE
>> image as a linux image.
>>
> 
> I'm still not getting the reasoning for this all, you can have the load
> address checks and relocation stuff inside your loadable handler:
> 
> U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process
Hi Andrew,

As I understand it, that's a board-specific method, which wants to 
install a TEE (jump into a TEE and return to u-boot), whereas the aim 
with this patch-set is to chain-load and boot via TEE - OPTEE in this case.

I should make that clearer in the patch text description.

The example from Peng Fang

>> mkimage -A arm -O linux -C none -a 0x9c0fffe4 -e 0x9c100000 -d
>> ./out/arm-plat-imx/core/tee.bin uTee

is then simplified down to this

 >> mkimage -A arm -T optee -C none -d ./out/arm-plat-imx/core/tee.bin

and remove the requirement to pass load and entry point on the command line.

The boot-flow looks like this

BootROM -> u-boot {load kernel, dtb, optee} -> OPTEE -> Kernel

Whereas - as I understand it the flow on the TI examples you have is

BootROM -> u-boot {load kernel, dtb, TEE} -> TEE -> u-boot -> Kernel

Note: I do believe IH_TYPE_TEE is the right type to use for Kever's 
patch with the SPL - because again as I understand it - the model is

BootROM -> SPL -> Install TEE -> u-boot -> etc

---
bod