On Fri, 12 Apr 2019 at 12:55, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 4/12/19 9:30 PM, Heinrich Schuchardt wrote:
On 4/12/19 8:26 PM, Ilias Apalodimas wrote:
Following Ard's suggestion: Runtime data sections are intended for data that is used by the runtime services implementation. Let's change the type to EFI_BOOT_SERVICES_DATA
This also fixes booting of armv7 using efi and fdtcontroladdr
Suggested-by: Ard Biesheuvel ard.biesheuvel@linaro.org Signed-off-by: Ilias Apalodimas ilias.apalodimas@linaro.org Acked-by: Ard Biesheuvel ard.biesheuvel@linaro.org
EfiBootServicesData is used by EDK II for installing the FDT. GRUB uses EfiLoaderCode when installing its modified version of the FDT.
Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de
Applied u-bootefi branch efi-2019-07
Thanks Heinrich.
I still have a question, though. The following code
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size); ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, EFI_BOOT_SERVICES_DATA, fdt_pages, &new_fdt_addr);
looks (from the patch context) like it sets new_fdt_addr to the FDT size rounded up to 4 KB, and then uses that *size* as the max address in the allocation. That seems a bit strange.
But the important point is that the EFI stub does not care at all where the FDT is. The stub allocates a new fdt based on the firmware provided one, and copies in all the data, and adds some data of its own.
This means that the EFI code in u-boot really doesn't have to abide by the same rules as the other code allocating FDTs. (It also means there is no point in using ACPI reclaim memory for the FDT, as I suggested earlier, so BS data is definitely the best choice here)