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

Tom Rini trini at konsulko.com
Wed Oct 25 16:28:42 CEST 2023


On Wed, Oct 25, 2023 at 04:18:20PM +0200, Mark Kettenis wrote:
> > Date: Tue, 24 Oct 2023 18:34:05 -0400
> > From: Tom Rini <trini at konsulko.com>
> > 
> > On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote:
> > > > From: Simon Glass <sjg at chromium.org>
> > > > Date: Mon, 23 Oct 2023 00:04:14 -0700
> > > > 
> > > > Hi Caleb,
> > > > 
> > > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On 21/10/2023 01:45, Simon Glass wrote:
> > > > > > 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.
> > [snip]
> > > There is absolutely no guarantee that arm64 machines have memory below
> > > 4GB.  Examples of SoCs that have no memory below 4GB are AMD's Opteron
> > > A1100 SoC and all the recent Apple SoCs.
> > 
> > So one thing to resolve here is where does that requirement about the
> > SMBIOS table needing to be below 4GB come from (standards wise), and in
> > turn is that obeyed by consumers like say Linux or OpenBSD? Answering my
> > own question, maybe in part, https://www.dmtf.org/standards/smbios reads
> > to me like there's a v3 and maybe we should be doing what we need to
> > support / identify as that, if it doesn't have that restriction?
> 
> Right.  U-Boot implements SMBIOS 2.x which is pretty much obsolete and
> uses 32-bit addresses.  SMBIOS 3.x allows for 64-bit addresses.  So to
> fix this U-Boot needs support for SMBIOS 3.x.

OK, thanks.  And for clarity / repeating my confusion, at least right
now we also set the major/minor in the struct to 3.0.

> Personally I don't see why we'd need SMBIOS support on non-x86
> platforms, which is why implementing this isn't a high priority for
> me.  I simply disabled SMBIOS support for M1 for now.

This I think in turn (based on Heinrich's emails in v2 of this patch)
EFI_LOADER wants to pass SMBIOS (probably 3) information along so that
human user facing tools can see the kind of info that table provides.

-- 
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/20231025/3afbe491/attachment.sig>


More information about the U-Boot mailing list