27

/proc/device-tree or /sys/firmware/devicetree/base I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc. You can then access dts properties from files: hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency The output format for integers is binary, so hexdump is needed. dtc -I fs Get ...


27

If dtc is available on your platform (else, install the device-tree-compiler package), you can use: dtc -I fs /sys/firmware/devicetree/base


12

Peripherals are connected to the main processor via a bus. Some bus protocols support enumeration (also called discovery), i.e. the main processor can ask “what devices are connected to this bus?” and the devices reply with some information about their type, manufacturer, model and configuration in a standardized format. With that information, the operating ...


10

The device tree is exposed as a hierarchy of directories and files in /proc. You can cat the files, eg: find /proc/device-tree/ -type f -exec head {} + | less Beware, most file content ends with a null char, and some may contain other non-printing characters.


8

When U-Boot executes the boot command, it provides a memory address for the kernel and a memory address for the device tree blob. Therefore, prior to this command, it must load these files into memory. Based on the messages you provided we see that two files failed to be loaded from the eMMC/SD card: /boot/boot.ub /boot/imx6dl-ts4900-13.dtb Its possible ...


8

PCs actually do need a device tree. They just call it something else. It is not correct to say that operating systems for the descendents of PC/AT compatibles assume the existence of things such as a PCI bus. They do not. Nor do they probe. Probing for hardware, just poking some I/O or memory addresses to see whether they work, has not been necessary ...


7

I'm way late on this, but I implemented this script and I'll address this for anyone who finds this using an internet search engine. This computer on module can be put on almost any off the shelf TS or custom baseboard, and we wanted it to automatically work without users having to adjust the device tree used. We have an 8-input shift register on any given ...


6

Have you tried consulting the Xilinx wiki? Build Device Tree Blob This howto looks like it has everything you need to get what you want. There's links to a git repository with code as well as directions on how to build it. Here's the command to download the device-tree sources. $ git clone git://github.com/Xilinx/device-tree.git The Xilinx website also ...


4

From: http://developer.toradex.com/device-tree-customization Nodes can be referenced using the ampersand (&) character and the label. Overwriting properties To overwrite a property, the node needs to be referenced using the ampersand character and the label. Later device tree entries overwrite earlier entries (the sequence order of entries is what ...


4

I'm not sure if I understand you correctly. If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs. You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob. If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go ...


4

In Linux, network interfaces don't have a device node in /dev at all. If you need the list of usable network interfaces e.g. in a script, look into /sys/class/net/ directory; you'll see one symbolic link per interface. Each network interface that has a driver loaded will be listed. Programmatically, you can use the if_nameindex() syscall: see this answer ...


3

The Device Tree is supposed to be a stable ABI so a device tree written for any version of the kernel should work with any following kernel version. However, for practical reasons, this is quite often not the case. You can have a look at the following presentation from Thomas, explaining why: http://free-electrons.com/pub/conferences/2015/elc/petazzoni-dt-...


3

You can get some information from the kernel documentation which describes the interrupts property. It goes on with the example of the OpenPIC interrupt controller which has 2 cells: The first cell defines the interrupt number. The second cell defines the sense and level information. Sense and level information should be encoded as follows: ...


3

You don't need to do this. With this change, overlays are in u-boot! https://github.com/u-boot/u-boot/commit/e6628ad7b99b285b25147366c68a7b956e362878 Enjoy :)


3

After being in a situation where this could be tested I've witnessed that you can't use a device tree compiled for kernel 3.10 on kernel 3.14. and vice versa.


3

The /dev/sd* device names are assigned in a first-come, first-served order by default, as the storage controller drivers are initialized. If you have several different storage controllers, you might be able to manipulate their loading order. If that's not possible, it's time to learn writing udev rules. It's not that difficult. First, run udevadm info -q ...


2

Google refers to Wikipedia, which refers to www.devicetree.org which describes your "device tree" as: The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspect of the hardware can be described in a data structure that is passed to the operating system at boot ...


