On 9 September 2015 at 17:42, Andrew Fish <af...@apple.com> wrote:
>
> On Sep 9, 2015, at 7:03 AM, Ard Biesheuvel <ard.biesheu...@linaro.org>
> wrote:
>
> On 9 September 2015 at 15:59, Laszlo Ersek <ler...@redhat.com> wrote:
>
> On 09/08/15 19:35, Ard Biesheuvel wrote:
>
> When executing on a LPAE capable 32-bit ARM platform, we support
> up to 40 bits of physical address space so set PcdPrePiCpuMemorySize
> accordingly.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
> ArmVirtPkg/ArmVirt.dsc.inc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index b49c1bfb8b04..c1b78be84e74 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -371,6 +371,9 @@ [PcdsFixedAtBuild.common]
> gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x80, 0x6d, 0x91, 0x7d,
> 0xb1, 0x5b, 0x8c, 0x45, 0xa4, 0x8f, 0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94}
> !endif
>
> +[PcdsFixedAtBuild.ARM]
> + gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|40
> +
> [Components.common]
> #
> # Networking stack
>
>
> Right, the "ArmPkg/Drivers/CpuPei/CpuPei.inf" builds the CPU HOB based
> on this, and then the DXE core determines the size of the GCD Memory
> Space Map's first (= "all is nonexistent") entry from that.
>
>
> Indeed. Otherwise, memory above 4 GB just gets ignored, which means
> its existence does not get advertised to the OS either.
>
>
> It should get advertised to the OS, that is why the memory map is
> EFI_PHYSICAL_ADDRESS. 32-bit x86 platforms can have a larger physical
> address space, than virtual. This was how it was done in the past.
>
> Plus, you probably don't have to care about any size increase in page
> tables that are allocated from the permanent PEI RAM (cf. SVN rev 17719).
>
>
> The 1:1 mapping only goes to 4 GB, so anything beyond that is never
> mapped anyway.
>
>
> This is the state when you hand off to the OS, but it is possible as part of
> the boot process to have a driver do some alternate mapping. This was done
> on x86 servers for a software based memory test for example.
>
OK, thanks Andrew. I have no idea if the 32-bit ARM MMU code would
deal with that at all (you would probably know better than I), but I
was just trying to get my 32-bit QEMU working with > 3 GB of memory.
So in patch #2, I needed to split the memory into two regions to get
the DXE core to handle it correctly, one below 4 GB and one above 4
GB. Is that expected?
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
