sysfs-firmware-ofw 2.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152
  1. What: /sys/firmware/devicetree/*
  2. Date: November 2013
  3. Contact: Grant Likely <grant.likely@arm.com>, devicetree@vger.kernel.org
  4. Description:
  5. When using OpenFirmware or a Flattened Device Tree to enumerate
  6. hardware, the device tree structure will be exposed in this
  7. directory.
  8. It is possible for multiple device-tree directories to exist.
  9. Some device drivers use a separate detached device tree which
  10. have no attachment to the system tree and will appear in a
  11. different subdirectory under /sys/firmware/devicetree.
  12. Userspace must not use the /sys/firmware/devicetree/base
  13. path directly, but instead should follow /proc/device-tree
  14. symlink. It is possible that the absolute path will change
  15. in the future, but the symlink is the stable ABI.
  16. The /proc/device-tree symlink replaces the devicetree /proc
  17. filesystem support, and has largely the same semantics and
  18. should be compatible with existing userspace.
  19. The contents of /sys/firmware/devicetree/ is a
  20. hierarchy of directories, one per device tree node. The
  21. directory name is the resolved path component name (node
  22. name plus address). Properties are represented as files
  23. in the directory. The contents of each file is the exact
  24. binary data from the device tree.
  25. What: /sys/firmware/fdt
  26. Date: February 2015
  27. KernelVersion: 3.19
  28. Contact: Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org
  29. Description:
  30. Exports the FDT blob that was passed to the kernel by
  31. the bootloader. This allows userland applications such
  32. as kexec to access the raw binary. This blob is also
  33. useful when debugging since it contains any changes
  34. made to the blob by the bootloader.
  35. The fact that this node does not reside under
  36. /sys/firmware/device-tree is deliberate: FDT is also used
  37. on arm64 UEFI/ACPI systems to communicate just the UEFI
  38. and ACPI entry points, but the FDT is never unflattened
  39. and used to configure the system.
  40. A CRC32 checksum is calculated over the entire FDT
  41. blob, and verified at late_initcall time. The sysfs
  42. entry is instantiated only if the checksum is valid,
  43. i.e., if the FDT blob has not been modified in the mean
  44. time. Otherwise, a warning is printed.
  45. Users: kexec, debugging