The memory map is initialized via ArmConfigureMmu, which builds the initial 
translation tables.  This code is in 
ArmPkg\Library\ArmMmuLib\Arm\ArmMmuLibCore.c, and it does 
"FillTranslationTable()".  This occurs in PEI/SEC before MMU is first enabled.  
This code does not just use sections -- it uses PopulateLevel2PageTable to 
create page tables for regions that are not modulo 1MB in size.

The start of my memory map has:
Base 0x00000000
Size  0x00018000

Which is the only region that matters really.

I know the ArmMmuLib was recently changed/moved.  Perhaps this is a side effect 
of that change?  Can the mover of that code comment?

It seems strange that Arm's code would set itself up one way but then assume 
another setup.


-----Original Message-----
From: Ard Biesheuvel [] 
Sent: Wednesday, September 21, 2016 10:21 AM
To: Kurt Kennett <>
Cc: edk2-devel <>
Subject: Re: [edk2] Problem with Arm Mmu code in CpuDxe

On 21 September 2016 at 17:09, Kurt Kennett <> wrote:
> I am having a problem on my system (assert), and during investigation I may 
> have found a problem with the Arm CpuDxe Mmu code that may affect all ARM 
> platform users.
> CpuDxeInitialize is the entry point, and pretty soon after entry it does:
>   SyncCacheConfig (&mCpu);
> This calls into:
>   ArmPkg\Drivers\CpuDxe\Arm\Mmu.c
> The code asserts that the Mmu is enabled, gets the memory space map, then 
> starts to process the page tables by getting the TTBR0 base address.

Before the assert, there is a comment that says

  // This code assumes MMU is enabled and filed [sic] with section translations

I don't know if this is a reasonable thing to assume, and how you end up 
violating this assumption, but it does explain why the code does not work 

What does your memory map look like?
edk2-devel mailing list

Reply via email to