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

[Mark Kettenis]

> 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.

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.