Understanding Device Trees

[Bozza]

Hello fellow armbianites,

 

It has been put to me that arm based boards require a DTB file because arm works a bit differently than x86.

The difference between an arm and an x86 board, is that x86 is standardised and always has the same form factor.

When you plug in a device into an expansion slot or port on your motherboard the new device announces itself.

All the addresses are known in advance and hence there is no need for a DTB file.

 

On arm on the other hand board design is not standardised. You can design a PCB whichever way you would like and solder any component onto the board that your heart desires.

There is no single way to design an arm PCB. The devices you solder onto the board do not announce themselves. It is therefore important to know the address location of each device and chip that is connected to the arm CPU.

 

This is where the DTB file comes in. Every chip and device that is wired to the CPU is linked in the DTB file.

 

I am trying to modify a DTB file to suit my box. Why is it that I cannot just take the DTB that came with the box and use it for an OS like armbian?

Moreover I have noticed that more recent mainline kernels have now lost audio on one of the ms1 dtb files. Someone has modified a dtb file with a fix for audio.

Why is a modified file needed? The hardware itself hasn't changed, and only the minor kernel revision. The audio chip didn't suddenly grow legs and migrate -1 hexadecimal locations. How can this be explained?

[Werner]

Sometimes the syntax of DTS changes (by upstream). That is why adjustments might be necessary.

Next is also drivers in the kernel change and therefore adjustments to the device tree might be necessary as well to fit the intersection with the kernel.

[Tido]

On 9/2/2020 at 8:33 PM, Bozza said:

that more recent mainline kernels have now lost audio

welcome to the party, not the same but similar in its nature: https://forum.armbian.com/topic/13515-panfrost-on-rk3288-and-gpu-on-600mhz-problems/?do=findComment&comment=104444

 

[guidol]

On 9/2/2020 at 9:33 PM, Bozza said:

Moreover I have noticed that more recent mainline kernels have now lost audio on one of the ms1 dtb files.

@Hannes Worst 

also on the NanoPi A64 with newer mainline kernel is missing the full function of the analog audio (its shown, but doenst make any sound)

HDMI-Audio is working on the NanoPi A64 - but I couldnt find any .dtb-changes for the problem with the analog-audio  

[Bozza]

Let's try to understand the dts/dtb file. At least this way we can modify the file to hopefully make our boxes and boards work better. 

 

The format of the dts file is pretty straightforward. On the left you have the variable names which are the devices on the pcb. On the right hand side you have the hexadecimal address location of the said device.

 

First we need to know the device name we want to modify. I am guessing the names are determined by the kernel and drivers. For instance in android4.9 you might have the device name bluetooth but in a mainline kernel it might be bt_dev. Again, as I understand this name might be determined by the drivers so it could differ on each box even with the same kernel version. For example on my stock image I have an entry for cyx-vdt. In other dtb files openvdt is used.

 

Another thing that we need to know is the hexadecimal address of the devices.  One way this could be found is through trial and error by looking at dtb files that work for your box and making a custom dtb file. If only your WiFi works with x.dtb but ethernet only works with y.dtb you could find the relevant bits to make an xy.dtb with both WiFi and ethernet. 

However if hexadecimal locations change with kernel or driver revisions I have no idea how the new address can be identified. 

 

Does anyone have any idea how any of this can be done? 

[Bozza]

There is a value called the phandle. 

This value is very much like a unique ID number. As far as I understand it is assigned to each device, however the ID can be anything you want it to be. The phandle is used to link different entries in different locations of the dts/dtb. (like a trace on a pcb). 

 

Now this is where it gets complicated and can get confusing. If your audio or WiFi isn't working it is tempting to take parts of two dtb files and stitch them together. This is not possible because the phandles are arbitrary and can differ from dtb to dtb. 

 

For example your x.dtb might give the audio device the phandle ID of 25, while your y.dtb might give that same phandle to your USB device. If you attempt to stitch them together you might lose both audio and USB.

 

I have a suspicion that a lot of these TV box devices were made by stitching different files together while leaving a lot of bad syntax in the device trees. These dtb files are turning out to be more fun than I thought. 

[Tido]

56 minutes ago, Bozza said:

These dtb files are turning out to be more fun than I thought. 

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

[jock]

I am a bit ashamed of citing myself, but this is a small post I wrote some time ago with some explanations:

 

https://forum.armbian.com/topic/14752-device-tree-translation/?do=findComment&comment=106284