On 22/01/18 14:46, Andrew F. Davis wrote:
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.
This is not board-specific, this is the flow all ARM boards I know of use (except i.MX 6).
The OPTEE port I'm working with is i.MX 7, which chain-loads in this same way.
Is there some technical reason I am missing as to why you want to use this alternate flow?
The reason is the upstream OPTEE port we are working with already uses this bootflow.
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
I haven't used mkimage in a while, but how is this any different than what we do with the kernel image? Why do we need to pull this info out of the header when we don't do the same for Linux?
So for a kernel you are typically making a uImage of a compressed kernel image and therefore you have to pass load-address and entry point.
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux kernel" -d arch/arm/boot/zImage uImage
For the bootable OPTEE image case I'm proposing
1. A distinct image type 2. Based on that image type we validate the OPTEE header MAGIC, version, etc 3. Based on the OPTEE header we can validate the location the OPTEE binary gets loaded to.
Having a distinct image type makes it more robust.
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.
To me the save in this command (which should be handled automatically during the build process),
As above, it's about image generation, validation and load-address sanity checking.
I apologize for not making that clearer upfront - my bad, I'll attempt to flesh-out the patch descriptions to make the logic clearer.
--- bod