Hi Simon, Adding Rob for information around putting things in device tree.
> > If a value is not valid during the DT or SYSINFO parsing, we explicitly > > set that to "Unknown Product" and "Unknown" for the product and > > manufacturer respectively. It's cleaner if we move the checks insisde > > smbios_add_string() and always report "Unknown" regardless of the missing > > field. > > > > pre-patch dmidecode > > <snip> > > Handle 0x0001, DMI type 1, 27 bytes > > System Information > > Manufacturer: Unknown > > Product Name: Unknown Product > > Version: Not Specified > > Serial Number: Not Specified > > UUID: Not Settable > > Wake-up Type: Reserved > > SKU Number: Not Specified > > Family: Not Specified > > > > Handle 0x0002, DMI type 2, 14 bytes > > Base Board Information > > Manufacturer: Unknown > > Product Name: Unknown Product > > Version: Not Specified > > Serial Number: Not Specified > > Asset Tag: Not Specified > > Features: > > Board is a hosting board > > Location In Chassis: Not Specified > > Type: Motherboard > > <snip> > > > > post-patch dmidecode: > > > > Handle 0x0001, DMI type 1, 27 bytes > > System Information > > Manufacturer: Unknown > > Product Name: Unknown > > Version: Unknown > > Serial Number: Unknown > > UUID: Not Settable > > Wake-up Type: Reserved > > SKU Number: Unknown > > Family: Unknown > > > > Handle 0x0002, DMI type 2, 14 bytes > > Base Board Information > > Manufacturer: Unknown > > Product Name: Unknown > > Version: Unknown > > Serial Number: Not Specified > > Asset Tag: Unknown > > Features: > > Board is a hosting board > > Location In Chassis: Not Specified > > Chassis Handle: 0x0000 > > Type: Motherboard > > > > Signed-off-by: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > --- > > lib/smbios.c | 17 +++-------------- > > 1 file changed, 3 insertions(+), 14 deletions(-) > > Perhaps a better fix is to drop the smbios info? > > What upstream projects use this information to show things to the > user? You showed a screenshot of some sort of system-info app. We > could teach it about falling back to the device tree. That way we are > not adding fake information to SMBIOS. Lots of things use it, particularly for enterprise support platforms. The system-info apps you mention above are the GNOME about dialog box and a tool called neofetch (which I personally don't particularly care for but people like it for some reason). There's general tools like dmidecode that use the information, but there's a LOT of open source tools that use the SMBIOS information, most of the Desktop UX About or HW tools, a lot of support tools like sosreport (https://github.com/sosreport/sos), and server management tools like cockpit (https://cockpit-project.org/) and uncountable proprietary tools. The problem with putting these things into Device Tree is that they're not really describing the hardware explicitly and it's U-Boot specific and Rob has mentioned in the past we absolutely shouldn't be making things up that don't belong in Device Tree. > Also, SMBIOS is a legacy thing and a PITA to work with. How about we > use the device tree binding for the same info: You say it's legacy, yet it released a new 3.6.0 version in June this year and is used extensively across x86 and is required for some of the Arm SystemReady standards. Doesn't appear particularly legacy to me. While I don't particularly like SMBIOS either it's the standard and widely used, I don't see it going anywhere soon. The advantage of it from someone who had to deal with end to end I feel it's better to support this because patching all the various projects to support other things and getting them deployed and enterprises and third parties to upgrade and integrate into their platforms and processes. Which from experience takes an extremely long time! > smbios { > compatible = "u-boot,sysinfo-smbios"; > > smbios { > system { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > > baseboard { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > > chassis { > manufacturer = "pine64"; > product = "rock64_rk3328"; > }; > }; > }; > > This is easy to parse and gets us away from all this legacy junk that > we don't need. I don't see this is any more pretty or any better than getting the information from Device Tree, moving forward I think it would also be useful to populate things like serial numbers from the fuse/otp blocks which we often already display either on the console during boot for via various commands. Overall I think we need to be practical, this is a standard that is widely used now, it's much more straight forward for the overall ecosystem to continue to use a widely adopted standard rather than trying to update all the open and proprietary tools out there to some new "standard" that is only useful for device tree platforms. I'll reference XKCD here for that: https://xkcd.com/927/ Peter
