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

[Joakim Tjernlund]

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 infinera.com> 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.

 Jocke

PS.
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,
> > 		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE
> > 
> > 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