No subject

don't have the ELF information at this point.

> =A02. The bootloader will select the first mode from the three listed
> =A0 =A0above which is supported by both the processor and the kernel to
> =A0 =A0be loaded, and transition the processor to that mode. =A0If this
> =A0 =A0involves dropping out of secure or hypervisor mode, it will put
> =A0 =A0those modes permanently beyond use.

I'm not considering this step because of my point above.

> =A03. The kernel will examine CPSR to determine which of the three
> =A0 =A0possibilities above has happened, and:
> =A0 (a) If started in monitor mode:
> =A0 =A0 =A0 * Grant access to everything to non-secure state
> =A0 =A0 =A0 * Set the non-secure copies of the various CP15 registers
> =A0 =A0 =A0 =A0 which don't have a sane value on cpu reset
> =A0 =A0 =A0 * Install a trivial monitor vector which unconditionally
> =A0 =A0 =A0 =A0 copies r0 to MVBAR and returns
> =A0 =A0 =A0 * Switch to non-secure Hyp mode (if available) and do (b),
> =A0 =A0 =A0 =A0 or non-secure Kernel mode (if Hyp mode not supported).
> =A0 (b) If started in Hyp mode:
> =A0 =A0 =A0 * Install a trivial hypervisor vector which unconditionally
> =A0 =A0 =A0 =A0 copies r0 to HVBAR and returns
> =A0 (c) Rest of startup.

Maybe we could allow (b) if SoC vendors don't provide a different API
to set the HVBAR. But it means that kernels not aware of this feature
would fail.

--=20
Catalin