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 <tr...@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 <s...@chromium.org>: > > > >Hi Tom, > > > > > > > >On Tue, 24 Oct 2023 at 15:34, Tom Rini <tr...@konsulko.com> wrote: > > > >> > > > >> 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? > > > > > > > >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-...@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
signature.asc
Description: PGP signature
