[U-Boot] [PATCH] [U-boot]: Change FDT memory type from runtime data to boot services data

[Ard Biesheuvel]

On Fri, 12 Apr 2019 at 12:55, Heinrich Schuchardt <xypron.glpk at 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 at linaro.org>
> >> Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> >> Acked-by: Ard Biesheuvel <ard.biesheuvel at 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 at 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)

-- 
Ard.