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

[Tom Rini]

On Thu, Oct 26, 2023 at 01:02:40AM +0200, Heinrich Schuchardt wrote:
> On 10/25/23 23:09, Tom Rini wrote:
> > On Wed, Oct 25, 2023 at 10:52:48PM +0200, Heinrich Schuchardt wrote:
> > > On 10/25/23 19:09, Tom Rini wrote:
> > > > On Wed, Oct 25, 2023 at 05:28:10PM +0200, Heinrich Schuchardt wrote:
> > > > > On 25.10.23 16:28, Tom Rini wrote:
> > > > > > 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.
> > > > > > 
> > > > > 
> > > > > If you have to manage a fleet of devices, be it Apple laptops, small
> > > > > servers or IoT devices, you want to be able to retrieve information
> > > > > about these devices like installed firmware, serial numbers, etc. This
> > > > > information should be presented by our SMBIOS implementation.
> > > > > 
> > > > > Other EFI architectures (ARM and RISC-V) target the same markets as x86.
> > > > > The customers expect that they can use the same tools irrespective of
> > > > > architecture.
> > > > 
> > > > Ah, we do have serial# being passed along that way (as well as other
> > > > methods which is why I didn't think about them for SMBIOS). But this
> > > > also doesn't answer my bigger concern which is that we're setting our
> > > > version major to 3, our minor to 0 and then filling in a struct that's
> > > > not the "smbios3" one that Simon's patch from another thread added. Is
> > > > what we're filling out today semantically valid? I'm hoping someone who
> > > > has already read over the spec / is familiar and I don't need to go do
> > > > that right now.
> > > > 
> > > 
> > > First of all there is a field "Anchor String". For a 32bit structure it
> > > contains the value '_SM_', for a 64bit structure it contains the value
> > > '_SM3_'. The different EFI GUIDs relate to these two different
> > > structures. In our mails we simply referred to them as SMBIOS2 and
> > > SMBIOS3 structures.
> > > 
> > > Next there are the fields 'SMBIOS Major Version' and 'SMBIOS Minor
> > > Version'. These should refer to the standard version 3.7 if U-Boot
> > > adheres to the current version.
> > > 
> > > As RISC-V was only fully added in SMBIOS version 3.4 we should not use
> > > any older version of the specification.
> > > 
> > > See
> > > https://www.dmtf.org/content/dmtf-releases-smbios-37
> > 
> > That's helpful.  Can we use an SMBIOS2 structure with 'SMBIOS Major
> > Version' = 3 and be valid?
> > 
> 
> The SMBIOS specification 3.7 says:
> 
> "If an implementation provides both a 32-bit and a 64-bit entry point,
> they must both report the same SMBIOS major.minor specification version"
> 
> This implies that SMBIOS Major Version = 3 is valid both in the 32- and
> in the 64-bit structure.

OK, so tooling isn't going to, or at least shouldn't, blow up because we
have Major Version 3 in a SMBIOS2 structure in 32bit address space,
thanks.

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