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

[Tom Rini]

On Tue, Oct 24, 2023 at 07:47:44PM -0700, Simon Glass wrote:
> 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/

This keeps bringing up more questions, sigh. Can we really, as we
seemingly do today, declare the table we're passing to be major_ver=3,
minor_ver=0 and not be using the struct [1] defines as the smbios3 table
format? anchor has a different size to start with.

I'm not familiar with where we decided we wanted to use SMBIOS2 unless
we couldn't, but maybe we need to re-evaluate that decision all the
same.

And in my mind, especially once we know the answer to my first question
here about struct vs version number, I see your patch in [1] is fixing a
problem, and adding whatever further information SMBIOS3 would let us
pass as future work for post-v2024.01.

-- 
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/654ddf1d/attachment.sig>