> 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. 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.
