On Tue, Dec 19, 2023 at 09:46:22PM -0700, Simon Glass wrote: > Hi again, > > On Mon, 18 Dec 2023 at 14:07, Simon Glass <s...@chromium.org> wrote: > > > > Hi Neil, > > > > On Mon, 18 Dec 2023 at 08:37, <neil.armstr...@linaro.org> wrote: > > > > > > Hi, > > > > > > On 18/12/2023 16:01, Simon Glass wrote: > > > > Hi Neil, > > > > > > > > On Mon, 18 Dec 2023 at 02:54, <neil.armstr...@linaro.org> wrote: > > > >> > > > >> On 17/12/2023 19:41, Tom Rini wrote: > > > >>> On Sat, Dec 16, 2023 at 11:46:18AM -0700, Simon Glass wrote: > > > >>>> Hi Tom, > > > >>>> > > > >>>> On Thu, 14 Dec 2023 at 06:11, Tom Rini <tr...@konsulko.com> wrote: > > > >>>>> > > > > [..] > > > > > > > >>> And my point with the above is that other SoC maintainers (Neil, for > > > >>> amlogic) have said (paraphrasing) he does not want to do N smbios node > > > >>> patches. Which is why Ilias' patch is if not 1000% correct, it's Good > > > >>> Enough and will, if it's really a problem to have all lower case > > > >>> information displayed, spur people to see providing that information > > > >>> as > > > >>> a real problem that needs to be solved. Or it will be seen as good > > > >>> enough. > > > >>> > > > >> > > > >> If some platforms requires a more "correct" smbios dataset, then > > > >> they're > > > >> welcome adding the required smbios node, and it's perfectly > > > >> understandable, > > > >> but for the other community-maintained platforms we need some valid > > > >> fallback > > > >> data otherwise they'll be de facto excluded from some tools for no > > > >> valid reasons. > > > > > > > > Do you know which tools require SMBIOS tables? I found sos and another > > > > Redhat one. > > > > > > SMBIOS data is translated into dmi informations in Linux, and a little > > > lookup in GitHub gives 6.4K files using something from > > > /sys/devices/virtual/dmi/id/, > > > and by very commonly used tools like lshw and probably fwupd. > > > > lshw also uses devicetree, so should not also need SMBIOS. > > > > fwupd uses UUIDs to indicate the device. So far as I know (and I wrote > > a plugin for it, so at least know something), it does not rely on > > SMBIOS tables. > > > > Here is my main question: is SMBIOS: > > > > 1) just informational, not affecting the operation of the device > > 2) important and needed for the device to function > > > > If it is (1), then I don't mind what is in the tables - we could > > perhaps add a '?' at the start of each string to indicate it is > > provisional? > > If it is (2), then I want to avoid adding information that might be > > wrong / might change over the life of the device > > > > In either case, putting these workarounds behind a Kconfig seems > > reasonable to me. What do you think? > > Hmmm and I forgot the other problem, which is that there is no way to > pass an SMBIOS table to Linux without booting via EFI. But I don't > follow it closely, so perhaps that has been resolved?
This issue here is firmly NOT a U-Boot problem. It's a problem for whomever wants to, I assume, design and upstream a DT binding to describe how to find a populated SMBIOS table? There is IIRC some MIPS-specific Linux Kernel option, but I imagine it wouldn't be allowed to be added to other architectures as I assume it's magic location based like non-EFI x86 ones? -- Tom
signature.asc
Description: PGP signature
