[PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing

[Peter Robinson]

> > > > > > Not always.  I am not sure if x86 does that, but on the rest of the
> > > > > > architectures, they are only initialized when the efi smbios code
> > > > > > runs. Wasn't this something you were trying to change?
> > > > >
> > > > > One of those things I keep repeating is that we don't know for sure what
> > > > > the right values here are until we load the DT the OS _will_ use. It's
> > > > > quite valid to start U-Boot and pass it a generic "good enough" DT at
> > > > > run time until U-Boot can see (GPIOs, EEPROM, whatever) what it's on and
> > > > > what the real DT to load before passing to the OS is. Since U-Boot
> > > > > doesn't need SMBIOS tables itself, we should make these "late" not
> > > > > "early".
> > > >
> > > > Fair enough, we can defer the init and testing of those late, just
> > > > before we are about to boot. But this is irrelevant to what this patch
> > > > does, can we get the fallback mechanism in first, assuming everyone is
> > > > ok with the patch now?
> > > >
> > >
> > > I would like this behind a Kconfig. Making it the default means people
> > > are going to start relying on (in user space) and then discover later
> > > that it is wrong.
> >
> > What do you mean wrong, exactly?
>
> "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm"
> instead of "FriendlyElec"

Well "raspberrypi" is better that what we get on the Raspberry Pi with
my testing at the moment which is "Unknown", which from what I can
tell from commit 330419727 should have at least the minimal amount but
it doesn't.

> I just wonder what this information is actually used for. If it is
> just for fun, that is fine, but I believe some tools do use dmidecode,
> at which point it needs to be accurate and should not change later,
> e.g. when someone decides to actually add the info.

So a lot of tools use the output of dmidecode, it's used extensively
through various support platforms and management tools.

In Fedora I would generally get around a dozen reports every few
months because anything booted with U-Boot was basically populated
with "Unknown".

At the moment, on the RPi4 with default upstream I get Unkown [1] with
these patches I get at least some useful information [2]. I've been
shipping this patch set, in various versions, for a while and have not
had a single bug report about wrong information.

When Ilias and I first spoke about these patches the intention was to
get initial useful information, them they could be possibly expanded
using things like information from eFuses (serial numbers etc).

In some cases with U-Boot you get SMBIOS tables that are incorrect and
crash the tools.

With this patch set you get at least the basics which is important
because support teams can easily work out the basics of what they're
working with even if they don't have physical access all without the
vendor of the HW having to work out what to do in firmware to make
something work.

This patch set moves the needle forward, if we wait for everything to
be properly formatted we will wait for ever, with information we
already have available ON EVERY DEVICE.

Peter

[1] https://pbrobinson.fedorapeople.org/dmi-decode-rpi-defaults.txt
[2] https://pbrobinson.fedorapeople.org/dmi-decode-rpi-auto-fallback-patchset.txt