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