From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Sat, 3 Oct 2020 19:54:13 +0200 Subject: [PATCH v2 4/4] smbios: Add documentation and devicetree binding In-Reply-To: References: <20201002142347.2907638-1-sjg@chromium.org> <20201002142347.2907638-4-sjg@chromium.org> Message-ID: <772284bf-e317-a67d-7758-5819309f6ad6@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/3/20 5:40 PM, Simon Glass wrote: > Hi Heinrich, > > On Fri, 2 Oct 2020 at 08:57, Heinrich Schuchardt 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 >>> --- >>> >>> (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 >