115 lines
		
	
	
		
			4.2 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			115 lines
		
	
	
		
			4.2 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| What:		/sys/firmware/dmi/entries/
 | |
| Date:		February 2011
 | |
| Contact:	Mike Waychison <mikew@google.com>
 | |
| Description:
 | |
| 		Many machines' firmware (x86 and arm64) 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.
 | |
| 		=============	  ====================================
 |