Thanks for your reply. The command which failed did not generate a boot.img or its signed version. And within a working Nano, I ran this command:
ls -al /dev/disk/by-partlabel, which gives the following output:
drwxr-xr-x 2 root root 320 nov 14 02:14 .
drwxr-xr-x 8 root root 160 nov 14 02:14 ..
lrwxrwxrwx 1 root root 15 nov 14 02:14 APP -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 16 nov 14 02:14 BMP -> ../../mmcblk0p13
lrwxrwxrwx 1 root root 15 nov 14 02:14 BPF -> ../../mmcblk0p6
lrwxrwxrwx 1 root root 15 nov 14 02:14 BPF-DTB -> ../../mmcblk0p7
lrwxrwxrwx 1 root root 16 nov 14 02:14 DTB -> ../../mmcblk0p10
lrwxrwxrwx 1 root root 15 nov 14 02:14 EBT -> ../../mmcblk0p4
lrwxrwxrwx 1 root root 16 nov 14 02:14 EKS -> ../../mmcblk0p12
lrwxrwxrwx 1 root root 15 nov 14 02:14 FX -> ../../mmcblk0p8
lrwxrwxrwx 1 root root 16 nov 14 02:14 LNX -> ../../mmcblk0p11
lrwxrwxrwx 1 root root 15 nov 14 02:14 RP1 -> ../../mmcblk0p3
lrwxrwxrwx 1 root root 16 nov 14 02:14 RP4 -> ../../mmcblk0p14
lrwxrwxrwx 1 root root 15 nov 14 02:14 TBC -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 nov 14 02:14 TOS -> ../../mmcblk0p9
lrwxrwxrwx 1 root root 15 nov 14 02:14 WB0 -> ../../mmcblk0p5
So I think
LNX can be safely assumed to be
Interestingly when I ran the other command to generate the dtb, I get the
boot.img.encrypted file inside
<top>/Linux_for_Tegra/bootloader/signed. This is the command I ran:
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;
I ran this command to get the dtb signed and encrypted. We had an issue that some Nanos do not boot on our custom carrier boards, for which the solution was to disable UART internally, full discussion here: Jetson Nano production module does not boot on custom carrier board, but does so on auvidea's. This required change in dtb and bootloader. Now with the solution, we can flash a non-booting Nano and get it to booting state again always. But we need to put these changes into the Nanos on field, which are running on our custom carrier board, so that in future it doesn’t happen that the Nanos suddenly stop booting (main cause being some Nanos being more susceptible to noise on uart-debug rx - pin 238). Since these Nanos are on-field, we cannot flash them, so we need to update them by logging in via ssh and updating the DTB and LNX partitions. Now we generate the dtb.encrypt using the above command, based on our discussion here: How to update dtb without flashing on Jetson Nano production module. And this command also generates
Since Nanos always boot on auvidea carrier boards, I use them for flashing. I tried this: I flashed our old
<top> directory (without the fix for UART noise) on one of the noise-susceptible Nanos, and then put this Nano on our custom carrier board as a test. Naturally this did not boot, as our custom carrier board has noise on pin 238 and this Nano is susceptible to that noise. Now I put this Nano back on the auvidea carrier board and updated partition
boot.img.encrypt, and the
DTB partition with
tegra210-p3448-0000-p3449-0000-a00.dtb.encrypt from the
<top> directory with the fix. This was the fix for the UART noise, from what I understood. But even with this update, the Nano did not boot on our custom carrier board. So this tells me that either the bootloader changes have not gone under boot.img.encrypt, or that updating LNX partition with boot.img.encrypt has not effect.
Can someone verify if boot.img.encrypt file so generated is the one to use? It did not work in our case.