[U-Boot] bootefi failures on armv7

Ilias Apalodimas
2019-04-11T18:44:22Z

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