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@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@chromium.org:
Hi Tom,
On Tue, 24 Oct 2023 at 15:34, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 23, 2023 at 05:31:19PM +0200, Mark Kettenis wrote:
> From: Simon Glass sjg@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@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-sj...
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.