(1) I intrrrupt the cpu in UEFI (EL2) by press enter key when the serial outputs the following message.
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.0(release):14b6608
NOTICE: BL1: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.0(release):14b6608
NOTICE: BL2: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL3-1
NOTICE: BL3-1: v1.0(release):14b6608
NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
The default boot selection will start in 9 seconds
[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
(2)I follow the tutorial(Running Bare-Metal code at EL3 on the Juno board) to switch to EL3.
(3)I modified the example project "startup_ARMv8_AArch64_with_AArch32_app" which is located in the example folder of DS5 installation folder.
It's aimed not to initial the GIC. I download the file "AArch64_startup.axf" at EL3.
(4)I set the PC to the entry point and set a breakpoint to the following "eret" instruction. I step the eret instuction when it runs to the breakpoint.
PC register changed to the value of "__main", but the CPSR is still EL3h. It failed to switch to SVC mode.
PS:I also run the program in the VE_AEMv8x4 Brae-Metal simulation envirionment and it successed to switch to SVC mode.
drop_primary_to_el1:
ldr x1, lit___main
msr ELR_EL3, x1
mov x1, #(AArch32_Mode_SVC | \
AARCH64_SPSR_F | \
AARCH64_SPSR_I | \
AARCH64_SPSR_A)
msr SPSR_EL3, x1
eret
The problem is why it failed to switch from EL3 to SVC mode.
Based on your description, it sounds like you've hit an illegal exception return. Mostly likely explanation is that the SCR_EL3/HCR_EL2 settings conflict with your SPSR value.
The RW bits in SCR_EL3 and HCR_EL2 control the execution state (AArch32 or AArch64) of lower ELs. If the SPSR value doesn't match the configured execution state, you get an illegal exception return.
Hi Martin:
1. Will illegal exception result in branching to vector table entry pointed by the VBAR ? The PC register changed to the value of __main rather than the vector table.
It seems that there isn't any illegal exception.
2.The following suggestion is from support <support@arm.com>.
Please can you confirm the following at the point that the ERET is executed:
1) SCR_EL3.RW is set to 1
2) HCR_EL2.RW is cleared to 0
3) SCTLR_EL2 is cleared to 0
4) SCTLR_EL1 is cleared to 0
3.I modified the code following the suggestion.
start64: //entry point
MRS X0, SCR_EL3
ORR X0, X0, #(1 << 10) // Set SCR_EL3.RW
MSR SCR_EL3, X0
MRS X1, HCR_EL2
AND X1, X1, #~(1 << 31) // Clear HCR_EL2.RW
MSR HCR_EL2, X1
MSR SCTLR_EL2, XZR
MSR SCTLR_EL1, XZR
ISB
//read the system control registers
mrs x1, SCR_EL3
mrs x2, HCR_EL2
mrs x3, SCTLR_EL2
mrs x4, SCTLR_EL1
drop_primary_to_el1_:
4.It also failed to switch from EL3 to SVC mode. The result is the same as last time.
Hello,
Please can you confirm the value defined for the 'AArch32_Mode_SVC' constant? It should be 0b10011. Note that this is a 5-bit constant, *NOT* a 4-bit constant.
It's possible that 'AArch32_Mode_SVC' has only been defined as 0b0011, which does correspond to AArch32 Supervisor mode, but that will fail to set bit M[4] of SPSR_EL3, which is required when performing an exception return to AArch32 state.
Ash.
View all questions in Arm Development Platforms forum