Hi Heinrich,
On Wed, 21 Oct 2020 at 23:51, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 10/22/20 5:08 AM, Simon Glass wrote:
Add information about how to set SMBIOS properties using the devicetree.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Add onto the sysinfo binding
doc/arch/x86.rst | 8 +++ doc/device-tree-bindings/sysinfo/smbios.txt | 77 +++++++++++++++++++++ 2 files changed, 85 insertions(+) create mode 100644 doc/device-tree-bindings/sysinfo/smbios.txt
diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst index c6b70ce61a3..cc307aa8d5e 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/sysinfo/smbios.txt
TODO List
- Audio
diff --git a/doc/device-tree-bindings/sysinfo/smbios.txt b/doc/device-tree-bindings/sysinfo/smbios.txt new file mode 100644 index 00000000000..b5223228025 --- /dev/null +++ b/doc/device-tree-bindings/sysinfo/smbios.txt @@ -0,0 +1,77 @@ +SMBIOS sysinfo information +==========================
+This binding allows the values for the SMBIOS tables to be specified in the +devicetree, as below.
+Required properties:
- compatible: "u-boot,smbios" or any other string depending on your board
+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. Within +that, the properties are broken down by table type, as in the System Management +BIOS (Basic Input/Output System) Specification.
+Available subnodes for each table type are:
- 1 : system
- 2 : baseboard
- 3 : chassis
+Within each subnode the following tables are recognised:
+"system" subnode optional properties:
- manufacturer: Product manufacturer for system
- 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
+"baseboard" subnode optional properties:
- manufacturer: Product manufacturer for baseboard
- product: Product name
- asset-tag: Asset tag for the motherboard, sometimes used in organisations
to track devices+"chassis" subnode optional properties:
- manufacturer: Product manufacturer for chassis
+Example:
+sysinfo {
compatible = "sandbox,sysinfo-sandbox";Most boards use don't use ACPI but device-trees for calling the operating system. We try to keep our device-trees in sync with Linux. The device-tree available under $fdtcontroladdr should be usable to boot the OS. We should avoid anything that could lead now or in the future to a conflict with the the OS usage of the device tree nodes.
Please, use in the example a compatibility string that is unique to U-Boot.
How about: "uboot,sandbox-sysinfo"?
See my other note on the same comment.
BTW the compatible string depends on the board vendor. We don't define it in this binding file.
In any case, as I say, this binding does not set the compatible string. It can be whatever the board wants.
I'd really like to send our bindings up to Linux. So far they have shown little interest in accepting these, although I don't think anyone has tried in years. It came up on the call last week.
Regards, Simon