111 lines
4.0 KiB
Plaintext
111 lines
4.0 KiB
Plaintext
What: /sys/firmware/dmi/entries/
|
|
Date: February 2011
|
|
Contact: Mike Waychison <mikew@google.com>
|
|
Description:
|
|
Many machines' firmware (x86 and ia64) export DMI /
|
|
SMBIOS tables to the operating system. Getting at this
|
|
information is often valuable to userland, especially in
|
|
cases where there are OEM extensions used.
|
|
|
|
The kernel itself does not rely on the majority of the
|
|
information in these tables being correct. It equally
|
|
cannot ensure that the data as exported to userland is
|
|
without error either.
|
|
|
|
DMI is structured as a large table of entries, where
|
|
each entry has a common header indicating the type and
|
|
length of the entry, as well as a firmware-provided
|
|
'handle' that is supposed to be unique amongst all
|
|
entries.
|
|
|
|
Some entries are required by the specification, but many
|
|
others are optional. In general though, users should
|
|
never expect to find a specific entry type on their
|
|
system unless they know for certain what their firmware
|
|
is doing. Machine to machine experiences will vary.
|
|
|
|
Multiple entries of the same type are allowed. In order
|
|
to handle these duplicate entry types, each entry is
|
|
assigned by the operating system an 'instance', which is
|
|
derived from an entry type's ordinal position. That is
|
|
to say, if there are 'N' multiple entries with the same type
|
|
'T' in the DMI tables (adjacent or spread apart, it
|
|
doesn't matter), they will be represented in sysfs as
|
|
entries "T-0" through "T-(N-1)":
|
|
|
|
Example entry directories:
|
|
|
|
/sys/firmware/dmi/entries/17-0
|
|
/sys/firmware/dmi/entries/17-1
|
|
/sys/firmware/dmi/entries/17-2
|
|
/sys/firmware/dmi/entries/17-3
|
|
...
|
|
|
|
Instance numbers are used in lieu of the firmware
|
|
assigned entry handles as the kernel itself makes no
|
|
guarantees that handles as exported are unique, and
|
|
there are likely firmware images that get this wrong in
|
|
the wild.
|
|
|
|
Each DMI entry in sysfs has the common header values
|
|
exported as attributes:
|
|
|
|
handle : The 16bit 'handle' that is assigned to this
|
|
entry by the firmware. This handle may be
|
|
referred to by other entries.
|
|
length : The length of the entry, as presented in the
|
|
entry itself. Note that this is _not the
|
|
total count of bytes associated with the
|
|
entry_. This value represents the length of
|
|
the "formatted" portion of the entry. This
|
|
"formatted" region is sometimes followed by
|
|
the "unformatted" region composed of nul
|
|
terminated strings, with termination signalled
|
|
by a two nul characters in series.
|
|
raw : The raw bytes of the entry. This includes the
|
|
"formatted" portion of the entry, the
|
|
"unformatted" strings portion of the entry,
|
|
and the two terminating nul characters.
|
|
type : The type of the entry. This value is the same
|
|
as found in the directory name. It indicates
|
|
how the rest of the entry should be interpreted.
|
|
instance: The instance ordinal of the entry for the
|
|
given type. This value is the same as found
|
|
in the parent directory name.
|
|
position: The ordinal position (zero-based) of the entry
|
|
within the entirety of the DMI entry table.
|
|
|
|
=== Entry Specialization ===
|
|
|
|
Some entry types may have other information available in
|
|
sysfs. Not all types are specialized.
|
|
|
|
--- Type 15 - System Event Log ---
|
|
|
|
This entry allows the firmware to export a log of
|
|
events the system has taken. This information is
|
|
typically backed by nvram, but the implementation
|
|
details are abstracted by this table. This entry's data
|
|
is exported in the directory:
|
|
|
|
/sys/firmware/dmi/entries/15-0/system_event_log
|
|
|
|
and has the following attributes (documented in the
|
|
SMBIOS / DMI specification under "System Event Log (Type 15)":
|
|
|
|
area_length
|
|
header_start_offset
|
|
data_start_offset
|
|
access_method
|
|
status
|
|
change_token
|
|
access_method_address
|
|
header_format
|
|
per_log_type_descriptor_length
|
|
type_descriptors_supported_count
|
|
|
|
As well, the kernel exports the binary attribute:
|
|
|
|
raw_event_log : The raw binary bits of the event log
|
|
as described by the DMI entry.
|