On 26 January 2015 at 08:37, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 22 January 2015 at 17:41, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 22 January 2015 at 14:33, Olivier Martin olivier.martin@arm.com wrote:
I guess the reason why I initially did this 'hack' (mark the DRAM occupied by the FD as non-present) is because the DXE (or something else) was copying over the FD during the dispatching of the UEFI drivers. You might not see this issue with your implementation of MemoryInitPeiLib because UEFI drivers will be loaded way above the FD file. But the risk might still exist - except if the DXE core now takes care of this case.
So which part of the FD file would we still be using at DXE time? And couldn't we use ConvertPages() to turn it into boot services code instead of removing it entirely?
... or more specifically: when you did this 'hack', were you already using a compressed FV inside the FD? I guess decompressing the payload into RAM would eliminate any dependencies that would in fact exist when the DXE core loads module straight from the FD.
FYI my PrePi Xen port still boots correctly when I clear the entire FD area right before jumping into DXE core. I.e., using this patch
------>8--------- diff --git a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c index 9a1ef344df6e..db5aacaf7ffb 100644 --- a/EmbeddedPkg/Library/PrePiLib/PrePiLib.c +++ b/EmbeddedPkg/Library/PrePiLib/PrePiLib.c @@ -133,9 +133,19 @@ LoadDxeCoreFromFfsFile (
Hob = GetHobList (); if (StackSize == 0) { - // User the current stack - - ((DXE_CORE_ENTRY_POINT)(UINTN)EntryPoint) (Hob); + unsigned int trampoline[] = { + 0xd2a8011d, // mov x29, #0x40080000 + 0xd2a8051e, // mov x30, #0x40280000 + 0xa8817fbf, // stp xzr, xzr, [x29], #16 + 0xeb1e03bf, // cmp x29, x30 + 0x54ffffcb, // blt (. - 8) + 0x5800005e, // ldr x30, 0xc + 0xd63f03c0, // blr x30 + (INT32)EntryPoint, + (INT32)(EntryPoint >> 32) + }; + + ((DXE_CORE_ENTRY_POINT)(UINTN)trampoline) (Hob); } else {
// ------>8---------
So Varad, can you confirm that your port consists of a primary FV containing PrePi and a compressed secondary FV, which in turn contains all the other modules? If this is the case, I think it is safe to go with my version of the MemoryInitPeiLib and not remove the memory used by the FD from the memory map.
Cheers, Ard.