[U-Boot] [U-Boot, v4, 07/11] spl: add support to booting with OP-TEE

Kever Yang kever.yang at rock-chips.com
Thu Jan 18 01:31:24 UTC 2018


Bryan,


On 01/18/2018 01:48 AM, Bryan O'Donoghue wrote:
>
>
> On 15/01/18 04:48, Peng Fan wrote:
>> On Mon, Jan 15, 2018 at 11:25:00AM +0800, Kever Yang wrote:
>>> Bryan,
>>>
>>>
>>> On 01/12/2018 11:10 PM, Bryan O'Donoghue wrote:
>>>>
>>>>
>>>> On 12/01/18 11:27, Philipp Tomsich wrote:
>>>>>> OP-TEE is an open source trusted OS, in armv7, its loading and
>>>>>> running are like this:
>>>>>> loading:
>>>>>> - SPL load both OP-TEE and U-Boot
>>>>>> running:
>>>>>> - SPL run into OP-TEE in secure mode;
>>>>>> - OP-TEE run into U-Boot in non-secure mode;
>>>>>>
>>>>>> More detail:
>>>>>> https://github.com/OP-TEE/optee_os
>>>>>> and search for 'boot arguments' for detail entry parameter in:
>>>>>> core/arch/arm/kernel/generic_entry_a32.S
>>>>>>
>>>>>> Signed-off-by: Kever Yang <kever.yang at rock-chips.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v4:
>>>>>> - use NULL instead of '0'
>>>>>> - add fdt_addr as arg2 of entry
>>>>>>
>>>>>> Changes in v3: None
>>>>>> Changes in v2:
>>>>>> - Using new image type for op-tee
>>>>>>
>>>>>>   common/spl/Kconfig     |  7 +++++++
>>>>>>   common/spl/Makefile    |  1 +
>>>>>>   common/spl/spl.c       |  9 +++++++++
>>>>>>   common/spl/spl_optee.S | 13 +++++++++++++
>>>>>>   include/spl.h          | 13 +++++++++++++
>>>>>>   5 files changed, 43 insertions(+)
>>>>>>   create mode 100644 common/spl/spl_optee.S
>>>>>>
>>>>>
>>>>> Acked-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com>
>>>>> _______________________________________________
>>>>> U-Boot mailing list
>>>>> U-Boot at lists.denx.de
>>>>> https://lists.denx.de/listinfo/u-boot
>>>>>
>>>>
>>>> Kever, Philipp
>>>>
>>>> I have patches that define a IH_TYPE_OPTEE as a bootable OPTEE
>>>> image (one that never returns to u-boot).
>>>
>>> I don't understand how you use OP-TEE in your project.
>>> You are using U-Boot 'bootm' cmd to run into OP-TEE and 'PC' never
>>> get out of the OP-TEE os?
>>> The upstream OP-TEE will always be back to the pointer in 'lr'.
>>>
>>> We are using boot flow like ARMv8 for OP-TEE in armv7, could you
>>> introduce your flow?
>>
>> The flow is ROM->U-Boot->OP-TEE->Linux.
>
> Hi Kever, this got buried in my mailbox...
>
> Which I believe is the preferred flow for armv7
>
> That said - if you look at the TI commits for IH_TYPE_TEE I believe 
> *that* is the appropriate type for what you are doing with SPL.
>
> As I read the TI code the TEE is installed into memory - jumped into 
> and returned out of, which is the model you are using with SPL here.
>
> Basically that's what 
> arch/arm/mach-omap2/sec-common.c::secure_tee_install() does.
>
> So, I think the SPL solution you have can co-exist quite easily with 
> the model we have described above for imx7.
>
> My only suggestion here is that you probably don't need to define a 
> new image type for SPL - you can reuse IH_TYPE_TEE for SPL as below.

I don't think we can reuse IH_TYPE_TEEļ¼Œ it use a optee.img type create 
by mkimage and it seem use more then one cpu.
We use fit to pack uboot and optee into one itb file, and we use only 
one cpu now.
I may prefer to use what I have send with the type update to 
IH_TYPE_OPTEE_SPL.

Thanks,
- Kever
>
> Other than that I think the SPL/bootm or indeed the TI method of 
> installing a TEE are entirely able to (and should) live side-by-side.
>
>>>> +#if CONFIG_IS_ENABLED(OPTEE)
>>>> +    case IH_TYPE_TEE:
>>>> +        debug("Jumping to U-Boot via OP-TEE\n");
>>>> +        spl_optee_entry(NULL, NULL, spl_image->fdt_addr,
>>>> +                (void *)spl_image.entry_point);
>>>> +        break;
>>>> +#endif
>




More information about the U-Boot mailing list