Re: Exporting discontiguous System Memory to EFI STUB

[Bhupesh Sharma <bhupesh.sharma@nxp.com>]

Thanks Ard, Laszlo.

See replies in-line:

> From: Ard Biesheuvel
> Sent: Thursday, September 15, 2016 5:01 PM
> 
> On 15 September 2016 at 10:01, Laszlo Ersek <lersek@redhat.com> wrote:
> > On 09/15/16 10:45, Sakar Arora wrote:
> >> Hi
> >>
> >> This is in aarch64 UEFI context.
> >>
> >> The efi stub code ignores any memory nodes in the device tree. It
> >> only relies on the UEFI memory map for memory info.
> >>
> >> In such a scenario, how can one export discontiguous regions of
> >> system memory to the efi stub? There seems to be only one way to
> >> inform UEFI about system memory, via PcdSystemMemoryBase.
> >>
> >> Looking at the latest Arm Juno code, it seems like building a memory
> >> resource descriptor hob, for the extra memory region, does the
> trick.
> >> Would that be the best way to go?
> >>
> >> Suggestions please.
> >
> > There are two ways.
> >
> > First, in the PEI phase, you can produce memory resource descriptor
> > HOBs that will describe system memory areas. When the DXE core
> starts,
> > it will convert the suitable HOBs to EfiGcdMemoryTypeSystemMemory
> > memory space. During DXE and BDS, boot/runtime code/data allocations
> > will be satisfied from these. Then the UEFI memmap will reflect those
> > allocations, and the system memory left unused, to the EFI stub.
> >
> > Second, you can add EfiGcdMemoryTypeSystemMemory memory space during
> > and after the DXE phase, explicitly, using the DXE services. (IIRC,
> > the PI spec says that memory space added this way may be picked by
> the
> > UEFI memory allocation system immediately; IOW, it may immediately
> > become available to the pool and page allocation boot serivces, to
> > allocate from. IIRC, in edk2 this actually happens.) The rest is the
> > same as above, wrt. the UEFI memmap.
> >
> > You can see an example for the second method under
> > "ArmVirtPkg/HighMemDxe". I think it might be particularly close to
> > your use case, as it practically translates the memory nodes found in
> > QEMU's
> > (copied) DTB to EfiGcdMemoryTypeSystemMemory memory space.
> >
> > (Ard, when do you plan to port this driver to FDT_CLIENT_PROTOCOL?
> :))
> >
> 
> Any day now :-)
> 
> But seriously, I think this is orthogonal to the question, since I
> don't expect that this platform uses DTB to describe the platform *to
> UEFI*, and it would not run any of the runtime DT probing code.
> 
> So in this particular case, it is simply a matter of adding the
> additional memory at any point during the execution of UEFI that is
> convenient, by using one of the two methods you describe.
> 

Yes, this platform, which has been extensively discussion on Linux mailing-lists
as well for discontiguous memory regions and their support in Linux (see [1]),
doesn't use DTB to describe the platform *to UEFI*.

However I have one generic question. At the moment we seem to use the PcdSystemMemoryBase
and PcdSystemMemorySize PCDs to convey to the PEI and DXE phases about the UEFI system
memory limits. 

How can we represent two discontiguous DDR regions in UEFI and make
the EDK2 code base use both - to create MMU mappings from?

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/435607.html

Regards,
Bhupesh