From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: Peter Robinson <pbrobinson@gmail.com>,
U-Boot Mailing List <u-boot@lists.denx.de>,
Tom Rini <trini@konsulko.com>,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Subject: Re: [PATCH 2/2] smbios: Fallback to the default DT if sysinfo nodes are missing
Date: Thu, 29 Sep 2022 13:23:01 +0300 [thread overview]
Message-ID: <YzVyBYtVBg3MTmpY@hera> (raw)
In-Reply-To: <CAPnjgZ2wPpyMp7gA-ksoTtNpm-k_3Mt34jGh7QfgFe8Nex9Zvg@mail.gmail.com>
Hi Simon,
On Thu, Sep 29, 2022 at 03:59:51AM -0600, Simon Glass wrote:
> Hi,
>
> On Tue, 20 Sept 2022 at 05:10, Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > On Tue, Sep 6, 2022 at 2:44 PM Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > In order to fill in the SMBIOS tables U-Boot currently relies on a
> > > "u-boot,sysinfo-smbios" compatible node. This is fine for the boards
> > > that already include such nodes. However with some recent EFI changes,
> > > the majority of boards can boot up distros, which usually rely on
> > > things like dmidecode etc for their reporting. For boards that
> > > lack this special node the SMBIOS output looks like:
> > >
> > > System Information
> > > Manufacturer: Unknown
> > > Product Name: Unknown
> > > Version: Unknown
> > > Serial Number: Unknown
> > > UUID: Not Settable
> > > Wake-up Type: Reserved
> > > SKU Number: Unknown
> > > Family: Unknown
> > >
> > > This looks problematic since most of the info are "Unknown". The DT spec
> > > specifies standard properties containing relevant information like
> > > 'model' and 'compatible' for which the suggested format is
> > > <manufacturer,model>. So let's add a last resort to our current
> > > smbios parsing. If none of the sysinfo properties are found, we can
> > > scan the root node for 'model' and 'compatible'.
> >
> > I don't think the information below all needs to go in the commit,
> > maybe in the cover letter?
> >
> > > pre-patch dmidecode:
> > > <snip>
> > > 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
> > >
> > > Handle 0x0003, DMI type 3, 21 bytes
> > > Chassis Information
> > > Manufacturer: Unknown
> > > Type: Desktop
> > > Lock: Not Present
> > > Version: Not Specified
> > > Serial Number: Not Specified
> > > Asset Tag: Not Specified
> > > Boot-up State: Safe
> > > Power Supply State: Safe
> > > Thermal State: Safe
> > > Security Status: None
> > > OEM Information: 0x00000000
> > > Height: Unspecified
> > > Number Of Power Cords: Unspecified
> > > Contained Elements: 0
> > > <snip>
> > >
> > > post-pastch dmidecode:
> > > <snip>
> > > Handle 0x0001, DMI type 1, 27 bytes
> > > System Information
> > > Manufacturer: socionext,developer-box
> > > Product Name: Socionext Developer Box
> > > 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: socionext,developer-box
> > > Product Name: Socionext Developer Box
> > > 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
> > >
> > > Handle 0x0003, DMI type 3, 21 bytes
> > > Chassis Information
> > > Manufacturer: socionext,developer-box
> > > Type: Desktop
> > > Lock: Not Present
> > > Version: Not Specified
> > > Serial Number: Not Specified
> > > Asset Tag: Not Specified
> > > Boot-up State: Safe
> > > Power Supply State: Safe
> > > Thermal State: Safe
> > > Security Status: None
> > > OEM Information: 0x00000000
> > > Height: Unspecified
> > > Number Of Power Cords: Unspecified
> > > Contained Elements: 0
> > > <snip>
> > >
> > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> >
> > Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
> > Tested-by: Peter Robinson <pbrobinson@gmail.com>
> >
> > > ---
> > > lib/smbios.c | 41 +++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 39 insertions(+), 2 deletions(-)
>
> I've thought about this a lot.
>
> As I mentioned earlier, we should require boards to add this
> information when they enable GENERATE_SMBIOS_TABLE
>
> It is a simple patch for each board vendor and it solves the problem.
> What we have here just masks it.
Not entirely. I think we just see the problem differently here. I agree
that the code here masks a problem (but only for *some* boards) and ideally
we should go and add smbios nodes on the boards that miss it. However we
conveniently keep ignoring OF_BOARD here. Until those things are documented
in a spec and you can *demand* a previous bootloader to include it, we'll have
boards that display "Unknown" all over the place. Personally I don't
think that's acceptable, hence the last resort solution.
I'd be much happier if we popped a warning on boards that miss the smbios
node and are not compiling with OF_BOARD, explaining smbios will be
disabled for them in the future, while having the flexibility to not
display values that make no sense.
Thanks
/Ilias
>
> Regards,
> Simon
next prev parent reply other threads:[~2022-09-29 10:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 13:44 [PATCH 1/2] smbios: Simplify reporting of unknown values Ilias Apalodimas
2022-09-06 13:44 ` [PATCH 2/2] smbios: Fallback to the default DT if sysinfo nodes are missing Ilias Apalodimas
2022-09-20 11:10 ` Peter Robinson
2022-09-29 9:59 ` Simon Glass
2022-09-29 10:23 ` Ilias Apalodimas [this message]
2022-09-29 23:55 ` Simon Glass
2022-09-30 9:56 ` Mark Kettenis
2022-09-30 14:51 ` Tom Rini
2022-09-12 18:31 ` [PATCH 1/2] smbios: Simplify reporting of unknown values Simon Glass
2022-09-16 20:30 ` Ilias Apalodimas
2022-09-17 16:55 ` Sean Anderson
2022-09-26 10:56 ` Ilias Apalodimas
2022-09-29 4:34 ` Sean Anderson
2022-09-29 9:59 ` Simon Glass
2022-09-29 14:02 ` Sean Anderson
2022-09-30 14:25 ` Tom Rini
2022-09-29 10:09 ` Ilias Apalodimas
2022-09-20 10:15 ` Peter Robinson
2022-09-20 11:09 ` Peter Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzVyBYtVBg3MTmpY@hera \
--to=ilias.apalodimas@linaro.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=pbrobinson@gmail.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox