dts2tsv

[dieselnutjob]

Suppose that you have a bunch of dtb/dts files that are known good (like from Linux kernel source).

Suppose that you have a dtb file that you ripped out of some new device and probably no source code.

This tool will allow to dump all of the parameters (nodes) out of the dtb file and compare it with all of the other ones that you have in a spreadsheet so that you can visualise the differences.

 

See https://github.com/dieselnutjob/dts2tsv

[tparys]

Interesting.

 

Another option that I use commonly is to disassemble .dtb files into .dts, and then use "meld" to find (and merge) differences between files.

[dieselnutjob]

I have just done a major update to dts2tsv.

One of the problems I had is that decompiled dtb files from different places can have misaligned phandle values.

Specifically a value might be a either text, a variable (in u32 form) or a pointer to a variable (a phandle).

When you look at a number in a value it's not easy to tell whether it's a variable or phandle, and when comparing two dtb files it is likely that they appear to be different, when actually two phandles are pointing at the same thing.

If you have original source code for a dts file you can tell whether a value is a u32 or a phandle, however that information is lost when the file is compiled.

Additionally if you have two similar devices, one with source code and one without, the one with source code will give you clues about the values in the dtb file from the device without.

This new version accepts two different types of file as input now.

-s [files]  These are source code files, and the program uses it to build a list of which values are variables and which are phandles.

-d [files]  These are decompiled dtb files.

The program will use the -s files to identify which values in the -d files are phandles, and then in each file it will search for values that own that phandle and substitute in the name, in other words what the phandle actually points to.

It seems to work quite well.

 

The reason that I wrote this program is that I want to be able to modify source code dts from similar devices to create source code for a device for which I have only decompiled dtb.

 

I want the resultant source code to produce a dtb that is as close as possible to the original vendor dtb, so get it as safe as possible and most likely to boot.  Having a comparison tool that tells me how close I am getting and what the differences still are is, I think, useful.

[dieselnutjob]

version 3 is on github.

This version will, if a label uses a different string to the nodename that it refers to, attempt to do a lookup for phandles to the label as will as nodenames.

This dramatically cuts down the differences between two similar boards in the dtb files.

I don't think that it's perfect and I only tested it on Rockchip 4.19 files, but it's progress.

[dieselnutjob]

I just did a big update to version 4.

 

This version contains quite a lot of the logic of how a dts file is actually compiled.

It recursively loads in a specified dts file and then all of the dtsi and .h files that are mentioned and reassembles the whole thing.

Then it searches for node labels that are references in nodes and childnodes and automatically converts those node labels into nodes as then would appear in the compiled dtb file.

 

I have tested this with 4.19 rockchip dtb file because that is what I am interested in and it seems to work very well.

 

[dieselnutjob]

Here is an example of what the output looks like.  The true/false column is the result of "=EXACT(C1,D1)", in other words true means that the value is of the unknown device is the same as rk3566-quartz-a and false means that it is different.

The magic of the program is that "true" means that in the case of a phandle that the values that are pointed to by the phandle are the same rather than the value of the phandle itself.