diff options
Diffstat (limited to 'man/dmidecode.8')
| -rw-r--r-- | man/dmidecode.8 | 159 |
1 files changed, 109 insertions, 50 deletions
diff --git a/man/dmidecode.8 b/man/dmidecode.8 index df861e1..83affc2 100644 --- a/man/dmidecode.8 +++ b/man/dmidecode.8 @@ -1,10 +1,12 @@ -.TH DMIDECODE 8 "March 2012" "dmidecode" +.TH DMIDECODE 8 "February 2023" "dmidecode" +.\" .SH NAME dmidecode \- \s-1DMI\s0 table decoder +.\" .SH SYNOPSIS .B dmidecode -.RB [ OPTIONS ] - +.RI [ OPTIONS ] +.\" .SH DESCRIPTION .B dmidecode is a tool for dumping a computer's \s-1DMI\s0 (some say \s-1SMBIOS\s0) table @@ -58,37 +60,61 @@ 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" -Read memory from device \fBFILE\fR (default: \fB/dev/mem\fR) +.BR "-d" ", " "--dev-mem \fIFILE\fP" +Read memory from device \fIFILE\fP (default: \fI/dev/mem\fP) .TP .BR "-q" ", " "--quiet" Be less verbose. Unknown, inactive and \s-1OEM\s0-specific entries are not displayed. Meta-data and handle references are hidden. .TP -.BR "-s" ", " "--string KEYWORD" -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, -\fBsystem-manufacturer\fR, \fBsystem-product-name\fR, -\fBsystem-version\fR, \fBsystem-serial-number\fR, -\fBsystem-uuid\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, -\fBchassis-type\fR, -\fBchassis-version\fR, \fBchassis-serial-number\fR, -\fBchassis-asset-tag\fR, \fBprocessor-family\fR, -\fBprocessor-manufacturer\fR, -\fBprocessor-version\fR, \fBprocessor-frequency\fR. +.BR " " " " "--no-quirks" +Decode everything exactly as it is in the table, without trying to fix up +common mistakes or hide irrelevant fields. +This mode is primarily aimed at firmware developers. +.TP +.BR "-s" ", " "--string \fIKEYWORD\fP" +Only display the value of the \s-1DMI\s0 string identified by \fIKEYWORD\fP. +It must be a keyword from the following list: +.nh +.BR bios\-vendor , +.BR bios\-version , +.BR bios\-release\-date , +.BR bios\-revision , +.BR firmware\-revision , +.BR system\-manufacturer , +.BR system\-product\-name , +.BR system\-version , +.BR system\-serial\-number , +.BR system\-uuid , +.BR system\-sku\-number , +.BR system\-family , +.BR baseboard\-manufacturer , +.BR baseboard\-product\-name , +.BR baseboard\-version , +.BR baseboard\-serial\-number , +.BR baseboard\-asset\-tag , +.BR chassis\-manufacturer , +.BR chassis\-type , +.BR chassis\-version , +.BR chassis\-serial\-number , +.BR chassis\-asset\-tag , +.BR processor\-family , +.BR processor\-manufacturer , +.BR processor\-version , +.BR processor\-frequency . +.hy Each keyword corresponds to a given \s-1DMI\s0 type and a given offset within this entry type. Not all strings may be meaningful or even defined on all systems. Some keywords may return more than one result on some systems (e.g. -\fBprocessor-version\fR on a multi-processor system). -If \fBKEYWORD\fR is not provided or not valid, a list of all valid +.nh +.B processor\-version +.hy +on a multi-processor system). +If \fIKEYWORD\fP is not provided or not valid, a list of all valid keywords is printed and .B dmidecode exits with an error. @@ -101,23 +127,32 @@ typically from files under .IR /sys/devices/virtual/dmi/id . Most of these files are even readable by regular users. .TP -.BR "-t" ", " "--type TYPE" -Only display the entries of type \fBTYPE\fR. \fBTYPE\fR can be either a +.BR "-t" ", " "--type \fITYPE\fP" +Only display the entries of type \fITYPE\fP. It can be either a \s-1DMI\s0 type number, or a comma-separated list of type numbers, or a -keyword from the following list: \fBbios\fR, \fBsystem\fR, -\fBbaseboard\fR, \fBchassis\fR, \fBprocessor\fR, \fBmemory\fR, -\fBcache\fR, \fBconnector\fR, \fBslot\fR. Refer to the DMI TYPES section -below for details. +keyword from the following list: +.nh +.BR bios , +.BR system , +.BR baseboard , +.BR chassis , +.BR processor , +.BR memory , +.BR cache , +.BR connector , +.BR slot . +.hy +Refer to the DMI TYPES section below for details. If this option is used more than once, the set of displayed entries will be the union of all the given types. -If \fBTYPE\fR is not provided or not valid, a list of all valid keywords +If \fITYPE\fP is not provided or not valid, a list of all valid keywords is printed and .B dmidecode exits with an error. .TP -.BR "-H" ", " "--handle HANDLE" -Only display the entry whose handle matches \fBHANDLE\fR. \fBHANDLE\fR -is a 16-bit integer. +.BR "-H" ", " "--handle \fIHANDLE\fP" +Only display the entry whose handle matches \fIHANDLE\fP. +\fIHANDLE\fP is a 16-bit integer. .TP .BR "-u" ", " "--dump" Do not decode the entries, dump their contents as hexadecimal instead. @@ -125,22 +160,23 @@ Note that this is still a text output, no binary data will be thrown upon you. The strings attached to each entry are displayed as both hexadecimal and \s-1ASCII\s0. This option is mainly useful for debugging. .TP -.BR " " " " "--dump-bin FILE" +.BR " " " " "--dump-bin \fIFILE\fP" Do not decode the entries, instead dump the DMI data to a file in binary -form. The generated file is suitable to pass to \fB--from-dump\fR +form. The generated file is suitable to pass to \fB--from-dump\fP later. +\fIFILE\fP must not exist. .TP -.BR " " " " "--from-dump FILE" -Read the DMI data from a binary file previously generated using -\fB--dump-bin\fR. +.BR " " " " "--from-dump \fIFILE\fP" +Read the DMI data from a binary file previously generated using +\fB--dump-bin\fP. .TP .BR " " " " "--no-sysfs" Do not attempt to read DMI data from sysfs files. This is mainly useful for debugging. .TP -.BR " " " " "--oem-string N" -Only display the value of the \s-1OEM\s0 string number \fBN\fR. The first -\s-1OEM\s0 string has number 1. With special value "count", return the +.BR " " " " "--oem-string \fIN\fP" +Only display the value of the \s-1OEM\s0 string number \fIN\fP. The first +\s-1OEM\s0 string has number \fB1\fP. With special value \fBcount\fP, return the number of OEM strings instead. .TP .BR "-h" ", " "--help" @@ -149,7 +185,10 @@ Display usage information and exit .BR "-V" ", " "--version" Display the version and exit .P -Options --string, --type, --dump-bin and --oem-string +Options +.BR --string , +.BR --type, +.BR --dump-bin " and " --oem-string determine the output format and are mutually exclusive. .P Please note in case of @@ -158,10 +197,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 __ @@ -218,7 +256,7 @@ end-of-table marker. Types 128 to 255 are for \s-1OEM\s0-specific data. will display these entries by default, but it can only decode them when the vendors have contributed documentation or code for them. -Keywords can be used instead of type numbers with \fB--type\fR. +Keywords can be used instead of type numbers with \fB--type\fP. Each keyword is equivalent to a list of type numbers: .TS @@ -246,25 +284,46 @@ 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 +The binary dump files generated by \fB--dump-bin\fP and read using \fB--from-dump\fP are formatted as follows: .IP \(bu "\w'\(bu'u+1n" 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), |