Device tree translation

[zaxeize]

Hello there, i just exporting android dtb from /root/dev/dtb and convert it to dts, here's the screenshot :

 

  

 

i'm confused to translate it (android dts) to armbian (linux dts) 

is there any complete tutorials / guides / software to convert / translate that android dts to armbian dts ?

[jock]

There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.

What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).

As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.

 

Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.

 

All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.

 

Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.

 

 

Edited August 6, 2020 by jock
changed senseless sentences

[lucky62]

I am thinking about automatic conversion of DTB extracted from Android firmware to DTB usable by Armbian (linux).
I am reading the docs about the DT but still I have no clear picture what is required to do this.

 

From the definition, the DT should be OS independent, so why the Android DTB cannot be used directly by Armbian/linux?

 

Currently I have in my mind only two things:

• DTB can be older and not fit to the current standards
• Device names/types (used in compatible=) may be different in linux and thus not recognized

Or am I wrong?...

 

This is new area for me, so any comments are welcome..

 

[lucky62]

Nobody interested?...

 

I was trying to understand, what is the difference between aliases and __symbols__.

I was looking around and found this good web page:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

 

According this page (if I correctly understand) the __symbols__ are required only in overlays to resolve local labels.
But after decompiling few DTBs I see the __symbols__ also in main DTB.

Are these required? Or it is only relique from previous decompile/change/compile actions?

 

[jock]

4 hours ago, lucky62 said:

Nobody interested?...

 

I was trying to understand, what is the difference between aliases and __symbols__.

I was looking around and found this good web page:
https://www.raspberrypi.org/documentation/configuration/device-tree.md

 

According this page (if I correctly understand) the __symbols__ are required only in overlays to resolve local labels.
But after decompiling few DTBs I see the __symbols__ also in main DTB.

Are these required? Or it is only relique from previous decompile/change/compile actions?

 

 

symbols are required in the main dtb because, when the overlay is going to be applied the kernel (or u-boot, or whatever), the kernel needs to know which node is the target. Having the symbols table allows allows the overlays to use the labels (prefixed by & symbol, like &sdio, &emmc, ...) but if you don't have symbols table you need to provide the absolute "path" of the target node.

 

For example, the following overlay requires the symbols table because target references a node via its label:

/ {
	fragment@0 {
		target = <&emmc>;
		__overlay__ {
			status = "okay";
			mmc-ddr-1_8v;
		};
	};
};

 

This other example instead uses target-path and references a node via its absolute path, so it works even without the symbol table:

/ {
    compatible = "rockchip,rk3328";
    fragment@0 {
        target-path = "/opp_table0";
        __overlay__ {
            opp-1392000000 {
                opp-hz = /bits/ 64 <1392000000>;
                opp-microvolt = <1400000>;
                clock-latency-ns = <40000>;
            };
        };
    };
};

 

edit: if you take a look to the symbols table, you see that it is a mere mapping between the node labels and their absolute paths. Aliases are a different thing: they are effectively used to instruct the operating system (or u-boot) about particular devices. For example you can force the operating system to use mmc0 for sdcard and mmc1 for emmc devices specifying them in the aliases stanza, no matter how many mmc controllers are there and the order they are initialized.

[lucky62]

Device Tree Specification tells nothing about symbols.
So __symbols__ should not be a part of DT.

 

Also there is nothing about overlays (dtbo) and/or inclusions (dtbi) in the specification.

But these are very useful/required. So the DT tools can use anything what will help, but the final DT should be aligned with specification (my opinion).