efi: Correct address handling with ACPI tables

The current EFI implementation confuses pointers and addresses. Normally
we can get away with this but in the case of sandbox it causes failures.

Despite the fact that efi_allocate_pages() returns a u64, it is actually
a pointer, not an address. Add special handling to avoid a crash when
running 'bootefi hello'.

Signed-off-by: Simon Glass <sjg@chromium.org>
This commit is contained in:
Simon Glass 2021-12-01 09:02:42 -07:00
parent 47642428ee
commit a9e414dd50

View File

@ -8,6 +8,7 @@
#include <common.h> #include <common.h>
#include <efi_loader.h> #include <efi_loader.h>
#include <log.h> #include <log.h>
#include <mapmem.h>
#include <acpi/acpi_table.h> #include <acpi/acpi_table.h>
static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID; static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
@ -22,6 +23,7 @@ efi_status_t efi_acpi_register(void)
/* Map within the low 32 bits, to allow for 32bit ACPI tables */ /* Map within the low 32 bits, to allow for 32bit ACPI tables */
u64 acpi = U32_MAX; u64 acpi = U32_MAX;
efi_status_t ret; efi_status_t ret;
ulong addr;
/* Reserve 64kiB page for ACPI */ /* Reserve 64kiB page for ACPI */
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
@ -34,7 +36,8 @@ efi_status_t efi_acpi_register(void)
* a 4k-aligned address, so it is safe to assume that * a 4k-aligned address, so it is safe to assume that
* write_acpi_tables() will write the table at that address. * write_acpi_tables() will write the table at that address.
*/ */
write_acpi_tables((ulong)acpi); addr = map_to_sysmem((void *)(ulong)acpi);
write_acpi_tables(addr);
/* And expose them to our EFI payload */ /* And expose them to our EFI payload */
return efi_install_configuration_table(&acpi_guid, return efi_install_configuration_table(&acpi_guid,