Hi,
We are using Jetson Nano production modules for our project. We install licenses on these Nanos before they are shipped to customers, so that our encrypted software can run on it and stay secure.
Now suppose due to some update for the Nanos we use, if we need to change the dtb, it is very difficult to call back the systems we ship to our customers.
Besides, even if we do call the Nanos back, we need to flash them again to update the device tree (dtb). Thus we lose our original license and have to fetch a new one, which is expensive.
So my question is⊠Is it possible to just update the dtb remotely, like if I am able to log in to a Nano via SSH at a customer from our location? That is, without the USB cable and all. We are looking to avoid the above-mentioned problems.
Please note that we have the cross compilation setup ready on our host machines, and due to our custom drivers and other requirements, we initially need to patch the kernel (and device tree) on our host, build the image using the cross compiler, and flash it on the Nanos over a USB cable using the flash script - the known procedure.
Hi,
Any updates on this one yet?
I would categorize this one as an OTA issue.
You could try to dump the signed dtb file by using below command.
./tegraflash.py --bl nvtboot_recovery_cpu.bin --chip 0x18 --applet mb1_recovery_prod.bin --cfg flash.xml --sdram_ config P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A02_l4t.cfg --sdram_config P3310_A00_8GB_Samsung_8GB_lpddr4_204Mhz_A0 2_l4t.cfg --misc_config tegra186-mb1-bct-misc-si-l4t.cfg --pinmux_config tegra186-mb1-bct-pinmux-quill-p3310-1000-c0 3.cfg --pmic_config tegra186-mb1-bct-pmic-quill-p3310-1000-c03.cfg --pmc_config tegra186-mb1-bct-pad-quill-p3310-100 0-c03.cfg --prod_config tegra186-mb1-bct-prod-quill-p3310-1000-c03.cfg --scr_config minimal_scr.cfg --scr_cold_boot_ config mobile_scr.cfg --br_cmd_config tegra186-mb1-bct-bootrom-quill-p3310-1000-c03.cfg --dev_params emmc.cfg --cfg flash.xml --bins "mb2_bootloader nvtboot_recovery.bin; mts_preboot preboot_d15_prod_cr.bin; mts_bootpack mce_mts_d 15_prod_cr.bin; bpmp_fw bpmp.bin; bpmp_fw_dtb tegra186-a02-bpmp-quill-p3310-1000-c01-00-te770d-ucm2.dtb; tlk tos.img ; eks eks.img; bootloader_dtb tegra186-quill-p3310-1000-c03-00-base.dtb" --cmd "sign;
The whole steps would be like:
- build the DTB
- replace new DTB files with $OUT/bootloader/tegra186.dtb
- generate signed files with tegraflash.py
- copy the signed DTB to target device.
- replace the kernel-dtb partition (/dev/mmcblk0p26) with dd command.
Hi WayneWWW,
Could you please elaborate on the above procedure?
- When I enter the command you provided (I assume a double quote at the end was missing, so I added it), a tegraflash prompt opens. Is this what should happen?
After that I type âhelpâ and see the only relevant commands as sign and signwrite.
What exactly should I do at this step to dump the signed dtb? And where would I find such a signed dtb?
- Also, in step 5 of your reply, I notice you use the /dev/mmcblk0p26), which is not present on one of the live Jetson Nanos we are using. On running the command
ls -al /dev/disk/by-partlabel, I find that DTB is assigned to /dev/mmcblk0p10. So should I use this instead of /dev/mmcblk0p26 ?
Hi WayneWWW,
Any updates on this one yet?
Hi jetson_user,
Sorry. I didnât notice your issue is on Nano. The command in #3 is for TX2.
I will share the correct commands with you later.
Please use this one. You may need to vary the dtb name if your board is using different dtb.
Linux_for_Tegra/bootloader$ sudo ./tegraflash.py --bl cboot.bin --bct P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg --odmdata 0x94000 --bldtb tegra210-p3448-0000-p3449-0000-a00.dtb --applet nvtboot_recovery.bin --cmd "flash; reboot" --cfg flash.xml --chip 0x21 --bins "EBT cboot.bin; DTB tegra210-p3448-0000-p3449-0000-a00.dtb" --cmd "sign;"
Copy the tegra210-p3448-0000-p3449-0000-a00.dtb.encrypt to your device and use dd command to overwrite the partition âDXBâ
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fpart_config.html
Hi WayneWWW,
I tried the above command but with the dtb for the board, like the following:
sudo ./tegraflash.py --bl cboot.bin --bct P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg --odmdata 0x94000 --bldtb tegra210-p3448-0000-p3449-0000-a00.dtb --applet nvtboot_recovery.bin --cmd "flash; reboot" --cfg flash.xml --chip 0x21 --bins "EBT cboot.bin; DTB tegra210-p3448-0000-p3449-0000-a00.dtb" --cmd "sign;"
And I receive the following error:
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[ 0.0021 ] tegrasign --key None --getmode mode.txt
[ 0.0027 ] Assuming zero filled SBK key
[ 0.0030 ]
[ 0.0031 ] Generating RCM messages
[ 0.0037 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm nvtboot_recovery.bin 0 0
[ 0.0044 ] RCM 0 is saved as rcm_0.rcm
[ 0.0048 ] RCM 1 is saved as rcm_1.rcm
[ 0.0048 ] List of rcm files are saved in rcm_list.xml
[ 0.0048 ]
[ 0.0048 ] Signing RCM messages
[ 0.0054 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0061 ] Assuming zero filled SBK key
[ 0.0115 ]
[ 0.0115 ] Copying signature to RCM mesages
[ 0.0121 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[ 0.0131 ]
[ 0.0132 ] Parsing partition layout
[ 0.0137 ] tegraparser --pt flash.xml
[ 0.0144 ] File flash.xml open failed
[ 0.0144 ]
Error: Return value 19
Command tegraparser --pt flash.xml
I believe this is because there is no flash.xml. Any clue how to debug this?
Are you using a fresh Linux_for_tegra? I think flash your board once should resolve this issue.
Hi WayneWWW,
Yes I was using a fresh Linux_for_tegra, sorry. I am now flashing it, will test the command once flashing is complete.
Also, my partitions list is like this:
total 0
drwxr-xr-x 2 root root 320 mrt 4 10:32 .
drwxr-xr-x 8 root root 160 mrt 4 10:32 ..
lrwxrwxrwx 1 root root 15 mrt 4 10:32 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 16 mrt 4 10:32 BMP -> ../../mmcblk0p13
lrwxrwxrwx 1 root root 15 mrt 4 10:32 BPF -> ../../mmcblk0p6
lrwxrwxrwx 1 root root 15 mrt 4 10:32 BPF-DTB -> ../../mmcblk0p7
lrwxrwxrwx 1 root root 16 mrt 4 10:32 DTB -> ../../mmcblk0p10
lrwxrwxrwx 1 root root 15 mrt 4 10:32 EBT -> ../../mmcblk0p4
lrwxrwxrwx 1 root root 16 mrt 4 10:32 EKS -> ../../mmcblk0p12
lrwxrwxrwx 1 root root 15 mrt 4 10:32 FX -> ../../mmcblk0p8
lrwxrwxrwx 1 root root 16 mrt 4 10:32 LNX -> ../../mmcblk0p11
lrwxrwxrwx 1 root root 15 mrt 4 10:32 RP1 -> ../../mmcblk0p3
lrwxrwxrwx 1 root root 16 mrt 4 10:32 RP4 -> ../../mmcblk0p14
lrwxrwxrwx 1 root root 15 mrt 4 10:32 TBC -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 mrt 4 10:32 TOS -> ../../mmcblk0p9
lrwxrwxrwx 1 root root 15 mrt 4 10:32 WB0 -> ../../mmcblk0p5
I do not see a âDXBâ partition. Which one should I be using?
Please flash the DTB one. Is it a release prior to rel-32.3?
Okay, thanks for the info, will flash the mmcblk0p10 partition then.
Yes, this L4T is 32.2.
I just updated the partition with the encrypted dtb and there were no problems with booting. But the dtb were the same, so I now need to test with changed contents of the device tree and verify if the update is taking effect.
Will keep you posted.
FYI, I think the âDXBâ is just a typoâŠâDTBâ is the device tree binary/blob.
Once a system is booted you can find out what the running device tree is via:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
(a small amount of boot info is edited during boot, but any edits you may have made should show up in âextracted.dtsââŠthe file is plain text)
You could also check the sha1sum of the signed binary on the host PC, and then compare to partition contents:
# On Jetson:
cat /dev/mmcblk0p10 | sha1sum
# On host PC:
sha1sum /whichever/signed/binary/file/went/in/tegra210-p3448-0000-p3449-0000-a00.dtb.encrypt
âdtcâ should be available as package âsudo apt-get install device-tree-compilerâ.
Hi WayneWWW,
Thank you, the solution worked.
Hi linuxdev,
Thanks for the suggestion of checksum. Indeed, it was DTB at partition /dev/mmcblk0p10 for Jetson Nano production module at least.
Also, the corresponding dtb file found out to be was: tegra210-p3448-0002-p3449-0000-b00.dtb
A question: are
dtc -I fs -O dts -o extracted.dts /proc/device-tree
and
dtc -I dtb -O dts -o extracted.dts /boot/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb
the same thing, as their contents seem similar.
I am not sure about how Nano handles this. Someone else will need to give you a final answer, but some history will explain why the question is more complicated than it soundsâŠ
In the past, over many years (going back to Tegra 3 L4T 16.x days at least, perhaps more), up through L4T 28.x, the pre bootloader stages did not need to read the device tree. It wasnât until U-Boot was reached that the device tree was needed. U-Boot is able to read a device tree directly from an ext4 filesystem, and thus the content in â/bootâ contained the actual device tree which was used.
Additionally, secure boot was not used in the older releases. There was no need to sign any content. Once secure boot became a requirement boot content required signing (and if you burn the fuse for this, then only correctly signed boot content will boot).
Enter other complications of secure boot. Now, in L4T R32.x+ for systems with internal eMMC, the content is verified prior to reaching any of the more advanced boot stages. These early boot stages are unable to read an ext4 filesystem type. The signed device tree content was moved into a partition since those early stages can read partitions as binary data, but not on an ext4 filesystem. Some of the content was left over as baggage in â/bootâ, but more than one Jetson variant uses the same flash software, and so your Nano might either use this legacy content or ignore this content in ways which differ between Jetsons.
There are actually two different NanosâŠone is the development kit version which does not have eMMC, and runs on SD card only. I do not know if the SD card version actually signs this and uses a partition of the SD card, or if the â/bootâ content is used without signing. I can only guess, but it would see likely the eMMC version moves this back into a signed binary device tree partition instead of â/bootââŠif secure boot is used, this seems like it would be mandatory.
Anyone else who can comment on whether signing is not needed on any of the Nano variants? Is the â/bootâ dtb file entirely leftover legacy, or does it have some actual purpose?
1 Like