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:
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
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Wednesday, September 21, 2016 10:21 AM
To: Kurt Kennett <kurt.kenn...@microsoft.com>
Cc: edk2-devel <firstname.lastname@example.org>
Subject: Re: [edk2] Problem with Arm Mmu code in CpuDxe
On 21 September 2016 at 17:09, Kurt Kennett <kurt.kenn...@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:
> 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