Retrieve DTB from partition

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Hi all,
I have 2 Jetson Tx2 systems that are behaving in different ways.
I suspect this is due to different DTBs they were flashed with.

I would like to compare these 2 DTBs and see if they actually differ. If that is the case, i would then modify one of the two to match the other.

Now, I know that the DTB the u-boot loads is the one written in the partition, because my extlinux.conf file doesn’t have an FDT entry.
I also know that the DTB differs from the one specified in /boot/dtb/ because I modified the extlinux.conf to point to that file and the system bricked.

How can I retrieve the DTB my system is using at the moment?
Can I just use dd? How do I recognize the right partition in that case?

Regards,
Andrea

2

I am curious about your board status. You said “the system bricked”.

If board is bricked, how do you dd it?

3

If the system is able to boot, you can also use the method as below. This one would dump the dtb in use.

Please be careful that this one is “the dtb in use”. It is not always from the partition.

dtc -I fs -O dts /sys/firmware/devicetree/base
1 Like
4

You should also note that partition content is signed before it is flashed. Two different Jetsons with the same device tree partition will have different content if signatures are different, and both would be valid…but only for the Jetson which the signature matches. If you were to use something like dd to extract such a partition, then the actual content is a subset less the signature. I don’t know enough to tell you how much or where the signature is.

The correct method of installing the same tree to a partition is to place it in the correct location for the original tree which was somewhere under “Linux_for_Tegra/”. Then, during flash, a signed version for a given Jetson is generated for the flash, and then the signed version is deleted. If you flash on command line using “flash.sh”, and save a log, then you will be able to see exactly which tree file was used for generating the signed file.

1 Like
5

Thanks for the answers.
I was trying to find the actual dtb in use (which I thought was the one from the partition).

I bricked but I also managed to restore it (luckily) by backing up the exlinux.conf file.

I knew about the flash method, but I couldn’t be sure the files in my host would be the ones that generated the particular DTB in my Jetson.

I solved my problem by using the dtc snippet.
However for future use, this observation might be useful:
I tried to dd the partition that I identified with

ls -al /dev/disk/by-partlabel

but it was empty.
Gparted sees an empty partition and mounting it has no effect.
What is wrong with this approach?

P.S: turns out that my two systems are using the same DTB except for the bootargs, in which two arguments are different:

tegra_fbmem2=0x800000@0x9607d000 lut_mem2=0x2008@0x9607a000

I obviously checked the extlinux.conf and they both list:

 APPEND ${cbootargs} quiet

Any idea on how these arguments could have been originated?

Thanks,
Andrea

6

I am more curious about which jetpack release are in use here. Generally, these two are not something you need to manually modify.

7

I am using Jetpack 4.3 L4T 32.3.1.

I don’t remember dealing with those parameters, but for sure we modified the devtree to remove iommu and generally match our custom board.

8

The “quiet” should be removed while testing. The “${cbootargs}” is inherited from boot stages prior to the Linux kernel being loaded. Although it is possible the content would be edited by the earlier boot stages you can consider the device tree node “chosen->bootargs” has this content. To see what the content in the device tree is check out this command:
cat /proc/device-tree/chosen/bootargs

The above is likely a verbatim quote from the actual device tree. Sometimes there are things the early boot stages need to know, and so this is why it is in the device tree. One would have to change the device tree to change this content. This content is in part determined at boot time based on the parameters passed to flash.sh. For example, naming “jetson-tx2” looks at a given “.conf” file to determine this, while some other target, e.g., some other model being named, would look at a different “.conf” file, and those files would determine how they differ.

In the above the files listed in “/dev/disk/by-partlabel” should be visible as partition names from
sudo gdisk -l /dev/mmcblk0
(I am assuming an eMMC device)

1 Like
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.