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/
