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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
