EL switching

[AALLeeXXX]

Hello

I still struggle to dynamically change the EL with my PI3 in AARCH64. (If I do it at boot from reset, I can enter EL2 or EL1 successfully, no pb here).
I start the ARM in 64bits at EL3 and keep it at this level. Then I want to dynamically switch to EL2. So, I call HVC #0.

This triggers the Sync Exception of EL3 as expected with EC = 0b010110, meaning HVC call in 64 bits. This is still ok here.
In this exception handler, I modify SPSR_EL3 EL bits to EL2, then after some debug prints (serial terminal), I leave the exception handler with an ERET.
But, as soon as the above exception handler returns, another exception is fired, that one vector 0x480, 'IRQ 64 bits from lower EL' still at EL3.
That IRQ, I have no idea why it is triggered ! IRQ are disabled in my startup. It seems this exception comes from EL2, but I cannot find out why and cannot clear it : so it fires continuously...

I know I don't give much details but just as it, is there anything obviously wrong ? And how can I find out the reason of the IRQ ? I'm not sure I can rely on the EC for an IRQ (I checked it in case, but it returns the same value in the IRQ as in the Sync exception).

Thank you for any idea / advice...

[bzt]

Hi,

As I haven't seen your code, I'm not sure, but I suspect you don't need HVC. That would create a new exception context, therefore all ERET does is returning from there to the original EL3. You need to just return (after setting up system registers of course). I've an example code for that here (tbh only tested with a hacked qemu, not on real hardware, but should be fine). The exception you're getting may be caused by inproperly set up vbar or scr register (again, haven't seen your code, just guessing).

Hope this helps,
bzt

[AALLeeXXX]

Hello Bzt,

Thank you for your highlights and guidance.
I finally found out what happened.. and this was not related to EL change directly, but instead, I triggered a trapped access to SIMD and FP features which I did not catch properly ! Thus even I entered in EL1, I could not 'see' it...
I did not get this trap in EL3 as this access is by default allowed in EL3 (but not in EL1). A fix in CPACR_EL1 made it !

Thanks again,
ALeX

[dpotop]

RPi3 newbie question: I thought RPi3 is at EL2 when control is given to kernel8.img. So, how come you're at EL3?

Dpotop

[bzt]

Hi,

RPi3 newbie question: I thought RPi3 is at EL2 when control is given to kernel8.img. So, how come you're at EL3?

If you put "kernel_old=1" in config.txt, then your kernel will be loaded at offset 0 (this part documented) and it will start at EL3 (this part not that much).

Cheers,
bzt

[LdB]

Take care all 4 cores enter at address 0x0 as basically that setting stops the bootstub being loaded and called. So core 1,2,3 won't be parked and all will kick at 0x0. So without the bootstubs running the ARM starts as per the ARM processor manual with all registers etc in the reset state which is why cores enter in EL3.

[dpotop]

Cool !
But is the VideoCore initialized if I boot at address 0?
Will it reply to mailbox requests?

Best,
Dpotop

[rpdom]

Yes, the VC controls the start up of the ARMs, so it is already initialised by the time your code runs.