a9e414dd50
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>
46 lines
1.1 KiB
C
46 lines
1.1 KiB
C
// SPDX-License-Identifier: GPL-2.0+
|
|
/*
|
|
* EFI application ACPI tables support
|
|
*
|
|
* Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
|
|
*/
|
|
|
|
#include <common.h>
|
|
#include <efi_loader.h>
|
|
#include <log.h>
|
|
#include <mapmem.h>
|
|
#include <acpi/acpi_table.h>
|
|
|
|
static const efi_guid_t acpi_guid = EFI_ACPI_TABLE_GUID;
|
|
|
|
/*
|
|
* Install the ACPI table as a configuration table.
|
|
*
|
|
* Return: status code
|
|
*/
|
|
efi_status_t efi_acpi_register(void)
|
|
{
|
|
/* Map within the low 32 bits, to allow for 32bit ACPI tables */
|
|
u64 acpi = U32_MAX;
|
|
efi_status_t ret;
|
|
ulong addr;
|
|
|
|
/* Reserve 64kiB page for ACPI */
|
|
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
|
|
EFI_ACPI_RECLAIM_MEMORY, 16, &acpi);
|
|
if (ret != EFI_SUCCESS)
|
|
return ret;
|
|
|
|
/*
|
|
* Generate ACPI tables - we know that efi_allocate_pages() returns
|
|
* a 4k-aligned address, so it is safe to assume that
|
|
* write_acpi_tables() will write the table at that address.
|
|
*/
|
|
addr = map_to_sysmem((void *)(ulong)acpi);
|
|
write_acpi_tables(addr);
|
|
|
|
/* And expose them to our EFI payload */
|
|
return efi_install_configuration_table(&acpi_guid,
|
|
(void *)(uintptr_t)acpi);
|
|
}
|