On 4/11/19 8:39 PM, Ilias Apalodimas wrote:
Following Ard's suggestion:
Runtime data sections are intended for data that is used by the runtime
services implementations.
Let's change they type to EFI_ACPI_RECLAIM_MEMORY
Suggested-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodi...@linaro.org>
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3619a20e6433..b54181909aff 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -111,13 +111,13 @@ static efi_status_t copy_fdt(void **fdtp)
new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f00000 +
fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
GRUB uses EfiLoaderCode when installing its modified version of the FDT.
The "Embedded Base Boot Requirements (EBBR) Specification, Release v1.0"
does not require ACPI support. Can we expect EfiACPIReclaimMemory to be
supported if we do not have any ACPI table?
How about functions efi_smbios_register() and efi_acpi_register()?
How about systab.tables assigned in efi_initialize_system_table()? Which
of the addresses in systab.tables should be updated upon relocation.
The EFI Spec is really hazy: "A pointer to the table associated with
VendorGuid. Whether this pointer is a physical address or a
virtual address during runtime is determined by the VendorGuid."
The FDT_TABLE_GUID or DEVICE_TREE_GUID as Linux calls it is not defined
in the UEFI spec. So we can marvel about expected behavior. Is there any
other document specifying it?
Best regards
Heinrich
&new_fdt_addr);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_RUNTIME_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
&new_fdt_addr);
if (ret != EFI_SUCCESS) {
printf("ERROR: Failed to reserve space for FDT\n");
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
