brintos

brintos / linux-shallow public Read only

0
0
Text · 4.2 KiB · b6c2380 Raw
115 lines · plain
1What:		/sys/firmware/dmi/entries/2Date:		February 20113Contact:	Mike Waychison <mikew@google.com>4Description:5		Many machines' firmware (x86 and arm64) export DMI /6		SMBIOS tables to the operating system.  Getting at this7		information is often valuable to userland, especially in8		cases where there are OEM extensions used.9 10		The kernel itself does not rely on the majority of the11		information in these tables being correct.  It equally12		cannot ensure that the data as exported to userland is13		without error either.14 15		DMI is structured as a large table of entries, where16		each entry has a common header indicating the type and17		length of the entry, as well as a firmware-provided18		'handle' that is supposed to be unique amongst all19		entries.20 21		Some entries are required by the specification, but many22		others are optional.  In general though, users should23		never expect to find a specific entry type on their24		system unless they know for certain what their firmware25		is doing.  Machine to machine experiences will vary.26 27		Multiple entries of the same type are allowed.  In order28		to handle these duplicate entry types, each entry is29		assigned by the operating system an 'instance', which is30		derived from an entry type's ordinal position.  That is31		to say, if there are 'N' multiple entries with the same type32		'T' in the DMI tables (adjacent or spread apart, it33		doesn't matter), they will be represented in sysfs as34		entries "T-0" through "T-(N-1)":35 36		Example entry directories::37 38			/sys/firmware/dmi/entries/17-039			/sys/firmware/dmi/entries/17-140			/sys/firmware/dmi/entries/17-241			/sys/firmware/dmi/entries/17-342			...43 44		Instance numbers are used in lieu of the firmware45		assigned entry handles as the kernel itself makes no46		guarantees that handles as exported are unique, and47		there are likely firmware images that get this wrong in48		the wild.49 50		Each DMI entry in sysfs has the common header values51		exported as attributes:52 53		========  =================================================54		handle	  The 16bit 'handle' that is assigned to this55			  entry by the firmware.  This handle may be56			  referred to by other entries.57		length	  The length of the entry, as presented in the58			  entry itself.  Note that this is _not the59			  total count of bytes associated with the60			  entry.  This value represents the length of61			  the "formatted" portion of the entry.  This62			  "formatted" region is sometimes followed by63			  the "unformatted" region composed of nul64			  terminated strings, with termination signalled65			  by a two nul characters in series.66		raw	  The raw bytes of the entry. This includes the67			  "formatted" portion of the entry, the68			  "unformatted" strings portion of the entry,69			  and the two terminating nul characters.70		type	  The type of the entry.  This value is the same71			  as found in the directory name.  It indicates72			  how the rest of the entry should be interpreted.73		instance  The instance ordinal of the entry for the74			  given type.  This value is the same as found75			  in the parent directory name.76		position  The ordinal position (zero-based) of the entry77			  within the entirety of the DMI entry table.78		========  =================================================79 80		**Entry Specialization**81 82		Some entry types may have other information available in83		sysfs.  Not all types are specialized.84 85		**Type 15 - System Event Log**86 87		This entry allows the firmware to export a log of88		events the system has taken.  This information is89		typically backed by nvram, but the implementation90		details are abstracted by this table.  This entry's data91		is exported in the directory::92 93		  /sys/firmware/dmi/entries/15-0/system_event_log94 95		and has the following attributes (documented in the96		SMBIOS / DMI specification under "System Event Log (Type 15)":97 98		- area_length99		- header_start_offset100		- data_start_offset101		- access_method102		- status103		- change_token104		- access_method_address105		- header_format106		- per_log_type_descriptor_length107		- type_descriptors_supported_count108 109		As well, the kernel exports the binary attribute:110 111		=============	  ====================================112		raw_event_log	  The raw binary bits of the event log113				  as described by the DMI entry.114		=============	  ====================================115