ARM A53 and initial MMU mapping for EL0/1/2/3 ?

Joakim Tjernlund Joakim.Tjernlund at
Wed Feb 9 09:35:04 CET 2022

On Wed, 2022-02-09 at 00:33 +0000, Andre Przywara wrote:
> On Tue, 8 Feb 2022 22:05:00 +0000
> Joakim Tjernlund <Joakim.Tjernlund at> wrote:
> Hi Joakim,
> > Trying to figure out how I should map the MMU for normal RAM so it acessible
> > from all ELx security states.
>        ^^^^^^^
> This does not make much sense. U-Boot is typically running in one
> exception level only, and sets up the page table for exactly that EL.
> Each EL uses a separate translation regime (with some twists for stage
> 2 EL2 and combined EL1/0, plus VHE). If you map your memory in EL3, then
> drop to EL2, the EL3 page tables become irrelevant.
> So in U-Boot we just set up the page tables for the EL we are running
> in, and leave the paging for the lower exception levels to be set up at
> the discretion of our payloads (kernels, hypervisors).
> Please not that *secure* memory is a separate concept, and handled by
> external hardware, typically using regions, not page tables.

I am a beginner w.r.t ARM and Secure/Non secure so thank you for above.

The problem I have is that I boot a custom SOC into u-boot and when u-boot tries
to boot linux I get an error exception when u-boot calls armv8_switch_to_el2 to enter linux.
I think the exception means "Instruction Abort taken without a change in Exception level."
I was thinking it could be some privilege missing in MMU map.
Note that kernel boots from a different memory region than u-boot but those two regions
are mapped the same way.


I can cheat/hack u-boot to branch to the linux kernel address and that works until kernel
tries to switch EL.

> > So far I have this mem_map: 
> > 
> > 		/* memory mapped RAM. 32MB  */
> > 		.virt = 0x60000000UL,
> > 		.phys = 0x60000000UL,
> > 		.size = 0x02000000UL,
> > 
> > but starting to doubt that is correct, can someone suggest what to put in the .attrs field?
> Those are the correct attributes for normal ("cache-able") memory.
> However you probably need at least another mapping for MMIO accesses,
> which MUST NOT be cacheable (MT_DEVICE_NGNRNE), but device memory.
> See the beginning of arch/arm/mach-sunxi/board.c for an example.
> Cheers,
> Andre

More information about the U-Boot mailing list