Merged
Conversation
At this point, boards will *generally* report *Unknown Product* from an *Unknown* vendor. Further changes are needed to automatically feed the relevant data to the sysinfo subsystem.
These nodes are pre-filled with the Tow-Boot board-specific info. This is correct enough as a fallback. We should strive to upstream discrete entries to all boards where sysinfo should be filled. This will require "generic" builds to include different DT entries for the different boards in the correct `*-u-boot.dtsi` files.
XOXO045
approved these changes
Feb 3, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a follow-up to #135, and does not obsolete #135.
This change set provides an automatic fallback for smbios data that will come from the intrinsic knowledge Tow-Boot already has about the platform.
This is a fallback value, as it is defined in the "earliest" available
*-u-boot.dtsifile, which means that when upstream U-Boot implements the appropriate data in their device trees, the values will be the ones from upstream as it should be.This also means we should make it an habit, and part of the "port" process to contribute the smbios data for the devices to upstream.
Tested on:
Notes
On Raspberry Pi 3, the SMBIOS information is not great. This is because the way this is implemented indeed only works as a fallback. The generic data defined for all Raspberry Pi platforms is used instead. This was expected.
On Raspberry Pi 4, I think what is happening is that there is no built-in information in U-Boot to use the fallback information. So at the current time it's showing Unknown and Unknown Product.
Given the general difficulties with the Raspberry Pi platforms, this is okay. Anyway packaging for Raspberry Pi is planned to be revised, so putting a lot of effort into something that will most likely change is not ideal.
On all other tested platforms the fallback values were used as expected.