hi, experts:
正在学习ARMv8 manual.
关于Aarch64/Aarch32，有几个问题：
假定一个ARMv8 SOC实现了4个EL：EL0 / EL1 / EL2 / EL3
1. Secure State下：从EL3 Aarch64切换到Secure下的EL1 Aarch64
Target EL是EL1
SPSR_EL3[3:2] ：defined target EL
那么target EL1的execution state是由SPSR_EL3[4]确定的吗？
根据ARMv8 manual:
SPSR_EL3[4] : Register width that the exception was taken from, 并不是 exception was taken to啊？
有一些Doc讲：
EL1的execution state，应该由HCR_EL2.RW来确定，对吗？
2. 如果从Secure state EL3 Aarch64切换到Non-Secure EL1 Aarch64
仍然用SPSR_EL3吗？
best wishes,
On (1), the SPSR_ELn describes the state of the processor immediately before the exception. So bit [4] will tell the you the execution state you took the exception from.
On (2), yes you would still use SPSR_EL3. Security state for EL1/0 is controlled by SCR_EL3.NS.
hi, Martin:
Thanks for your reply!
On (1)
as you said, SPSR_ELn[4] labeled the cpu state which the exception taken from.
So, Could SPSR_ELn[4] be also used to label the target EL's execution state?
When you take an exception, SPSR_ELn[4] tells you the execution state you have come from.
When you return from an exception (using ERET), SPSR_ELn[4] tells the processor what execution state you are returning to.
When you take an exception, the execution state of the EL you take the exception to is controlled by registers (*). For example, you take a IRQ exception from non-secure EL0 to EL2. The execution state you arrive in EL2 as is controlled by SCR_EL3.RW. Similarly, if instead we'd take the exception to non-secure EL1, then the execution state we arrived in would be controlled by HCR_EL2.RW.
(* Apart from the highest implemented EL, typically EL3. The execution state of the highest implemented EL is fixed at reset)
Thanks a lot!
How about in secure state?
For example:
A SOC implements EL0/EL1/EL3 in secure state.
I want to switch to EL1-Aarch32 state from EL3-Aarch64 state, which register is used to set EL1's execution state?
Is it SCR_EL3[10]?
chinatiger wrote: I want to switch to EL1-Aarch32 state from EL3-Aarch64 state, which register is used to set EL1's execution state? Is it SCR_EL3[10]?
chinatiger wrote:
Yes. The SCR_EL3.RW bit controls the execution state of the next lowest EL. In the secure state, that would be EL1.
Is there any example code of going from AArch64 EL3 to AArch32 EL1? I'm trying to do this now with code similar to this, but I am aborting because the CPSR is incorrect after the eret.
mrs x0, currentel
cmp x0, #0xc
b.ne br_to_test
mov x0, #0x030 // RES1 field
tst x26, #0x1 // do we switch to 32-bit for lower EL's?
beq 1f
orr x0, x0, #0x400 // Lower EL's are AArch64
1:
orr x0, x0, #0x100 // HVC instruction enabled
msr scr_el3, x0
msr cptr_el3, xzr // don't trap to EL3
msr sctlr_el2, xzr
// setup some EL2 stuff
mrs x0, hcr_el2
orr x0, x0, #(1 << 31) // 64-bit EL1
msr hcr_el2, x0
msr ttbr0_el2, xzr // clear out the page table address for EL2
// Coprocessor traps.
mov x0, #0x33ff
msr cptr_el2, x0 // Disable copro. traps to EL2
msr hstr_el2, xzr // Disable CP15 traps to EL2 in AArch32
// now go to EL1 with eret
ldr w0, [x29, #0] // next image address
tst x26, #0x1
b.eq 1f // need to setup for 32-bit
mov x1, #0x3c5 // AArch64 - EL1h + D,A,I,F disabled
b 2f
1: mov x1, #0x10 // AArch32 - Supervisor + D,A,I,F disabled
2: msr elr_el3, x0
msr spsr_el3, x1
eret
An example would be something like this....
; Put SCTLRs for lower ELs into known state MSR SCTLR_EL2, XZR MSR SCTLR_EL1, XZR MSR SCR_EL3, XZR ; NS=0 (secure), RW=0 (next EL down is AArch32), SMD=0 (SMCs enabled), IRQ/FIQ=0 (not routed to EL3) ADR x1, <label in EL1> MSR ELR_EL3, x1 MOV x1, #0x13 (AArch32 SVC mode) MSR spsr_el3, x1 ERET
Hi Martin,
My understanding is: each EL in AArch64 state has a corresponding AArch32 state respectively, please correct me if I am wrong.
I've successfully switched the system from 64bit-EL3 to AArch32 mode. One question I am not sure about is: which EL the new AArch32 will run in? You know SPSR_EL3 only define that we will return to AArch32 mode and of course we can ensure that that will be a SVC mode AArch32 world. So when SCR.EL3.NS is 0, after "eret" instruction executes, how the system will determine the new EL number the new AArch32 mode will run in?
Thanks.
moonlight wrote: I've successfully switched the system from 64bit-EL3 to AArch32 mode. One question I am not sure about is: which EL the new AArch32 will run in? You know SPSR_EL3 only define that we will return to AArch32 mode and of course we can ensure that that will be a SVC mode AArch32 world. So when SCR.EL3.NS is 0, after "eret" instruction executes, how the system will determine the new EL number the new AArch32 mode will run in?
moonlight wrote:
Execution state can only change from AArch64 to AArch32 on an exception return. The SPSR_ELn defines the execution state (AArch32/AArch64) and the EL/mode (EL0/1/2/3 and for AArch32; SVC, ABT, IRQ, etc...) you will return to.
Thanks for the quick reponse. I am still a little confused...
When the system is switching from 64 to another 64, the current SPSR_EL can define the number of of the next new EL down. This is well described in ARMv8 manual.
When the system is switching from 64 to 32, the current SPSR_EL can define the mode(SVC, IRQ etc) of the forthcoming 32bit state. This is also well described in ARMv8 manual.
What I am not sure is: for the 2nd case above, if we switch from AArch64-EL3 to 32 bit mode, and SCR.EL3.RW = 0 and SCR_EL3.NS = 0, then will the new AArch32 mode run in EL1 or EL2?
Which EL you went into would depend on what value you had in SPSR_EL3 when you performed the ERET. So for example, if you had "0x13" in the bottom 5 bits, you would return to Secure SVC mode (S.EL1). Or, if you used "0x10" you would return to Secure User mode (S.EL0).
There is _no_ EL2 in Secure state (SCR_EL3.NS=0). If you had the bit pattern for Hyp mode (0x1A) it would trigger an illegal exception return exception.
EDIT: Forgot the all important "no" in the last line.
Thank you Martin, I think I get the answer now.
BR.