sysfs-firmware-dmi-entries 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114
  1. What: /sys/firmware/dmi/entries/
  2. Date: February 2011
  3. Contact: Mike Waychison <mikew@google.com>
  4. Description:
  5. Many machines' firmware (x86 and ia64) export DMI /
  6. SMBIOS tables to the operating system. Getting at this
  7. information is often valuable to userland, especially in
  8. cases where there are OEM extensions used.
  9. The kernel itself does not rely on the majority of the
  10. information in these tables being correct. It equally
  11. cannot ensure that the data as exported to userland is
  12. without error either.
  13. DMI is structured as a large table of entries, where
  14. each entry has a common header indicating the type and
  15. length of the entry, as well as a firmware-provided
  16. 'handle' that is supposed to be unique amongst all
  17. entries.
  18. Some entries are required by the specification, but many
  19. others are optional. In general though, users should
  20. never expect to find a specific entry type on their
  21. system unless they know for certain what their firmware
  22. is doing. Machine to machine experiences will vary.
  23. Multiple entries of the same type are allowed. In order
  24. to handle these duplicate entry types, each entry is
  25. assigned by the operating system an 'instance', which is
  26. derived from an entry type's ordinal position. That is
  27. to say, if there are 'N' multiple entries with the same type
  28. 'T' in the DMI tables (adjacent or spread apart, it
  29. doesn't matter), they will be represented in sysfs as
  30. entries "T-0" through "T-(N-1)":
  31. Example entry directories::
  32. /sys/firmware/dmi/entries/17-0
  33. /sys/firmware/dmi/entries/17-1
  34. /sys/firmware/dmi/entries/17-2
  35. /sys/firmware/dmi/entries/17-3
  36. ...
  37. Instance numbers are used in lieu of the firmware
  38. assigned entry handles as the kernel itself makes no
  39. guarantees that handles as exported are unique, and
  40. there are likely firmware images that get this wrong in
  41. the wild.
  42. Each DMI entry in sysfs has the common header values
  43. exported as attributes:
  44. ======== =================================================
  45. handle The 16bit 'handle' that is assigned to this
  46. entry by the firmware. This handle may be
  47. referred to by other entries.
  48. length The length of the entry, as presented in the
  49. entry itself. Note that this is _not the
  50. total count of bytes associated with the
  51. entry. This value represents the length of
  52. the "formatted" portion of the entry. This
  53. "formatted" region is sometimes followed by
  54. the "unformatted" region composed of nul
  55. terminated strings, with termination signalled
  56. by a two nul characters in series.
  57. raw The raw bytes of the entry. This includes the
  58. "formatted" portion of the entry, the
  59. "unformatted" strings portion of the entry,
  60. and the two terminating nul characters.
  61. type The type of the entry. This value is the same
  62. as found in the directory name. It indicates
  63. how the rest of the entry should be interpreted.
  64. instance The instance ordinal of the entry for the
  65. given type. This value is the same as found
  66. in the parent directory name.
  67. position The ordinal position (zero-based) of the entry
  68. within the entirety of the DMI entry table.
  69. ======== =================================================
  70. **Entry Specialization**
  71. Some entry types may have other information available in
  72. sysfs. Not all types are specialized.
  73. **Type 15 - System Event Log**
  74. This entry allows the firmware to export a log of
  75. events the system has taken. This information is
  76. typically backed by nvram, but the implementation
  77. details are abstracted by this table. This entry's data
  78. is exported in the directory::
  79. /sys/firmware/dmi/entries/15-0/system_event_log
  80. and has the following attributes (documented in the
  81. SMBIOS / DMI specification under "System Event Log (Type 15)":
  82. - area_length
  83. - header_start_offset
  84. - data_start_offset
  85. - access_method
  86. - status
  87. - change_token
  88. - access_method_address
  89. - header_format
  90. - per_log_type_descriptor_length
  91. - type_descriptors_supported_count
  92. As well, the kernel exports the binary attribute:
  93. ============= ====================================
  94. raw_event_log The raw binary bits of the event log
  95. as described by the DMI entry.
  96. ============= ====================================