Code: Select all
MONITOR: movw r9, 0x0130 mcr p15, 0, r9, c1, c1, 0 movs pc, lr
Within the context I was talking about, that's not true.AlfredJingle wrote:It is a misunderstanding that a reset is needed for going to monitor-mode.
Because it's possible to use a hypervisor that way. Some people wanted to do so: https://github.com/raspberrypi/firmware/issues/369dwelch67 wrote:Am I hearing that the operating systems. Linux, BSD, etc leave HYP mode as a first thing? If so why are the pis being switched into HYP mode to just go back out? Or am I misunderstanding?
Once you are in EL1 there is no way to get back into higher exception levels without the support of the software running there. So it's not unusual to boot in a higher EL. I didn't want to tell this.swarren wrote:Thus, the ARM stub switching to HYP mode isn't something that's there just to benefit a few unusual people, but rather is done to comply with the Linux booting rules/recommendations.
My AArch64 port of the Circle bare metal environment runs in EL1t (main thread, using sp_el0) and in EL1h (exception handlers, using sp_el1). Currently it expects to be booted in EL3. This has to be changed so that EL1, 2 or 3 are allowed.If you're writing some other OS for the Pi, it's best to fit into the standard ARM exception level usage, and run in EL1/system mode. That should work on any CPU/SoC and interact well with any other parts of the SW stack. It's quite unusual to run an OS (rather than a secure monitor, or secure OS on ARM32) in SVC/EL3.
That's not quite true.AlfredJingle wrote:to: dwelch
An OS has to leave hyp-mode as soon as possible after booting in order to set up the security registers and security related vectors and traps and what have you. This can only be done from a secure world. And hyp-mode is unsecure by definition. I have no clue why the pi is switched to hyp-mode. Just keeping it in secure supervisor mode seems to be easier for all.