mirror of
https://git.jff.email/cgit/dmidecode.git
synced 2026-08-07 08:07:48 +00:00
326 lines
9.8 KiB
Groff
326 lines
9.8 KiB
Groff
.TH DMIDECODE 8 "January 2019" "dmidecode"
|
|
.\"
|
|
.SH NAME
|
|
dmidecode \- \s-1DMI\s0 table decoder
|
|
.\"
|
|
.SH SYNOPSIS
|
|
.B dmidecode
|
|
.RI [ OPTIONS ]
|
|
.\"
|
|
.SH DESCRIPTION
|
|
.B dmidecode
|
|
is a tool for dumping a computer's \s-1DMI\s0 (some say \s-1SMBIOS\s0) table
|
|
contents in a human-readable format. This table contains a description of the
|
|
system's hardware components, as well as other useful pieces of information
|
|
such as serial numbers and \s-1BIOS\s0 revision. Thanks to this table, you can
|
|
retrieve this information without having to probe for the actual hardware.
|
|
While this is a good point in terms of report speed and safeness, this also
|
|
makes the presented information possibly unreliable.
|
|
|
|
The \s-1DMI\s0 table doesn't only describe what the system is currently made
|
|
of, it also can report the possible evolutions (such as the fastest supported
|
|
\s-1CPU\s0 or the maximal amount of memory supported).
|
|
|
|
\s-1SMBIOS\s0 stands for System Management \s-1BIOS\s0, while \s-1DMI\s0
|
|
stands for Desktop Management Interface. Both standards are tightly related
|
|
and developed by the \s-1DMTF\s0 (Desktop Management Task Force).
|
|
|
|
As you run it,
|
|
.B dmidecode
|
|
will try to locate the \s-1DMI\s0 table. It will first try to read the DMI table
|
|
from sysfs, and next try reading directly from memory if sysfs access failed.
|
|
If
|
|
.B dmidecode
|
|
succeeds in locating a valid DMI table, it will then parse this table
|
|
and display a list of records like this one:
|
|
|
|
Handle 0x0002, DMI type 2, 8 bytes.
|
|
Base Board Information
|
|
Manufacturer: Intel
|
|
Product Name: C440GX+
|
|
Version: 727281-001
|
|
Serial Number: INCY92700942
|
|
|
|
Each record has:
|
|
.IP \(bu "\w'\(bu'u+1n"
|
|
A handle. This is a unique identifier, which allows records to
|
|
reference each other. For example, processor records usually reference
|
|
cache memory records using their handles.
|
|
.IP \(bu
|
|
A type. The \s-1SMBIOS\s0 specification defines different types of elements
|
|
a computer can be made of. In this example, the type is 2, which
|
|
means that the record contains "Base Board Information".
|
|
.IP \(bu
|
|
A size. Each record has a 4-byte header (2 for the handle, 1 for the type,
|
|
1 for the size), the rest is used by the record data. This value doesn't
|
|
take text strings into account (these are placed at the end of the record),
|
|
so the actual length of the record may be (and is often) greater than the
|
|
displayed value.
|
|
.IP \(bu
|
|
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 \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 \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.
|
|
.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.
|
|
This option cannot be used more than once.
|
|
|
|
Note: on Linux, most of these strings can alternatively be read directly
|
|
from
|
|
.BR sysfs ,
|
|
typically from files under
|
|
.IR /sys/devices/virtual/dmi/id .
|
|
Most of these files are even readable by regular users.
|
|
.TP
|
|
.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:
|
|
.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 \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 \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.
|
|
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 \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\fP
|
|
later.
|
|
.TP
|
|
.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 \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"
|
|
Display usage information and exit
|
|
.TP
|
|
.BR "-V" ", " "--version"
|
|
Display the version and exit
|
|
.P
|
|
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
|
|
.B dmidecode
|
|
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
|
|
__
|
|
r l.
|
|
Type Information
|
|
0 BIOS
|
|
1 System
|
|
2 Baseboard
|
|
3 Chassis
|
|
4 Processor
|
|
5 Memory Controller
|
|
6 Memory Module
|
|
7 Cache
|
|
8 Port Connector
|
|
9 System Slots
|
|
10 On Board Devices
|
|
11 OEM Strings
|
|
12 System Configuration Options
|
|
13 BIOS Language
|
|
14 Group Associations
|
|
15 System Event Log
|
|
16 Physical Memory Array
|
|
17 Memory Device
|
|
18 32-bit Memory Error
|
|
19 Memory Array Mapped Address
|
|
20 Memory Device Mapped Address
|
|
21 Built-in Pointing Device
|
|
22 Portable Battery
|
|
23 System Reset
|
|
24 Hardware Security
|
|
25 System Power Controls
|
|
26 Voltage Probe
|
|
27 Cooling Device
|
|
28 Temperature Probe
|
|
29 Electrical Current Probe
|
|
30 Out-of-band Remote Access
|
|
31 Boot Integrity Services
|
|
32 System Boot
|
|
33 64-bit Memory Error
|
|
34 Management Device
|
|
35 Management Device Component
|
|
36 Management Device Threshold Data
|
|
37 Memory Channel
|
|
38 IPMI Device
|
|
39 Power Supply
|
|
40 Additional Information
|
|
41 Onboard Devices Extended Information
|
|
42 Management Controller Host Interface
|
|
.TE
|
|
|
|
Additionally, type 126 is used for disabled entries and type 127 is an
|
|
end-of-table marker. Types 128 to 255 are for \s-1OEM\s0-specific data.
|
|
.B dmidecode
|
|
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\fP.
|
|
Each keyword is equivalent to a list of type numbers:
|
|
|
|
.TS
|
|
l l
|
|
__
|
|
l l.
|
|
Keyword Types
|
|
bios 0, 13
|
|
system 1, 12, 15, 23, 32
|
|
baseboard 2, 10, 41
|
|
chassis 3
|
|
processor 4
|
|
memory 5, 6, 16, 17
|
|
cache 7
|
|
connector 8
|
|
slot 9
|
|
.TE
|
|
|
|
Keywords are matched case-insensitively. The following command lines are equivalent:
|
|
.IP \(bu "\w'\(bu'u+1n"
|
|
dmidecode --type 0 --type 13
|
|
.IP \(bu
|
|
dmidecode --type 0,13
|
|
.IP \(bu
|
|
dmidecode --type bios
|
|
.IP \(bu
|
|
dmidecode --type BIOS
|
|
.\"
|
|
.SH BINARY DUMP FILE FORMAT
|
|
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
|
|
.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),
|
|
.BR ownership (8),
|
|
.BR vpddecode (8)
|