Hi,
Please find an issue I posted earlier, and its resolution here: How to update dtb without flashing on Jetson Nano production module - #10 by jetson_user.
I would like to know what would the procedure be for TX2, as we intend to update on field TX2s (as we did for the Nanos), and there is no possibility of calling them back.
I ran: ls -al /dev/disk/by-partlabel on one of the TX2s and I get the following output:
total 0
drwxr-xr-x 2 root root 380 jul 3 14:42 .
drwxr-xr-x 7 root root 140 jul 3 14:42 …
lrwxrwxrwx 1 root root 15 jul 3 14:42 APP → …/…/mmcblk0p1
lrwxrwxrwx 1 root root 16 jul 3 14:42 BMP → …/…/mmcblk0p12
lrwxrwxrwx 1 root root 15 jul 3 14:42 bootloader-dtb → …/…/mmcblk0p4
lrwxrwxrwx 1 root root 15 jul 3 14:42 bpmp-fw → …/…/mmcblk0p7
lrwxrwxrwx 1 root root 15 jul 3 14:42 bpmp-fw-dtb → …/…/mmcblk0p8
lrwxrwxrwx 1 root root 16 jul 3 14:42 CAC → …/…/mmcblk0p16
lrwxrwxrwx 1 root root 15 jul 3 14:42 cpu-bootloader → …/…/mmcblk0p3
lrwxrwxrwx 1 root root 15 jul 3 14:42 eks → …/…/mmcblk0p6
lrwxrwxrwx 1 root root 16 jul 3 14:42 FBNAME → …/…/mmcblk0p11
lrwxrwxrwx 1 root root 16 jul 3 14:42 kernel → …/…/mmcblk0p14
lrwxrwxrwx 1 root root 16 jul 3 14:42 kernel-dtb → …/…/mmcblk0p15
lrwxrwxrwx 1 root root 15 jul 3 14:42 mts-bootpack → …/…/mmcblk0p2
lrwxrwxrwx 1 root root 16 jul 3 14:42 sc7 → …/…/mmcblk0p10
lrwxrwxrwx 1 root root 15 jul 3 14:42 sce-fw → …/…/mmcblk0p9
lrwxrwxrwx 1 root root 15 jul 3 14:42 secure-os → …/…/mmcblk0p5
lrwxrwxrwx 1 root root 16 jul 3 14:42 SOS → …/…/mmcblk0p13
lrwxrwxrwx 1 root root 16 jul 3 14:42 UDA → …/…/mmcblk0p17
I need the equivalent of 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;", which was done for Nano, i.e., assuming TX2 also uses encrypted dtb partition.
hello jetson_user,
you don’t need those tegraflash commands to generate signed and encrypted binaries.
please enable the flash scripts, adding --no-flash options into the commands line.
for example,
$ sudo ./flash.sh --no-flash -k kernel-dtb jetson-tx2 mmcblk0p1
please refer to below, it will calling all necessary python scripts to complete the process.
*** Signing tegra186-quill-p3310-1000-c03-00-base.dtb ***
./tegraflash.py --chip 0x18 --cmd "sign tegra186-quill-p3310-1000-c03-00-base.dtb" --skipuid
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.0070 ] Generating signature
[ 0.0262 ] tegrasign_v2 --key None --getmode mode.txt
[ 0.0273 ] Assuming zero filled SBK key
[ 0.0317 ]
[ 0.0318 ] sign_type : 825439088
[ 0.0319 ] header_magic: d00dfeed
[ 0.0341 ] tegrahost_v2 --chip 0x18 --align 1_tegra186-quill-p3310-1000-c03-00-base.dtb
[ 0.0370 ]
[ 0.0384 ] tegrahost_v2 --appendsigheader 1_tegra186-quill-p3310-1000-c03-00-base.dtb zerosbk
[ 0.0417 ]
[ 0.0436 ] tegrasign_v2 --key None --list 1_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb_list.xml --pubkeyhash pub_key.key
[ 0.0449 ] Assuming zero filled SBK key
[ 0.0613 ]
[ 0.0642 ] tegrahost_v2 --updatesigheader 1_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt 1_tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.hash zerosbk
after that,
you’ll also found it generate signed and encrypted binaries to your local host machine.
[ 0.0667 ] Signed file: $OUT/Linux_for_Tegra/bootloader/tegra186-quill-p3310-1000-c03-00-base_sigheader.dtb.encrypt
you may copy this binary to your remote target, using dd commands to update the partition without flashing.
thanks
1 Like
Hi JerryChang,
Which partition do we use for the TX2? Please find in the question the output of ls -al /dev/disk/by-partlabel.
hello jetson_user,
had you check post #3, what’s the remaining question here?
Hi JerryChang,
I meant the partition to which the signed dtb is to be written using the dd command.
Someone else will need to answer the question of which partition, but wanted to add something for safety: Also be certain that your signed binary actually fits in the space of the partition. If enough is added to the dtb file, then it is possible the partition itself will be too small.
Hi linuxdev,
Thank you for the response. Indeed, we should take the size into account, thanks for the tip. We just found out that the partition to which the dtb is to be written to is /dev/mmcblk0p30. This can be found out by using the command: ls -al /dev/disk/by-partlabel, and looking for the label kernel-dtb. This was tested for Jetpack version 4.4.
hello jetson_user,
you should check the kernel-dtb partition with $ ls -al /dev/disk/by-partlabel on your target for confirmation.
it should be a signed and encrypted binary write into the partition.
BTW,
there’s cboot option to select kernel image and device tree blob via /boot/extlinux/extlinux.conf.
it’s by default having LINUX entry for loading kernel image; you may specify FDT entry for loading device tree blob.
those binaries loading from extlinux.conf configuration file were NOT signed and encrypted.
thanks
Hi JerryChang,
Thank you for the information. Yes, I already did that, as can be seen from my previous post. For our case (Jetpack 4.4), the partition was /dev/mmcblk0p30.