On 06/21/2016 10:55 AM, Alexander Graf wrote:
Am 21.06.2016 um 19:12 schrieb york sun york.sun@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@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.
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.
York