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 <tr...@konsulko.com> > > > > > > > > > > > > On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote: > > > > > > > > From: Simon Glass <s...@chromium.org> > > > > > > > > Date: Mon, 23 Oct 2023 00:04:14 -0700 > > > > > > > > > > > > > > > > Hi Caleb, > > > > > > > > > > > > > > > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly > > > > > > > > <caleb.conno...@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? -- Tom
signature.asc
Description: PGP signature
