[U-Boot] [PATCH v4 2/9] efi_loader: AArch64: Run EFI payloads in EL2 if U-Boot runs in EL3

[york sun]

On 06/21/2016 10:44 PM, Alexander Graf wrote:
>
>
> On 21.06.16 20:02, york sun wrote:
>> On 06/21/2016 10:55 AM, Alexander Graf wrote:
>>>
>>>
>>>> Am 21.06.2016 um 19:12 schrieb york sun <york.sun at nxp.com>:
>>>>
>>>>> On 06/20/2016 04:07 PM, Alexander Graf wrote:
>>>>> Some boards decided not to run ATF or other secure firmware in EL3, so
>>>>> they instead run U-Boot there. The uEFI spec doesn't know what EL3 is
>>>>> though - it only knows about EL2 and EL1. So if we see that we're running
>>>>> in EL3, let's get into EL2 to make payloads happy.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>>>> ---
>>>>>    arch/arm/include/asm/armv8/mmu.h | 19 ++++++++++++-------
>>>>>    cmd/bootefi.c                    | 11 +++++++++++
>>>>>    2 files changed, 23 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
>>>>> index 0d08ed3..876a2b2 100644
>>>>> --- a/arch/arm/include/asm/armv8/mmu.h
>>>>> +++ b/arch/arm/include/asm/armv8/mmu.h
>>>>> @@ -116,19 +116,24 @@
>>>>>    static inline void set_ttbr_tcr_mair(int el, u64 table, u64 tcr, u64 attr)
>>>>>    {
>>>>>        asm volatile("dsb sy");
>>>>> -    if (el == 1) {
>>>>> +    switch (el) {
>>>>> +    case 1:
>>>>>            asm volatile("msr ttbr0_el1, %0" : : "r" (table) : "memory");
>>>>>            asm volatile("msr tcr_el1, %0" : : "r" (tcr) : "memory");
>>>>>            asm volatile("msr mair_el1, %0" : : "r" (attr) : "memory");
>>>>> -    } else if (el == 2) {
>>>>> -        asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
>>>>> -        asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
>>>>> -        asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
>>>>> -    } else if (el == 3) {
>>>>> +        break;
>>>>> +    case 3:
>>>>>            asm volatile("msr ttbr0_el3, %0" : : "r" (table) : "memory");
>>>>>            asm volatile("msr tcr_el3, %0" : : "r" (tcr) : "memory");
>>>>>            asm volatile("msr mair_el3, %0" : : "r" (attr) : "memory");
>>>>> -    } else {
>>>>> +
>>>>> +        /* We may switch to EL2 later, so set those too; fall through */
>>>>> +    case 2:
>>>>> +        asm volatile("msr ttbr0_el2, %0" : : "r" (table) : "memory");
>>>>> +        asm volatile("msr tcr_el2, %0" : : "r" (tcr) : "memory");
>>>>> +        asm volatile("msr mair_el2, %0" : : "r" (attr) : "memory");
>>>>> +        break;
>>>>
>>>>
>>>> This may be problematic. If we use secure memory for EL3, the MMU tables
>>>> have to be within the secure memory. But EL2 will not be able to access
>>>> it. I believe you have verified this patch set actually work. I am
>>>> curious how it work.
>>>
>>> That's a good question. I suppose the default config doesn't actually lock secure memory? Or doesn't go secure at all?
>>>
>>
>> The patch set using this secure memory is still pending. Our internal
>> team has been working on it. So the secure memory has been working. I am
>> sure I have put MMU tables in secure memory. You can verify by running
>> "bdi" command. It will show you the secure memory location. If you don't
>> see it, then you don't have secure memory setup. By default, it is enabled.
>
> Ok, yes, I do see secure memory there.
>
>> I remember I have done a test to access to the secure memory from
>> non-secure master and got an exception.
>>
>> Could your test run at EL2 without a proper MMU table? I don't remember
>> if the core would hang, or continue to run if fetching MMU table fails.
>
> So without this patch, U-Boot would just hang (or probably loop in
> delivering page faults) in the switch to EL2, before we even reach any
> EFI payload. I'm not sure why it does succeed in accessing the page
> tables though if they are indeed in secure memory.
>
> Maybe we should just turn the whole logic upside down. Switch from EL3
> to EL2 in very early init code and get people to just run ATF or some
> other self-contained trusted firmware (maybe even built as part of
> U-Boot) in EL3. Putting all of U-Boot into EL3 doesn't seem to much of a
> good idea either way, as there is a lot of code that has no business at EL3.
>
> Would that approach work for you as well?
>

Alex,

I think we can make this work. I have two patch pending. One is my 
rewriting MMU setup for FSL Layerscape SoCs. Another one is Zhiqiang's 
PPA patch. Once they are both merged, you can drop the change in 
set_ttbr_tcr_mair() and let dcache_disable() do the job. The latter one 
will call mmu_setup() to setup new tables for EL2.

York