On 10/25/23 04:49, Simon Glass wrote:
Hi Heinrich,
On Tue, 24 Oct 2023 at 18:22, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
Am 25. Oktober 2023 01:31:19 MESZ schrieb Simon Glass <s...@chromium.org>:
U-Boot typically sets up its malloc() pool near the top of memory. On
ARM64 systems this can result in an SMBIOS table above 4GB which is
not supported by SMBIOSv2.
Work around this problem by providing a new option to choose an address
below 4GB (but as high as possible), if needed.
You must not overwrite memory controlled by the EFI subsystem without calling
its allocator. We should provide SMBIOS 3. SMBIOS 2 is only a fallback for
outdated tools.
That is not my intention and I don't believe this code does that. EFI
is not running at this point, is it?
The function install_smbios_table() only exists if CONFIG_EFI_LOADER=y.
We have:
EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, install_smbios_table);
This is invoked after efi_memory_init().
The EFI specification requires that the memory area occupied by the
SMBIOS table uses one of a specific set of memory types where
EfiRuntimeServicesData is recommended. So you must call
u64 addr = UINT_MAX;
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
EFI_RUNTIME_SERVICES_DATA, efi_size_in_pages(size), *addr);
to allocate the memory. If the return code is not EFI_SUCCESS, no memory
below 4 GiB is available.
The bit I am confused about is that we don't support SMBIOS3 in
U-Boot. I am trying to fix an introduced bug...
I would not know why we should not use SMBIOS 3.
Best regards
Heinrich