[U-Boot] [PATCH v15 07/10] arm64: core support

From: drambo <drambo@broadcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v15 07/10] arm64: core support
Date: Wed, 22 Jan 2014 17:06:26 -0800 (PST)	[thread overview]
Message-ID: <52E06B04.3020405@broadcom.com> (raw)
In-Reply-To: <1390436886.24905.539.camel@snotra.buserror.net>

On 14-01-22 04:29 PM, Scott Wood-2 [via U-Boot] wrote:
>
>
> On Tue, 2014-01-14 at 09:52 +0800, FengHua wrote:
>> hi bhupesh,
>>
>>> Hi David,
>>>
>>> In reference to my mail above, I see that the transition to EL2 (from EL3) which occurs very early
>>> in start.S needs to be changed on lines of the ARMv7 code, i.e. the EL2 transition should happen just
>>> before Linux is booted up by the u-boot.
>>>
>>> The reason for the same is that a no of ARM IPs like GIC, SMMU and TZPC/TZASC need to be configured to
>>> allow non-secure accesses from Linux world (which runs in EL1 mode). Adding the assembly code for all
>>> such IPs in 'setup_el3' function in start.S, will bloat the start.S and also increase the chances of a
>>> bug in the assembly code.
>>>
>>> Hence, I would like to propose a strategy to shift from EL3 to EL2 to some point in u-boot code after the
>>> C Run Time has been initialized (similar to present ARMv7 u-boot code).
>>>
>>> If you are ok with the same, I can try to send out some RFC patches rebased against your latest v16 code-base.
>>>
>>> Please let me know.
>>> Regards,
>>> Bhupesh
>>>
>> Actually, patch v16 did exception level switch in the way as you said. please review the code.
>> Both master and slaves switch to el2(el1) just before jumping to linux kernel. BTW,if any good conception please feel free to patch it.
>
> How would you handle running U-Boot under a secure firmware, or under a
> hypervisor?  Why not take the Linux approach of running most code in
> EL1, with exception handlers pointing at code to handle special
> situations (such as returning to EL2 before OS entry)?
>
> As for bloating start.S, could leaving EL3 be done in early C code
> rather than in early asm or late C code?  Or, bundle U-Boot with a tiny
> "insecure firmware" that provides the minimum functionality needed with
> similar APIs that would be used with real secure firmware.

Hi Scott,
Why is any EL3 code in u-boot at all? That's not the ARM ATF approach I 
believe but I'm not an expert in this. Please see 
http://lists.denx.de/pipermail/u-boot/2014-January/171581.html and 
(https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md 

See section "Normal World Software Execution")

Thanks.
Darwin

>
> -Scott
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172101.html
>
> To unsubscribe from [PATCH v15 00/10] arm64 patch, visit http://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=167751&code=ZHJhbWJvQGJyb2FkY29tLmNvbXwxNjc3NTF8LTQ0Nzc3MTIxNQ==
>

--
View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v15-00-10-arm64-patch-tp167751p172102.html
Sent from the U-Boot mailing list archive at Nabble.com.