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

Reply via email to