Re: Problem with Arm Mmu code in CpuDxe

[Kurt Kennett <Kurt.Kennett@microsoft.com>]

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
Attr ARM_MEMORY_REGION_ATTRIBUTE_DEVICE

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.

K2

-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] 
Sent: Wednesday, September 21, 2016 10:21 AM
To: Kurt Kennett <Kurt.Kennett@microsoft.com>
Cc: edk2-devel <edk2-devel@lists.01.org>
Subject: Re: [edk2] Problem with Arm Mmu code in CpuDxe

On 21 September 2016 at 17:09, Kurt Kennett <Kurt.Kennett@microsoft.com> 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 correctly.

What does your memory map look like?