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

[Simon Glass]

Hi Tom,

On Tue, 24 Oct 2023 at 17:44, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Oct 25, 2023 at 02:19:59AM +0200, Heinrich Schuchardt wrote:
> >
> >
> > Am 25. Oktober 2023 01:28:10 MESZ schrieb Simon Glass <sjg at chromium.org>:
> > >Hi Tom,
> > >
> > >On Tue, 24 Oct 2023 at 15:34, Tom Rini <trini at konsulko.com> wrote:
> > >>
> > >> 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?
> > >
> > >Yes that was my previous patch. However 1) we apparently don't want to
> > >use SMBIOS3 and 2) my patch had some sort of bug so that it wasn't
> > >read correctly.
> > >
> > >So my next version is going to be along the lines of what was discussed here.
> > >
> > >Of course, we cannot solve Mark's problem with SMBIOS2, but I suppose
> > >that is obvious. Anyway, those platforms probably don't need SMBIOS.
> >
> > You are heading in the wrong direction. We need SMBIOS 3. SMBIOS 2 is
> > only a fallback for outdated tools.
> >
> > Upcoming mainline RISC-V platforms will also have memory starting above 4GiB.
>
> I want to echo this because yes, SMBIOS if I'm recalling things right is
> one of those tools used to provide user friendly information about the
> system, so "everyone" wants it, or at least platforms like ones Mark is
> concerned about that have more human users than embedded system users,
> would like to show the information.  Maybe part of the answer moving
> forward is to allow being specific about SMBIOS2 or SMBIOS3 (or none) so
> that the issue you had to fix can also be addressed minimally?

OK, so perhaps fixing up this patch would work? [1]

I got the impression that we wanted to continue to use SMBIOS2 unless
we couldn't. So this patch provides for that. It is conceptually
similar to the way things worked before, so provides the smallest
possible change. The move to SMBIOS3 is really a separate issue, isn't
it?

In fact, how can writing SMBIOS2 have ever worked on machines without
memory below 4GB? That seems like a 'feature request' rather than a
bug fix...and the merge window is closed.

So...?

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20231015024511.3995580-4-sjg@chromium.org/