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

[Heinrich Schuchardt]

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.

>> 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";

>
>>    bios {};
>>    system {};
>>    board {
>>       manufacturer = "Hardkernel Co., Ltd.";
>>       product = "ODROID-C2";
>>       ...
>>    };
>>    chassis {};
>>    processor {};
>>    boot {};
>> };
>>
>>> +                     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.

Best regards

Heinrich

>
>>
>> ....
>> Handle 0x0001, DMI type 1, 27 bytes
>> System Information
>>         Manufacturer: Hardkernel Co., Ltd.
>>         Product Name: ODROID-C2
>>         Version: Not Specified
>> ...
>>         Wake-up Type: Reserved
>>         SKU Number: Not Specified
>>         Family: Not Specified
>> ....
>>
>>
>> So doc/device-tree-bindings/board/board_x86.txt is the wrong place to
>> document the new device tree node.
>>
>> Why not create a document doc/device-tree-bindings/smbios.rst for it?
>
> OK I can do that. I'll await your thoughts on the above.
>
> Regards,
> Simon
>