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