From ebef811fce038c382fb66ecd728c9d885460263b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Frings-F=C3=BCrst?= Date: Sat, 17 Oct 2020 09:29:59 +0200 Subject: New upstream version 3.3 --- man/dmidecode.8 | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) (limited to 'man/dmidecode.8') diff --git a/man/dmidecode.8 b/man/dmidecode.8 index df861e1..64dc7e7 100644 --- a/man/dmidecode.8 +++ b/man/dmidecode.8 @@ -1,10 +1,12 @@ -.TH DMIDECODE 8 "March 2012" "dmidecode" +.TH DMIDECODE 8 "January 2019" "dmidecode" +.\" .SH NAME dmidecode \- \s-1DMI\s0 table decoder +.\" .SH SYNOPSIS .B dmidecode .RB [ OPTIONS ] - +.\" .SH DESCRIPTION .B dmidecode is a tool for dumping a computer's \s-1DMI\s0 (some say \s-1SMBIOS\s0) table @@ -58,7 +60,7 @@ displayed value. Decoded values. The information presented of course depends on the type of record. Here, we learn about the board's manufacturer, model, version and serial number. - +.\" .SH OPTIONS .TP .BR "-d" ", " "--dev-mem FILE" @@ -72,9 +74,10 @@ displayed. Meta-data and handle references are hidden. Only display the value of the \s-1DMI\s0 string identified by \fBKEYWORD\fR. \fBKEYWORD\fR must be a keyword from the following list: \fBbios-vendor\fR, \fBbios-version\fR, \fBbios-release-date\fR, +\fBbios-revision\fR, \fBfirmware-revision\fR, \fBsystem-manufacturer\fR, \fBsystem-product-name\fR, \fBsystem-version\fR, \fBsystem-serial-number\fR, -\fBsystem-uuid\fR, \fBsystem-family\fR, +\fBsystem-uuid\fR, \fBsystem-sku-number\fR, \fBsystem-family\fR, \fBbaseboard-manufacturer\fR, \fBbaseboard-product-name\fR, \fBbaseboard-version\fR, \fBbaseboard-serial-number\fR, \fBbaseboard-asset-tag\fR, \fBchassis-manufacturer\fR, @@ -158,10 +161,9 @@ is run on a system with BIOS that boasts new SMBIOS specification, which is not supported by the tool yet, it will print out relevant message in addition to requested data on the very top of the output. Thus informs the output data is not reliable. - +.\" .SH "DMI TYPES" The \s-1SMBIOS\s0 specification defines the following \s-1DMI\s0 types: - .TS r l __ @@ -246,7 +248,7 @@ dmidecode --type 0,13 dmidecode --type bios .IP \(bu dmidecode --type BIOS - +.\" .SH BINARY DUMP FILE FORMAT The binary dump files generated by --dump-bin and read using --from-dump are formatted as follows: @@ -255,16 +257,37 @@ The SMBIOS or DMI entry point is located at offset 0x00. It is crafted to hard-code the table address at offset 0x20. .IP \(bu "\w'\(bu'u+1n" The DMI table is located at offset 0x20. - +.\" +.SH UUID FORMAT +There is some ambiguity about how to interpret the UUID fields prior to SMBIOS +specification version 2.6. There was no mention of byte swapping, and RFC 4122 +says that no byte swapping should be applied by default. However, SMBIOS +specification version 2.6 (and later) explicitly states that the first 3 fields +of the UUID should be read as little-endian numbers (byte-swapped). +Furthermore, it implies that the same was already true for older versions of +the specification, even though it was not mentioned. In practice, many hardware +vendors were not byte-swapping the UUID. So, in order to preserve +compatibility, it was decided to interpret the UUID fields according to RFC +4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to +interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS +version is 2.6 or later. The Linux kernel follows the same logic. +.\" .SH FILES .I /dev/mem -.I /sys/firmware/dmi/tables/smbios_entry_point (Linux only) -.I /sys/firmware/dmi/tables/DMI (Linux only) +.br +.I /sys/firmware/dmi/tables/smbios_entry_point +(Linux only) +.br +.I /sys/firmware/dmi/tables/DMI +(Linux only) +.\" .SH BUGS More often than not, information contained in the \s-1DMI\s0 tables is inaccurate, incomplete or simply wrong. +.\" .SH AUTHORS Alan Cox, Jean Delvare +.\" .SH "SEE ALSO" .BR biosdecode (8), .BR mem (4), -- cgit v1.2.3