Dear,
Previously we used dd tool to backup and restore the device tree for Jetson nano: dd if=/dev/mmcblk0p2 of=backup.dtb, and seems now it doesn’t work.
Also on the Jetpack 4.6, I found that the command:“ls -al /dev/disk/by-partlabel” to check the label of device tree, is also not work.
Any update to this part? What’s the proper tool to backup and restore the dtb file on Jetson Nano?
Thanks!
Use the extlinux.conf under /boot/extlinux/extlinux.conf to directly read the dtb from rootfs.
You can write one more option there and choose this option in uboot console.
Added notes: Unless security fuses are burned the existence of an FDT entry in extlinux.conf takes precedence over the partition. If the partition is being used, the it must be signed for it to be allowed. If you used dd to backup that partition, and if there is no extlinux.conf FDT entry, and if you restore to the same exact Jetson, then restore probably works. If there has been a version update which updated anything in the partition, then perhaps the signing is wrong (e.g., using a backup from one Jetson and putting on another might fail for reasons of signing).
Thanks for the replying.
The problem we meet is: we released our product basing on JetPack 4.4.1, at the that time, the device tree still works from the partition mmcblk0p2, and we did some customization on the device tree to make the USB OTG port working as the host also. At our manufacturing side, we use the flash.sh tool to flash the the customized DTB to nano, at one of our customer’s side, they reported the USB port is not working as host, so we took some investigation and found that on that device the DTB file loaded is not what we customized, instead it’s the NVIDIA default on the JetPack 4.4.1 version.
So the question is:
For question 2, my previous reply is already the answer…
Thanks Wayne,
But that means for this customer, we will need to modify the exlinux.conf to offer a unique way to load the dtb comparing to other customers? This could not be a ideal solution since we are creating standard products instead of one-time business…
The default dtb is read from the partition. It didn’t change in each release.
But actually I don’t use something like “mmcblk0p2” to recognize such partition. Using flash.sh to flash DTB partition would definitely flash the dtb to what you want.
And trust me, using extlinux.conf is already the easiest method now since dd cannot be used due to some update in bootloader.
The rest one you can try is the BUP payload updater.
On the earlier version of JetPack, like 4.4.1, the partition can be viewed through command: ls -al /dev/disk/by-partlablel:
gel-x@gelx-desktop:~$ ls -al /dev/disk//by-partlabel/
total 0
drwxr-xr-x 2 root root 380 9月 10 13:09 .
drwxr-xr-x 8 root root 160 9月 10 13:09 ..
lrwxrwxrwx 1 root root 15 9月 10 13:09 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 16 9月 10 13:09 BMP -> ../../mmcblk0p10
lrwxrwxrwx 1 root root 15 9月 10 13:09 DTB -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 9月 10 13:09 DTB-1 -> ../../mmcblk0p6
lrwxrwxrwx 1 root root 15 9月 10 13:09 EKS -> ../../mmcblk0p4
lrwxrwxrwx 1 root root 15 9月 10 13:09 EKS-1 -> ../../mmcblk0p8
lrwxrwxrwx 1 root root 16 9月 10 13:09 kernel-bootctrl -> ../../mmcblk0p14
lrwxrwxrwx 1 root root 16 9月 10 13:09 kernel-bootctrl_b -> ../../mmcblk0p15
lrwxrwxrwx 1 root root 15 9月 10 13:09 LNX -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 15 9月 10 13:09 LNX-1 -> ../../mmcblk0p9
lrwxrwxrwx 1 root root 16 9月 10 13:09 recovery -> ../../mmcblk0p12
lrwxrwxrwx 1 root root 16 9月 10 13:09 recovery-dtb -> ../../mmcblk0p13
lrwxrwxrwx 1 root root 16 9月 10 13:09 RECROOTFS -> ../../mmcblk0p16
lrwxrwxrwx 1 root root 16 9月 10 13:09 RP4 -> ../../mmcblk0p11
lrwxrwxrwx 1 root root 15 9月 10 13:09 TOS -> ../../mmcblk0p3
lrwxrwxrwx 1 root root 15 9月 10 13:09 TOS-1 -> ../../mmcblk0p7
lrwxrwxrwx 1 root root 16 9月 10 13:09 UDA -> ../../mmcblk0p17
And following the instruction in the below link, dd tool is mentioned as a tool to update the device tree on Jetson devices.
You have to understand what is the official document and what is not.
Ridgerun is not maintained by us. It is not a official document. We won’t guarantee the method on it will work in every release.
I don’t know what is your point to give out that page. Already mentioned the same thing twice previously. “dd” is not a tool that we would guarantee it can update the partition without problem.
If you just want to change the dtb in device, use extlinux.conf. Or use the BUP payload updater. Read the L4T document if you never used that.
I just want to reiterate that if the extlinux.conf file has an FDT key/value pair in it (with a device tree binary location named), then it uses this even if you’ve updated the partition…except if security fuses were burned. So for your question 1, you need to know if (A) the security fuses were burned on an eMMC model, and (B) if the extlinux.conf names a “.dtb” file before you can answer which device tree is used.
Thanks for the clarification, I will refer to L4T document instead.
The point is that, we are not just need to modify the device tree on one certain device, instead, as we are using Jetson nano to create standlized products, we need to seek for a secure way to maintain the update/fix of device tree on our custmer’s products.
And that device is alreay remotely on the customer’s hand, in which dtb is not maintained by the FDT in extlinux.conf.
BTW, we tried also with FDT, it’s not 100% secure,
Thanks for helping clarifying more details.
One additional question, how can we check if security fuses were burned?
We are using flash.sh tool for flash the device, is this contained as the default option?
For question B, in our case, there is no added FDT setting, with “.dtb” file selected.
It was a bug in uboot and should be fixed in jetpack4.6.
When you see some bug in a release and you know that your release is not the latest one, please move to latest one and try.
You will not be the first person to ask “how to change dtb” question in this forum.
Understood, for sure, we will consider to use the latest JP4.6 for our later product releases.
But now, we are really suffering, because, we have the customized version on V4.4, and we have install base on our customer’s side which carries the default version dtb of V4.5, if we can not fix the problem remotely, we will need to ask the customer to return the device, which is not easy as not in the same country…
Anyway, thanks for offering the suggestions and clarification.
I don’t have a version with a burned fuse (in fact I only have an early SD card model, which doesn’t have such fuses…eMMC models have fuses), so I couldn’t tell you how to check. However, you would very likely know if the fuse were burned.
In the case of units with a burned fuse the flash software would refuse to flash (edit: or flash then refuse to use the content during boot) that non-rootfs content unless you have the correct key. If all of your customers have non-fuse-burned versions, then it will be easier since you would need the private key to sign each specific board’s content as it is flashed for eMMC models with burned fuses. Someone using special tools (e.g., “dd”) to install content onto those signed partitions might succeed in adding such content, but the content (and or boot) would be rejected without proper signing.
Someone else may be able to answer how to check if fuses are burned from a booted eMMC unit without actually running flash software.
Thanks for the updating.
We will check of MFG tool to make sure if the efuses were burned. And try to create th signed version and double check.