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.

On 28 January 2015 at 17:00, Varad Gautam varadgautam@gmail.com wrote:

On 01/27/15 at 11:44 AM Ard Biesheuvel ard.biesheuvel@linaro.org wrote:

...

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?

I'm using the same FD layout, I have switched to your version of MemoryInitPeiLib.

On 11 January 2015 at 17:23, Varad Gautam varadgautam@gmail.com wrote:

...

• arch/arm/boot/compressed/head.S: jump to zImage `mov pc, r3` fails,

although jump

...

to hard-coded relocated address (`ldr pc, =0x80008000`) works, 0x80008000

being the

...

new zImage location. Need help with calling convention - am I setting

*image_addr

...

correctly?

^ this problem still persists, except the zImage is now placed at 0x82000000; but I noticed that clearing (or changing) r4 in head.S after `efi_entry` returns causes the kernel to boot and show early debug messages! I am figuring out what's causing this oddity.

---

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S @@ -166,6 +166,7 @@ efi_stub_entry: mov r2, sp @ pass pointer in r2 bl efi_entry ldr r3, [sp], #8 @ get new zImage address from stack

•           mov r4, #0x00           @ doing this strangely boots the kernel
  
            @ Check for error return from EFI stub.  r0 has FDT address
            @ or error code.
  

Nice bug! Do you have a git tree somewhere?