Provided DTB = No Ethernet

Hello,

I think I may have found a bug in the provided DTB file, tegra186-quill-p3310-1000-c03-00-base.dtb. I followed this tutorial: https://devtalk.nvidia.com/default/topic/1024806/jetson-tx2/how-to-enable-spi-spidev-on-28-1-on-target and got SPI to work, but my Ethernet port stopped working.

On a hunch, I then pointed extlinux.conf to point to the unmodified DTB file that is provided with L4T 28.1. My Ethernet port still does not work. If I remove the “FDT” line completely (i.e., I revert back to the original extlinux.conf), my Ethernet port starts working again.

As a result, I’m wondering how I need to patch the DTB file to fix this Ethernet issue and if there are any other gremlins associated with the provided DTB file. My design requires SPI, so I need a stable baseline DTB in order to add the necessary SPI definitions.

Thanks in advance for the help.

The mechanics of using the FDT entry is valid only prior to the R28.1 release. At R28.1 FDT cannot be used, and hidden partitions instead contain the device tree. So the answer is probably not how to change the device tree so far as editing goes, and the tree you used is probably valid…but the way you install it now differs.

After copying the dtb to the right place, you would flash just the one partition via:

sudo ./flash.sh -r -k DTB jetson-tx1 mmcblk0p1

For more explanation see (the TX1 and TX2 use the same rootfs at R28.1, and though there are some differences, the following notes when talking TX1 or TX2):

https://elinux.org/Jetson/TX2_DTB

There is an option I have not tried, someone has found dd to work for this as well:
https://devtalk.nvidia.com/default/topic/1021660/jetson-tx1/is-there-any-other-method-in-l4t-r28-1-to-update-dtb-file-for-tx1-besides-flashing-the-dtb-partitio-/post/5200056/#5200056

sudo dd if=tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb of=/dev/mmcblk0p13
(mmcblk0p13 is the DTB partition in my TX1)

Just to make sure I understand what I need to do (here are the steps):

  1. On the host (i.e., NOT the TX2 itself), copy the modified DTB to JetPack/3.1/64_TX2/Linux_for_Tegra_64_tx2/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb.
  2. Place the TX2 into recovery mode, connect USB cable, etc.
  3. On the host, run:
sudo ./flash -r -k kernel-dtb jetson-tx2 mmcblk0p1

, where flash.sh is found in JetPack/3.1/64_TX2/Linux_for_Tegra_64_tx2.

Is that correct? Sorry for the simplistic questions, but I have always flashed the board just using the JetPack GUI and not the scripts themselves.

That is correct. JetPack is just a front end for the flash.sh script and package installs.

Hi linuxdev,

Thanks for your help. I actually found some of your other posts that helped me out.

Namely, I found this command:

dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

This now gives me a DTS file of ALL the current settings. From there, I edited the DTS file to add my SPI configuration and compiled it to a DTB. I then edited extlinux.conf to point to this newly created DTB, which works like a champ.

This set-up ends up working better for me versus flashing the DTB partition because if I ever need to revert to the “factory” DTB, I just need to revert my extlinux.conf file.

This experiment points to two facts:

  1. The provided DTB does NOT contain all the necessary settings for various pieces of hardware. The only way to pull all those settings into a DTS is to use the command I referenced above.
  2. extlinux.conf takes priority over what’s in the DTB partition. That is, if you point extlinux.conf to a DTB file, then it will ignore the partition.

Thanks again for your help. It looks like everything is now working.

I am surprised that extlinux.conf was able to work. Some of what is in this file still works as usual, but a large chunk of it is inherited directly from U-Boot and not modifiable from anything extlinux.conf points at. I think if you were to edit something already in the DTB partition your override might fail if it is in the FDT entry.

I believe part of the reason things have changed since earlier releases is that the boot loader stage itself is now supporting the TX1 boot mechanics and the TX2 boot mechanics, and the two are significantly different. Even U-Boot has to have some device tree setup before it can hand off to Linux.

Yes, it is hard to trust “defaults”, it is easier to trust the kernel telling us exactly what it sees.