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