[U-Boot] bootefi failures on armv7

[Ilias Apalodimas]

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