[PATCH v2] smbios: arm64: Allow table to be written at a fixed addr

[Tom Rini]

On Sun, Oct 29, 2023 at 07:41:27AM +1300, Simon Glass wrote:
> [unfortunately I am not receiving email from the list at present]
> 
> Hi Heinrich,
> 
> On Wed, 25 Oct 2023 at 21:39, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >
> > On 10/25/23 04:49, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Tue, 24 Oct 2023 at 18:22, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > >>
> > >>
> > >>
> > >> Am 25. Oktober 2023 01:31:19 MESZ schrieb Simon Glass <sjg at 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.
> 
> That is because ARM devices don't normally need it, right? Anyway,
> that option isn't related to this patch. If ARM devices started using
> SMBIOS and had another way to pass it to Linux (other than EFI) then
> we would want to install it.

No one "needs" it, but it can be helpful. And yes, a future discussion
should be about what we should put in an SMBIOS 3 table, and when. But
for today, being part of EFI (outside of X86) is fine.

> > 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 root problem here is that x86 and ARM used to work differently.
> When the ARM SMBIOS stuff was done, it worked by writing the SMBIOS
> table as part of the 'bootefi' command. On x86, the tables were
> written on startup, so you can examine them within U-Boot. Clearly the
> x86 approach is correct. For one thing, a previous-stage bootloader

I don't think the X86 approach is right, certainly for ARM. We'll be
populating the table with what we're also getting from the device tree
that we're passing to the OS. On x86 I don't know if we'd be loading
anything that might correct/change what goes in the table but on ARM we
have a bunch of places that set the serial# so some function, so some
function in the actual OS boot flow that creates and populates the table
makes sense. I don't know on x86 how we can examine the table.

So, can we please start by just doing the minimal changes to get the
SMBIOS table done correctly for memory above 4G, via EFI, and then start
the next steps?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231028/89882ed9/attachment.sig>