[PATCH v2 4/4] smbios: Add documentation and devicetree binding

[Simon Glass]

Hi Heinrich,

On Sat, 3 Oct 2020 at 11:54, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 10/3/20 5:40 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Fri, 2 Oct 2020 at 08:57, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> On 02.10.20 16:23, Simon Glass wrote:
> >>> Add information about how to set SMBIOS properties using the devicetree.
> >>>
> >>> Signed-off-by: Simon Glass <sjg at chromium.org>
> >>> ---
> >>>
> >>> (no changes since v1)
> >>>
> >>>  doc/arch/x86.rst                             |  8 +++++
> >>>  doc/device-tree-bindings/board/board_x86.txt | 36 ++++++++++++++++++++
> >>>  2 files changed, 44 insertions(+)
> >>>  create mode 100644 doc/device-tree-bindings/board/board_x86.txt
> >>>
> >>> diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst
> >>> index c6b70ce61a3..45f9ba308c7 100644
> >>> --- a/doc/arch/x86.rst
> >>> +++ b/doc/arch/x86.rst
> >>> @@ -740,6 +740,14 @@ Note that this is a development feature only. It is not intended for use in
> >>>  production environments. Also it is not currently part of the automated tests
> >>>  so may break in the future.
> >>>
> >>> +SMBIOS tables
> >>> +-------------
> >>> +
> >>> +To generate SMBIOS tables in U-Boot, for use by the OS, enable the
> >>> +CONFIG_GENERATE_SMBIOS_TABLE option. The easiest way to provide the values to
> >>> +use is via the device tree. For details see
> >>> +device-tree-bindings/board/board_x86.txt
> >>> +
> >>>  TODO List
> >>>  ---------
> >>>  - Audio
> >>> diff --git a/doc/device-tree-bindings/board/board_x86.txt b/doc/device-tree-bindings/board/board_x86.txt
> >>> new file mode 100644
> >>> index 00000000000..3766751896a
> >>> --- /dev/null
> >>> +++ b/doc/device-tree-bindings/board/board_x86.txt
> >>> @@ -0,0 +1,36 @@
> >>> +x86 board driver
> >>> +================
> >>> +
> >>> +This driver allows providing board-specific features such as power control
> >>> +GPIOs. In addition, the SMBIOS values can be specified in the device tree,
> >>> +as below:
> >>> +
> >>> +An optional 'smbios' subnode can be used to provide these properties.
> >>> +
> >>> +Optional properties:
> >>> +  - manufacturer: Product manufacturer for system / baseboard
> >>> +  - product:      Product name
> >>> +  - version:      Product version string
> >>> +  - serial:       Serial number for system (note that this can be overridden by
> >>> +                      the serial# environment variable)
> >>> +  - sku:          Product SKU (Stock-Keeping Unit)
> >>> +  - family:       Product family
> >>> +  - asset-tag:    Asset tag for the motherboard, sometimes used in organisations
> >>> +                      to track devices
> >>> +
> >>> +
> >>> +Example:
> >>> +
> >>> +     board {
> >>> +             compatible = "google,coral";
> >>> +
> >>> +             smbios {
> >>
> >> I think board is the wrong place for the new node.
> >>
> >> SMBIOS also includes chassis, processor and other information. We may
> >> opt to provide non-board information in future via the device-tree.
> >
> > I think of board as the whole thing. Are you thinking of it just being
> > the circuit board?
>
> The whole I would call a system.
>
> dmidecode shows bios, system, board, chassis, processor, boot. So board
> seems to be only a small aspect of the SMBIOS system description.

Well that is using smbios terminology. For U-Boot there is only the
board at present.

We could rename the board uclass to system, I suppose. But at least
for now, the terminology within U-Boot is to use the word 'board' to
describe a build target.

>
> >> If this is for U-Boot internal only usage, we should indicate this in
> >> the label name.
> >
> > All drivers are for U-Boot-internal use, right? Or are you saying you
> > don't want this information to appear in the upstream bindings?
>
> I don't won't name collisions of U-Boot with Linux when using U-Boot's
> device tree for booting an operating system on ARM and RISC-V systems.
>
> >> So it could be like:
> >>
> >> /u-boot-smbios {
> >
> > compatible string?
>
> Yes there should be one. So you know that this is the node you are
> looking for.
>
>     compatible = "u-boot,smbios";

OK good.

>
> >
> >>    bios {};
> >>    system {};
> >>    board {
> >>       manufacturer = "Hardkernel Co., Ltd.";
> >>       product = "ODROID-C2";
> >>       ...
> >>    };
> >>    chassis {};
> >>    processor {};
> >>    boot {};

I think this makes sense because here we are describing smbios tables
so we should use the same terminology.

> >> };
> >>
> >>> +                     manufacturer = "Google";
> >>> +                     product = "Coral";
> >>> +                     version = "rev2";
> >>> +                     serial = "123456789";
> >>> +                     sku = "sku3";
> >>> +                     family = "Google_Coral";
> >>> +                     asset-tag = "ABC123";
> >>> +             };
> >>> +     };
> >>>
> >>
> >> SMBIOS is not x86 specific. On ARM we are also passing an SMBIOS table.
> >>
> >> On my Odroid C2 dmidecode shows the information provided by U-Boot:
> >
> > Oh dear. Legacy never dies. It never occurred to me that this would be
> > used on ARM.
>
> Don't forget about RISC-V :)
>
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.3.0.pdf:
>
> "The following processor architectures are now supported:
>
> * IA-32 (x86),386
> * x64 (x86-64, Intel64, AMD64, EM64T),
> * Intel Itanium architecture,
> * 32-bit ARM (Aarch32),
> * 64-bit ARM (Aarch64),
> * RISC-V 32 (RV32),
> * RISC-V 64 (RV64),
> * RISC-V 128 (RV128)"
>
> If you think of data centers, it may be valuable to be able to use the
> same management tools for amd64, aarch64 and rv64.

Yes, long live legacy!

Regards,
SImon