Confused between Device Tree and Device Tree Overlay.What to use for the new Driver?


I have been following this famous link from Robert Nelson for kernel building :

I have been reading and trying the concept of Device Tree for a new Driver i am writing.To start with I tried to build a sample dts file( leds-ns2.dts) by copying it into the KERNEL/scripts/dtc folder

dtc -I dts -O dtb -o mydtb.dtb leds-ns2.dts

below is the content of the leds-ns2.dts

I’m not sure there is a one-stop shop for understanding the Device Tree anywhere.

There are at least 4 file types involved:

  1. dts- This is the source code (text file) which is a data structure to describe hardware.
  2. dtsi- A sub-chunk or “include” file which is used inside dts files. It’s somewhat similar to an “include” or “import” in programming languages.
  3. dtb- Device tree blob. This is the compiled version of the dts. This is what gets loaded at boot time. It’s the foundation of the system used by the kernel.
  4. dtbo- Device tree overlay. This can be loaded after boot time. This is how the Beaglebone adjusts itself when different “capes” are plugged in. It does this by reading information stored in the EEPROM in the cape. These “overlays” can also be loaded at the command line using the “slots” in the sysfs virtual file system. Look for a substantial collection of already done overlays in the directory /lib/firmware. If you want to make your own overlay, /lib/firmware is where you want to place it.

This topic is really confusing, and no doubt my notes above are full of flaws.

You can work through and understand all of the above. However, depending on the complexity of what you are trying to do, this may be sufficient:

Using the config-pin -f option and a simple text file you can use your .profile or similar start-up configuration file to set the pins to your requirements.
This is a relatively straight-forward solution to tacking the problem.

In my opinion the device tree is a major hurdle to making progress with the Beaglebones. If you google you will get a bunch of out-dated information, so be careful what you read on the net. Perhaps someone will suggest single source of accurate information on this topic.


Hi Greg,
Thankyou for the elaborative post and the link you sent.My understanding is mainly theoretical and inlined with what you wrote…

Yes,I have been scanning across many links on google and stack overflow but not able to find single one convincing.

I came to conclusion that i will write a hello world gpio driver with lots of printk and build it along with the dts file by placing it in arch/arm/boot/dts and then loading that kernel image.According to R.Nelson’s link i will copy the dtb files as well.
Init–> probe–>register platform driver(.compatible string in the platform_device structure ) should throw something to go ahead with then.

But still the loop holes in the understanding like why to copy all the dtb files,how to build only that dtb file and copy it in the lib/firmware and dynamically insmod the driver …where does overlays come into the picture…can the drivers without dtb implementation be accepted in kernelmain line…

Really looking for some example code here.

Note the structure here form this modified file( Modified from Charles S’ Universal IO overlay ‘univ-all’ ) This is for a single pin instead of all pins.

IN short here is what is required:

  • /dts-v1/;
  • /plugin/;
  • / {
  • compatible = “ti,beaglebone”, “ti,beaglebone-black”, “ti,beaglebone-green”;
  • part-number = “univ-P8_07”;
  • version = “00A0”;

Passed that exclusive-use = “P8.7”; ive seen in each overlay for pins each uses. BUt if you examine this file closely it should become apparent what is required to make a like overlay function. This specific file is mean to offer the ability to change pin mux dynamically as the system is running. So there are 5 possibilities from this file, but initially the pin is configured as input.

I will tell you what helps me a good bit while editing device tree files. You need a good editor that will allow you to arbitrarily set syntax highlighting. Then, I personally set syntax highlighting to “C”.


/ {
compatible = “ti,beaglebone”, “ti,beaglebone-black”, “ti,beaglebone-green”;

/* identification */
part-number = “univ-P8_07”;
version = “00A0”;

/* state the resources this cape uses */
exclusive-use = “P8.7”;

/* P8_07 (ZCZ ball R7 ) /
P8_07_default_pin: pinmux_P8_07_default_pin {
pinctrl-single,pins = <0x090 0x37>; }; /
Mode 7, Pull-Up, RxActive /
P8_07_gpio_pin: pinmux_P8_07_gpio_pin {
pinctrl-single,pins = <0x090 0x2F>; }; /
Mode 7, RxActive /
P8_07_gpio_pu_pin: pinmux_P8_07_gpio_pu_pin {
pinctrl-single,pins = <0x090 0x37>; }; /
Mode 7, Pull-Up, RxActive /
P8_07_gpio_pd_pin: pinmux_P8_07_gpio_pd_pin {
pinctrl-single,pins = <0x090 0x27>; }; /
Mode 7, Pull-Down, RxActive /
P8_07_timer_pin: pinmux_P8_07_timer_pin {
pinctrl-single,pins = <0x090 0x32>; }; /
Mode 2, Pull-Up, RxActive */

fragment@1 {
target = <&ocp>;
overlay {

P8_07_pinmux {
compatible = “bone-pinmux-helper”;
status = “okay”;
pinctrl-names = “default”, “gpio”, “gpio_pu”, “gpio_pd”, “timer”;
pinctrl-0 = <&P8_07_default_pin>;
pinctrl-1 = <&P8_07_gpio_pin>;
pinctrl-2 = <&P8_07_gpio_pu_pin>;
pinctrl-3 = <&P8_07_gpio_pd_pin>;
pinctrl-4 = <&P8_07_timer_pin>;

fragment@2 {
target = <&ocp>;
overlay {

cape-universal {
compatible = “gpio-of-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <>;

P8_07 {
gpio-name = “P8_07”;
gpio = <&gpio2 2 0>;

Can you name the editor?Is the dt is also like python where the Tabs and special character may ruin its compiling?
Also does dtc compiler checks for the sanity of the file besides checking these tabs,syntax,etc.I mean what if it compiles fine but there is an issue in the dt?
Also can you please elaborate more on the example dt below.Is it a device tree or device tree overlay?Also way to compile it.

I use sublime text 3. And no device tree syntax is nothing like python.

Hi William,
can you please elaborate on the purpose for the cape-overlay you have written.How did you compile and pushed it into the beagleboneblack?Where did you place the compiled .dtb/.dtbo?