Hi Ard, > From: Ard Biesheuvel > Sent: Wednesday, September 21, 2016 4:50 PM > > On 21 September 2016 at 12:17, Laszlo Ersek <ler...@redhat.com> wrote: > > On 09/21/16 11:10, Bhupesh Sharma wrote: > >> 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 <ler...@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. > > > > No, that's incorrect. These PCDs don't capture the full picture about > > the "UEFI system memory limits". They just describe one initial > memory > > range; the one that will serve as the permanent PEI RAM. (In the PEI > > phase, one of the PEIMs discovers and installs the "permanent PEI > > RAM", which is one contiguous range, to be used by the rest of the > PEI phase. > > A bit later, the PEI core, the PEIMs, the HOBs etc (IIRC) are > migrated > > from the temporary PEI RAM to this "installed" permanent PEI RAM.) > > > > However, starting with the DXE phase, disjoint ranges of RAM are > > supported; they can be installed by either using the appropriate DXE > > services within DXE, or by producing appropriate HOBs still in PEI. > > > > > >> > >> How can we represent two discontiguous DDR regions in UEFI and make > >> the EDK2 code base use both - to create MMU mappings from? > > > > As I said, by producing the right HOBs in PEI or by calling the right > > DXE services in DXE. The actual range locations (= the fields of the > > HOBs or the arguments to the DXE services) depend on your platform. > > > > Regarding the MMU: I don't know. I had always believed that the DXE > > services should cover the MMU setup transparently, when new system > > memory ranges are added -- as long as they exist within the address > > space pre-announced by the CPU HOB --, but I do recall from another > > thread on the list that this wasn't the case on ARM. I don't know > why. > > > > I recently fixed a problem in the MMU code where the maximum size of > the VA range which is programmed into the MMU registers was based on > the initial memory size, and adding memory (or MMIO) ranges later would > cause problems. > > WIth the latest EDK2, adding memory may be done at any time, and will > be reflected in the 1:1 mapping in the MMU
Thanks. That looks promising. Can you please share the SHA-ID, commit-ID of this *MMU fixup* patch. Regards, Bhupesh _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
