Hi Ilias,
On Sat, 26 Jun 2021 at 12:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
[...]
This depends on https://lists.denx.de/pipermail/u-boot/2021-June/451761.html lib/smbios.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
It is strange that all the boards that defined the old CONFIG set it to "", meaning that an empty string is used. Was that just wrong?
Yea I think so. In fact Heinrich fixed an identical error due to that on 00a871d34e2f
OK I see.
In your patch you are using 'Unknown' and 'Unknown Product'. Should it use CONFIG_SYS_VENDOR and CONFIG_SYS_BOARD instead?
I don't have an issue with that, as long as they are defined for every board. I think already Tom pulled this though, but I can send a follow up.
I don't they are both defined for every board (the vast majority though), but probably for every board that uses SMBIOS.
Or should we actually fail (and return an error code), and require the properties to be set by the board? It does not seem very useful to have a meaningless string. Are these SMBIOS values ignored in Linux?
Well the problem is that those tables are marked as mandatory (section 6.2) So failing one would mean disable the entire thing. Why dont we do something less intrusive? I can send a follow up, popping a warning 'fix your dts and/or CONFIG_SYS_VENDOR/CONFIG_SYS_BOARD'. Then we can rid of the fallback but keep the warning for future boards.
OK, I suppose that would have to be a run-time warning. I just worry that no one will notice / fix it if the code builds and runs without it.
I am not aware of all the cases linux uses those. I found the problem trying to enable fwupd and specifically the EFI capsule updates for the firmware. In that case, fwupd is trying to find the 'EFI bit' in 'BIOS Characteristics Extension Byte 2'. There were two things wrong, the bit was wrong and the tables were not installed at all. With the two patches applied fwupd seems happy.
OK.
Regards, Simon