2

Angle brackets (<>) denotes a "32-bit unsigned integer array" and I believe they are often refereed to as "cells". In the case with the reg property, the first value is the (offset) address and the second the length of the register(s). Note that it is also possible to have multiple ranges i.e. reg = <addr1 addr1_length addr2 addr2_length ... addrN ...


2

You can disable a device node by adding: ps7_ethernet_0: ps7-ethernet@e000b000 { ... status = "disabled"; }; Depending on your device tree include structure you should add this at board specification level. Otherwise there might be a chance that status = "disabled"; is overwritten by a status = "okay"; somewhere.


2

cmdk@0,0:h is the driver instance for a disk. Per the Solaris documentation: The cmdk device driver is a common interface to various disk devices. The driver supports magnetic fixed disks and magnetic removable disks.


2

The issue with your clocks, is that clocks declared outside the TI clock domains are not parsed and set up correctly in 3.17. This issue is resolved in kernel version 4.0.5. The required changes occurred in the function omap_clk_init at the end of /arch/arm/mach-omap2/io.c, there is an extra call there to of_clk_init(NULL) which doesn't exist in 3.17. Some ...


2

A working solution to get the driver to bind to the device is: cgublock: jz4780-cgublock@10000000 { compatible = "simple-bus", "syscon"; #address-cells = <1>; #size-cells = <1>; reg = <0x10000000 0x100>; ranges; cgu: jz4780-cgu@10000000 { compatible = "ingenic,jz4780-cgu"; reg = <0x10000000 ...


2

I ask myself why there isn't a way to put the device tree, as the hardware description, together with the bootloader on some ROM chip and build the Linux OS independently from any hardware specs, at least within some defined limits. Answer: Cheapness. Nobody wants to pay for the ROM chip. The SoC has a boot ROM in it, but the device tree varies depending ...


2

The Linux Kernel Map shows in some detail the device control. It contains something called "drivers" and "modules" that can be extended by "Loadable Kernel Modules". E.G.: USB devices generally have a module that gets loaded when the device gets attached whereas the USB root hub is statically linked into the kernel and an nVidia card need a driver ...


2

The device drivers (i.e. the part of the kernel that interact directly with the hardware) can be compiled as kernel modules. These are separate files, which can be loaded or unloaded by the kernel, as necessary, depending on the hardware present in the system. The generic kernels that are shipped with mainstream Linux distributions tend to be supplied with ...


2

Okay, I found this page which guides me through the basic troubleshooting steps. This was what I was looking for. If you care for our problem itself: Obviously, muxing the pins as MMC (as described in our user's guide) is not sufficient, the bus needs to be declared as being SDIO in the device-tree. Now I can continue to find out how to enable SDIO ...


1

As meuh suggested, this information should be available in the kernel device tree bindings documentation. However, it might not be obvious what file to look at, so here are some advice: First check the compatible property string(s) in the interrupt-parent node (i.e. gpio5 in this case). If you are lucky, the documentation will have a list of all compatible ...


1

A platform in this context is a set of different boards that are similar, e.g. PC motherboards are different, but together they form a platform that can be treated uniformly. A SoC is a System on a Chip, i.e. a CPU and associated peripheral circuits are integrated on one silicon chip. The same SoC can be used on different boards designs, in which case they ...


1

Assuming you are talking about the ARM Linux boot protocol, r1 and r2 are CPU registers. There are 16 general-purpose registers on 32-bit ARM processors, named r0-r15.


1

The raison d'etre of the device tree is to tell what devices are on the system. It is typically needed on platforms that don't provide any automatic detection of devices, i.e. there is no registry of ids you can query (like for USB and PCI devices) and you can't reliably probe for the hardware. The device tree tells which drivers (kernel modules) should be ...


Only top voted, non community-wiki answers of a minimum length are eligible