Hi Ard,
This loads the fdt on c7ef4000 (which is more than a page). Changing the address from 0x7f00000 to 7EFF000, on the original code, works as well
Kernel's EFI map (with the patch) : [ 0.000000] efi: Processing EFI memory map: [ 0.000000] efi: 0x0000c0000000-0x0000c1ffffff [Boot Data | | | | | | | | |WB| | | ] [ 0.000000] efi: 0x0000c2000000-0x0000c2860fff [Loader Data | | | | | | | | |WB| | | ] [ 0.000000] efi: 0x0000c2861000-0x0000c7cf3fff [Conventional Memory| | | | | | | | |WB| | | ] [ 0.000000] efi: 0x0000c7cf4000-0x0000c7ef3fff [Loader Data | | | | | | | | |WB| | | ] [ 0.000000] efi: 0x0000c7ef4000-0x0000c7efffff [Runtime Data |RUN| | | | | | | |WB| | | ]
As an aside, putting the FDT in runtime data is not the right thing to do.
Runtime data sections are intended for data that is used by the runtime services implementations themselves, which is why they automatically get the EFI_MEMORY_RUNTIME attribute as well, and get mapped into the EFI runtime address space. They also get flagged as NOMAP regions, which means they get omitted from the linear map, which causes unnecessary page table fragmentation leading to more TLB pressure.
I recommend using boot services data here, or acpi reclaim if you are concerned about the OS not reserving the region correctly.
This also fixes my boot issue. I still think the initial analysis is right and this is still a kernel issue. Chaning the mem type to EFI_ACPI_RECLAIM_MEMORY removes the NOMAP flag from the memory and 'avoids' the kernel issue.
Thanks /Ilias