Corrupted NvTbootKernelDTB and flashing with an x86 host

Autonomous Machines Jetson & Embedded Systems Jetson Projects
1

I recently purchased a Jetson Nano 4GB (B01 Board), but I can’t get the Jetson Nano to boot up now. I’m using a Mac and successfully performed the SDCard install of Jetpack 4.6.1 on the Nano. I also completed the system preference screens for the Jetson Nano in the Ubuntu Linux OS before selecting “Shut Down.” Following this initial Jetson shutdown, the boot up failed.

I’ve connected the ttl to USB cable. Using the Ubuntu minicom debug console, I’ve started the Jetson Nano in normal startup mode and received the following console log:
[0000.125] [L4T TegraBoot] (version 00.00.2018.01-l4t-e82258de)
[0000.130] Processing in cold boot mode Bootloader 2
[0000.135] A02 Bootrom Patch rev = 1023
[0000.138] Power-up reason: pmc por
[0000.141] No Battery Present
[0000.144] pmic max77620 reset reason
[0000.147] pmic max77620 NVERC : 0x40
[0000.151] RamCode = 0
[0000.153] Platform has DDR4 type RAM
[0000.156] max77620 disabling SD1 Remote Sense
[0000.161] Setting DDR voltage to 1125mv
[0000.165] Serial Number of Pmic Max77663: 0x320e75
[0000.172] Entering ramdump check
[0000.175] Get RamDumpCarveOut = 0x0
[0000.179] RamDumpCarveOut=0x0, RamDumperFlag=0xe59ff3f8
[0000.184] Last reboot was clean, booting normally!
[0000.188] Sdram initialization is successful
[0000.192] SecureOs Carveout Base=0x00000000ff800000 Size=0x00800000
[0000.199] Lp0 Carveout Base=0x00000000ff780000 Size=0x00001000
[0000.204] BpmpFw Carveout Base=0x00000000ff700000 Size=0x00080000
[0000.210] GSC1 Carveout Base=0x00000000ff600000 Size=0x00100000
[0000.216] GSC2 Carveout Base=0x00000000ff500000 Size=0x00100000
[0000.222] GSC4 Carveout Base=0x00000000ff400000 Size=0x00100000
[0000.228] GSC5 Carveout Base=0x00000000ff300000 Size=0x00100000
[0000.234] GSC3 Carveout Base=0x000000017f300000 Size=0x00d00000
[0000.250] RamDump Carveout Base=0x00000000ff280000 Size=0x00080000
[0000.256] Platform-DebugCarveout: 0
[0000.259] Nck Carveout Base=0x00000000ff080000 Size=0x00200000
[0000.265] Non secure mode, and RB not enabled.
[0000.269] BoardID = 3448, SKU = 0x0
[0000.272] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.276] Nano-SD: checking PT table on QSPI …
[0000.281] Read PT from (2:0)
[0000.296] Using BFS PT to query partitions
[0000.302] Loading Tboot-CPU binary
[0000.330] Verifying TBC in OdmNonSecureSBK mode
[0000.340] Bootloader load address is 0xa0000000, entry address is 0xa0000258
[0000.347] Bootloader downloaded successfully.
[0000.351] Downloaded Tboot-CPU binary to 0xa0000258
[0000.356] MAX77620_GPIO5 configured
[0000.359] CPU power rail is up
[0000.362] CPU clock enabled
[0000.366] Performing RAM repair
[0000.369] Updating A64 Warmreset Address to 0xa00002e9
[0000.374] BoardID = 3448, SKU = 0x0
[0000.377] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.381] Nano-SD: checking PT table on QSPI …
[0000.385] Loading NvTbootBootloaderDTB
[0000.452] Verifying NvTbootBootloaderDTB in OdmNonSecureSBK mode
[0000.523] Bootloader DTB Load Address: 0x83000000
[0000.528] BoardID = 3448, SKU = 0x0
[0000.531] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.535] Nano-SD: checking PT table on QSPI …
[0000.540] Loading NvTbootKernelDTB
[0000.606] Verifying NvTbootKernelDTB in OdmNonSecureSBK mode
[0000.629] NvTbootKernelDTB is corrupted!
[0000.633] Error in NvTbootLoadBinary: 0x14 !
[0000.637] Error is 14

It appears that the NvTbootKernelDTB is corrupted. With a brand new microUSB to USB 2.0 data cable, the ‘lsusb’ command identifies my Nvidia P3450 board listing the device in the following format: Bus Device : ID 0955: Nvidia Corp. I followed the untar instructions and successfully ran the apply_binaries.sh script, but for some reason the Ubuntu host can connect to the Nvidia nano board and see it with the lsusb command, but the probing process fails? In the documentation, there aren’t specific ${BOARD} parameter values for the P3450 board, so I read recent developer responses hoping to find the right command syntax to initiate the flash, which is where I found the following (ubuntu@ubuntu:~/Downloads/Linux_for_Tegra$ sudo ./flash.sh jetson-nano-devkit mmcblk0p1), but to-date I am still unsuccessful with the flash. This is the error code received:

ubuntu@ubuntu:~/Downloads/Linux_for_Tegra$ sudo ./flash.sh jetson-nano-devkit mmcblk0p1
###############################################################################
L4T BSP Information:
R32 , REVISION: 7.1
###############################################################################
Unsupported ioctl: cmd=0xffffffff8004550f
Error: probing the target board failed.
Make sure the target board is connected through
USB port and is in recovery mode.

I’m using a Raspberry Pi 3B v1.2 (quad-core 64-bit Broadcom BCM2837 ARM Cortex-A53 SoC processor running at 1.2 GHz) as the host, but apparently I need an x86 host with Ubuntu 18.04.

Is there a preferred x86 host machine/manufacturer? Is there simple documentation for this specific step (I’ve had to jump between a number of different source documents and posts to troubleshoot up to this point). Lastly, is this the only option now (i.e. to purchase another machine as a host)? As a last resort, I’m posting here because I’m hoping there is a simple fix to this, but if not, I would just like some guidance on the specifications for the host before I invest any more time/money into this project.

Thanks in advance.

2

I’m adding a lot here because there is often confusion on flash procedure and where boot content resides depending on if this is a dev kit by NVIDIA, versus a commercial module sold with a custom carrier board by a third party. More specific answers require knowing if you have a dev kit versus whether or not you have a module plus third party custom carrier board. You’re seeing information for both cases, and it could be a lot more brief if we could limit to whatever carrier board you have. The short answer requires knowing if your SD card slot is on the module itself (without eMMC), or if the SD card slot is on the carrier board (implying your module does not have the SD card slot directly on the module, and that your module has eMMC). Does your model have eMMC with SD card slot on carrier board, or is it SD card slot on the module itself, without eMMC?

The rest of this is for people wondering about where software resides or how it changes flash for eMMC models versus SD card models (and a slight bit on initrd flashing for alternate external media).

A distinction to be aware of is that there are two types of Jetson modules: (A), the dev kit where the SD card slot is on the module itself, or (B), the separately sold commercial modules whereby any SD card slot is on the carrier board, and not on the module.

NVIDIA sells Nano dev kits (and lots of versions in that form factor, e.g., the NX for Xavier or Orin, and the Orin Nano; just “Nano” is a TX1 in small form factor). I have not used the 4GB model, but if there is an SD card slot on the module itself the software is very different than if the SD card slot is on the carrier board.

In every case you will find it is possible there is software on the module itself in QSPI memory. In cases where there is an SD card slot is on the module, then all software for boot, along with the equivalent of a BIOS (Jetsons don’t have an actual BIOS), is in that QSPI memory (the module itself is flashed, only the o/s resides on SD card…you can flash the SD all you want, but it won’t fix boot issues). It is in models which have eMMC that this content is usually in partitions of the eMMC instead of being in QSPI (flash of eMMC normally also flashes the other partitions for boot and equivalent of BIOS).

When flashing on command line the eMMC is referred to as mmcblk0p1; however, for an SD card model which does not have eMMC, this changes slightly and is mmcblk1p1 (which is the SD card, not eMMC). I see your flash referred to mmcblk0p1, which is for an eMMC model (the first partition of the eMMC). If you have eMMC, then the SD card as o/s requires special flash procedures. If you do have a non-eMMC model, then you have to flash the module once as well, separately from the SD card.

Is your SD card slot on the module itself, or is it on the carrier board? If on the module, you have a dev kit needing separate QSPI and SD software install, and which uses the NVIDIA flash software directly.

Is your SD card slot on the carrier board? If so, then you do not have a dev kit. You would instead have a commercial module with a third party carrier board (module made by NVIDIA, carrier board made by someone else). In that case flash is to eMMC, not SD card, unless you take special steps for an initrd flash. The software and instructions normally have to come from the third party carrier board manufacturer.

In some cases a third party carrier board manufacturer exactly follows the electrical layout of the reference carrier board. In that case the manufacturer will probably state to use the NVIDIA flash software. If there is any difference in layout or options to the carrier board, then a new device tree is required. Possibly other drivers would also be required. In this case one the following will occur, as stated by the manufacturer of the carrier board:

  • Use a patch from the manufacturer on the NVIDIA flash software, and then flash with NVIDIA instructions using the patched software.
  • Use the third party manufacturer’s flash software, which would be the NVIDIA content with patches (usually just device tree, but perhaps also drivers).

As for what is getting flashed, it is L4T (“Linux for Tegra”). L4T is just Ubuntu with NVIDIA drivers added to it. JetPack/SDK Manager is just a front end for the actual flash software, and runs on the host PC, not the Jetson. The release version of JetPack and L4T tend to be tied together, so usually if you pick one, then you’ve picked the other. JetPack tends to be started on command line with sdkmanager (which is the smart network layer on top of JetPack), and you can make old versions of L4T available with “sdkmanager --archivedversions” (or on the very latest SDKM “sdkmanager --archived-versions”).

I mentioned earlier that Jetsons do not have an actual BIOS. This means Jetsons cannot self-flash. When in recovery mode, Jetsons are custom USB devices. Such devices are understood by a custom USB driver. If you were to manually install flash content on a host PC, then one part of it is called the “driver package” (this is what JetPack uses underneath it to perform the actual flash). The name “driver package” is appropriate because it is a driver for a custom USB device…the Jetson in recovery mode.

The driver package does not run on platforms other than desktop PC Linux. The command line driver package can actually run on a wide range of Linux host PCs, but JetPack requires a more limited range. JetPack itself can limit the range of host PC versions of Ubuntu based on which L4T release is being flashed. For L4T R32.x, which is flashed via JetPack 4.x, the host PC can be Ubuntu 18.04 or Ubuntu 20.04.

Here’s where you find the releases (not important if you have a third party carrier board with flash content provided by the manufacturer):

All that can be greatly simplified if we know if this is a third party carrier board with SD card slot on carrier board, versus if this is a dev kit without eMMC and with SD on the module itself.

3

The SD card slot is underneath an elevated board with the GPU Heatsink. This elevated board is attached to the primary (larger) Jetson Nano Developer Kit carrier board where the power, monitor, USB, and ethernet ports are positioned. The back of the carrier board has the NVIDIA logo along with the stamped Model: P3450 and a S/N sticker.

This is the Jetson Nano Developer kit layout:

4

Yes, that is an SD card (dev kit) model without eMMC. This means all of the equivalent of BIOS and boot content is in the QSPI memory of the module itself. A subset of that content is the TBoot content you are having issues with. So the problem is that the module must be flashed. The SD card won’t ever be reached if that content isn’t flashed at least once. Most of the R32.x content will work with a single flash of the QSPI, so once that is done and if there is another SD card release, then you probably wouldn’t need to flash the QSPI again.

You will need to flash using JetPack. You can go to the link above for the latest R32.x release, and then find the JetPack release associated with that:
https://developer.nvidia.com/linux-tegra

You will need an Ubuntu 18.04 of 20.04 host PC to perform that flash (the lack of a real BIOS is why Jetsons cannot self-flash). You’d use the correct USB port to the host PC, put the Jetson in recovery mode (there are two pins next to each other under the module where one is “recovery” and the one next to it is a ground pin, short those, and then either reset power or power on, then remove the short on the pins…this puts the Jetson in recovery mode). From there check or uncheck items in the list of steps JetPack will perform, e.g., you could uncheck installing some content to host PC, or uncheck installing certain optional packages to the Jetson.

After this the SD card should work.

5

Thank you for the reply. My original question was about the nature/specifications of the host. I use a Mac and the previous errors came from using Ubuntu 18.04 on a Raspberry Pi (Raspberry Pi 3B v1.2 quad-core 64-bit Broadcom BCM2837 ARM Cortex-A53 SoC processor running at 1.2 GHz) as the host. What kind of host PC is required because I’ve been told neither a Mac or ARM processor machine can be used to perform the flash.

6

A Mac that has the amd64/x86_64 CPU, but running Ubuntu 18.04, should work without issue (I can’t guarantee it though since I don’t have a Mac). The RPi is the wrong architecture for the driver package, and so that is guaranteed to fail. Some of the Macs of the past used a Motorola CPU architecture, and those too would fail, so it is more about the CPU architecture than it is about brand.

7

Using my Mac, I installed VMWare Fusion then used the ubuntu-18.04.6-desktop-amd64.iso image for the OS. From the NVIDIA documentation site, I downloaded the Jetson-210_Linux_R32.7.4_aarch64.tbz2 tar file. Ensuring that the board was in recovery mode by jumping pins 9 and 10 on the J50 Button Header on plug in and removing the jumper before initiating communication with the board, I’m able to see the Jetson Nano using ‘lsusb’ without issue. After changing directories into the Linux_for_Tegra directory, I ran the following and changed the final parameter from mmcblk0p1 to mmcblk1p1 per your recommendation:

sudo ./flash.sh jetson-nano-devkit mmcblk1p1

The result is better than before since at least now the target board and the Ubuntu host are exchanging data, however, there still appears to be read errors related to an ‘nv_boot_control.conf’ not being a directory. Below is the Jetson response in full. Please advise.

###############################################################################

L4T BSP Information:

R32 , REVISION: 7.1

###############################################################################

Target Board Information:

Name: jetson-nano-devkit, Board Family: t210ref, SoC: Tegra 210,

OpMode: production, Boot Authentication: ,

Disk encryption: disabled ,

###############################################################################
./tegraflash.py --chip 0x21 --applet “/home/orionrk/Downloads/Linux_for_Tegra/bootloader/nvtboot_recovery.bin” --skipuid --cmd “dump eeprom boardinfo cvm.bin”
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.0019 ] Generating RCM messages
[ 0.0034 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/orionrk/Downloads/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
[ 0.0043 ] RCM 0 is saved as rcm_0.rcm
[ 0.0060 ] RCM 1 is saved as rcm_1.rcm
[ 0.0069 ] List of rcm files are saved in rcm_list.xml
[ 0.0181 ]
[ 0.0182 ] Signing RCM messages
[ 0.0219 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0228 ] Assuming zero filled SBK key
[ 0.0427 ]
[ 0.0428 ] Copying signature to RCM mesages
[ 0.0454 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[ 0.0541 ]
[ 0.0542 ] Boot Rom communication
[ 0.0565 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[ 0.0627 ] RCM version 0X210001
[ 0.1119 ] Boot Rom communication completed
[ 1.1346 ]
[ 1.1347 ] dump EEPROM info
[ 1.1403 ] tegrarcm --oem platformdetails eeprom /home/orionrk/Downloads/Linux_for_Tegra/bootloader/cvm.bin
[ 1.1414 ] Applet version 00.01.0000
[ 1.1760 ] Saved platform info in /home/orionrk/Downloads/Linux_for_Tegra/bootloader/cvm.bin
[ 1.2905 ]
[ 1.2936 ] tegrarcm --reboot recovery
[ 1.2946 ] Applet version 00.01.0000
[ 1.3512 ]
Board ID(3448) version(402)
copying bctfile(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/BCT/P3448_A00_lpddr4_204Mhz_P987.cfg)… done.
copying bootloader(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/cboot.bin)… done.
copying initrd(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/l4t_initrd.img)… done.
Making Boot image… done.
Existing sosfile(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/nvtboot_recovery.bin) reused.
copying tegraboot(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/nvtboot.bin)… done.
copying cpu_bootloader(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/cboot.bin)… done.
copying bpffile(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/sc7entry-firmware.bin)… done.
copying wb0boot(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/t210ref/warmboot.bin)… done.
Existing tosfile(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/tos-mon-only.img) reused.
Existing eksfile(/home/orionrk/Downloads/Linux_for_Tegra/bootloader/eks.img) reused.
copying dtbfile(/home/orionrk/Downloads/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb)… done.
Copying nv_boot_control.conf to rootfs
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
sed: can’t read /home/orionrk/Downloads/Linux_for_Tegra/rootfs/etc/nv_boot_control.conf: Not a directory
generating system.img for booting…
Making system.img…
/tmp/tmp.IwMRTBdkrJ/boot/extlinux/extlinux.conf is not found, exiting…

8

If there is a way to download the JetPack/SDK Manager instead, then you should do this. It is this GUI and network front end which properly unpacks and picks the right packages.

Note that no VM is guaranteed to work. There is setup for USB which very often fails if not done properly, and every VM has its own instructions.

Be very certain that the filesystem this software runs on is ext4. It is possible that your install on the VM produced a partition or other filesystem which is ext4, but if it is not, then flash will only “appear” to succeed, but the installation will be terribly broken and will not work.

If you are going to manually install and work on command line, then there are more steps than what you’ve completed. I will recommend that you delete the produced “Linux_for_Tegra/” subdirectory which unpacked, and start over like this:

  1. Unpack as a regular user (I think this part so far is correct; do not use sudo for this):
    tar xvfj Jetson-210_Linux_R32.7.4_aarch64.tbz2
  2. cd to Linux_for_Tegra/rootfs/. Unpack the sample root filesystem using sudo.
  3. cd back to Linux_for_Tegra/. Install the NVIDIA drivers to the rootfs:
    sudo ./apply_binaries.sh

After this, if you have sufficient disk space, then you can run the command line flash you previously ran. You were running for an SD card model since the target mmcblk1p1 is incorrect for an eMMC model (but I think you have a model with SD card and no eMMC so this is likely correct).

9

Thank you. I will give this a try in the next day and reply back. Just to clarify, this flash should not only fix the boot issue, but it will also write the Ubuntu OS to the SDCard? If so, I should be working with a deleted/empty/formatted SDCard, correct? Or will this just fix the boot issues and I should use the SDCard image from the NVIDIA “Getting Started with Jeston” download?

Also, it’s unclear to me this distinction between the driver install from the tar file and the use of Jetpack 4.x. This driver tar file install also includes the Jetpack download, correct?

It appears the SDK Manager GUI may be a nice solution here as well (per your comment). Is this the correct documentation?
https://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html

10

If you have a Jetson where the SD card slot is on the carrier board, and not on the module, then it will have eMMC memory. This will flash to eMMC, including boot content and o/s. If you have an SD card on the module itself, then setting up the SD card is a separate step, and the flash only writes to the QSPI memory (typically someone with SD card models…meaning no eMMC…will write a pre-created image to the SD card separately). Your original SD card image should work without having to flash it if and only if the boot content was flashed.

The driver package is a custom USB driver. This is the flash software. On an eMMC model, this will flash both boot content and o/s. On SD card models you will typically flash the QSPI only with this. A Jetson in recovery mode is a custom USB device understood by the custom driver…the driver package. The sample rootfs and the apply_binaries.sh steps create the content used for the o/s itself, but on the SD card model, you already have this (this is used for eMMC models); this custom driver can flash both QSPI and o/s, but you don’t need to flash o/s onto the SD card since it already has the o/s loaded onto it; the QSPI remains in order for boot to reach the SD card.

Years ago there was only command line flash. JetPack was added as a GUI front end to the flash software. By itself JetPack does add a few features. Many of the optional packages, including CUDA, do not exist in the base flash. Those are added after flash completes on a fully running Jetson via the ssh network connection. JetPack has available versions of those packages which work on that version of the Jetson. You cannot use the outside world’s packages because they are not designed for the GPU which is integrated directly to the memory controller. After a Jetson flashes it will automatically reboot. This is when you have to use the first boot account setup, and this is when JetPack will continue to add some optional packages. JetPack can add those optional packages to SD card models as well as eMMC models.

SDK Manager is a more recent invention. SDKM is used by JetPack. This is a “smart” network layer. This is used by JetPack for downloading the correct software for your particular model (but it doesn’t know about third party carrier boards, it only knows about units entirely created by NVIDIA; third party devices will either provide patches to this, or will create their own flash environment using what JetPack uses). Original JetPack still required the end user to download individual content.

SDKM/JetPack will more or less pick the right packages for you automatically and download those as well. That URL you linked is correct, but I don’t know if it is limited to a particular release. Incidentally, the o/s installed is Ubuntu, but when you add the NVIDIA drivers, it becomes known as L4T (“Linux for Tegra”). The L4T release is normally tied to a particular JetPack release, so if you’ve picked one, then you’ve also picked the other’s release version. The documentation you are interested in is the L4T R32.7.4 (because it is the most recent release for your model), and it can be found here:

You can sometimes get a more recent JetPack, but start it like this to see older releases:
sdkmanager --archivedversions

Always use documentation, such as the document you provided the URL for earlier, from the exact release of L4T you are flashing. However, the instructions for most of R32.x will be similar, and most of R32.7.x will likely be an exact match on instructions (except perhaps for a list of bugs fixed or maybe documentation updates).

Do understand though that command line works on a wider range of Linux host PCs than does JetPack. JetPack will limit you to a smaller subset of Ubuntu host PCs. The L4T R32.x releases should work on Ubuntu 18.04 of 16.04 host PCs. Once you have this all of the downloads and software setup would be simplified by JetPack/SDKM rather than needing to manually download and set up the different flash software steps.

1 Like
11

An update from my side. So, going into Linux_for_Tegra/rootfs/ directory landed me into a readme file that in the vi editor instructed me to insert the file directory there (but what text exactly needs to be inserted before running the apply_binaries.sh script?).

Trying a new approach, I opted for installing SDK Manager 2.0.0.11405 x86_64 on the Ubuntu 16.04 host. All of the downloads were successful, but the flash did not work. Interestingly, SDK Manager does not correctly recognize the board. It defaulted to the P3448 module and P3449 carrier board, but my carrier board is P3450 (not sure if this is an issue). There is no P3450 option to select in this version of SDK Manager.

The USB board appears to be recognized in Recovery Mode because SDK Manager prompts that the USB device APX has been “added” or “removed” when either connecting or disconnecting the USB cable. Of note, I have a 64GB SD Card complete with the Jetson Nano Developer Kit SD Card Image already inserted into the Jetson that I successfully flashed using Etcher. Below is the full flash error. Please advise.

18:14:34 INFO: Flash Jetson Nano - flash: [ 3.4001 ] tegrarcm --oem platformdetails eeprom /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/bbd.bin
18:14:34 INFO: Flash Jetson Nano - flash: [ 3.4013 ] Cannot open usb device.Check if device is in recovery
18:14:34 INFO: Flash Jetson Nano - flash: [ 3.4042 ]
18:14:34 ERROR: Flash Jetson Nano - flash: Error: Return value 8
18:14:34 INFO: Flash Jetson Nano - flash: Command tegrarcm --oem platformdetails eeprom /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/bbd.bin
18:14:34 ERROR: Flash Jetson Nano - flash: — Error: Reading board information failed.
18:14:34 ERROR: Flash Jetson Nano - flash: [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP.orionrk.sh; [error]: — Error: Reading board information failed.
18:14:34 INFO: Flash Jetson Nano - flash: [ Component Install Finished with Error ]
18:14:34 INFO: Flash Jetson Nano - flash: [host] [ 12.82 MB used. Disk Avail: 46.68 GB ]
18:14:34 INFO: Flash Jetson Nano - flash: [ NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP Install took 4s ]
18:14:34 ERROR: Flash Jetson Nano - flash: command terminated with error
18:14:34 SUMMARY: Flash Jetson Nano - flash: First Error: Installation failed.
18:31:19 DEBUG: Flash Jetson Nano - flash: using adapter to install NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP@JETSON_NANO_TARGETS to /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS
18:31:19 INFO: Flash Jetson Nano - flash: exec_command: /tmp/tmp_NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP.orionrk.sh
18:31:19 INFO: Flash Jetson Nano - flash: sudo ./nvsdkmanager_flash.sh --nv-auto-config --username orioncrk
18:31:19 INFO: Flash Jetson Nano - flash: [OEMPreconfig] SDKM_INSTALL_ERROR Password for L4T new user orioncrk:
18:31:19 INFO: Flash Jetson Nano - flash: *** Checking ONLINE mode … OK.
18:31:19 INFO: Flash Jetson Nano - flash: *** Checking target board connection … 1 connections found.
18:31:19 INFO: Flash Jetson Nano - flash: *** Reading ECID … FUSELEVEL=fuselevel_production hwchipid=0x21 bootauth=
18:31:19 INFO: Flash Jetson Nano - flash: *** Reading EEPROM … “/home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/tegraflash.py” --chip 0x21 --applet “/home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/nvtboot_recovery.bin” --skipuid --cmd “dump eeprom boardinfo cvm.bin; dump eeprom baseinfo bbd.bin”
18:31:19 INFO: Flash Jetson Nano - flash: [ 0.0070 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
18:31:19 INFO: Flash Jetson Nano - flash: [ 0.0156 ] Assuming zero filled SBK key
18:31:19 INFO: Flash Jetson Nano - flash: [ 0.0287 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
18:31:20 INFO: Flash Jetson Nano - flash: [ 0.0361 ] RCM version 0X210001
18:31:21 INFO: Flash Jetson Nano - flash: [ 1.1074 ] Applet version 00.01.0000
18:31:21 INFO: Flash Jetson Nano - flash: [ 1.1430 ] Saved platform info in /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/cvm.bin
18:31:21 INFO: Flash Jetson Nano - flash: [ 1.2560 ] Applet version 00.01.0000
18:31:23 INFO: Flash Jetson Nano - flash: [ 3.3118 ] RCM 0 is saved as rcm_0.rcm
18:31:23 INFO: Flash Jetson Nano - flash: [ 3.3166 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
18:31:23 INFO: Flash Jetson Nano - flash: [ 3.3263 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
18:31:23 INFO: Flash Jetson Nano - flash: [ 3.3305 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
18:31:23 INFO: Flash Jetson Nano - flash: Command tegrarcm --oem platformdetails eeprom /home/orionrk/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/bootloader/bbd.bin
18:31:23 ERROR: Flash Jetson Nano - flash: command terminated with error

12

Normally sdkmanager would have installed rootfs content into “Linux_for_Tegra/rootfs/”. If you do not use JetPack/SDKM once to install this, then you need to:

  • Unpack the driver package as a regular user.
  • cd into Linux_for_Tegra/rootfs/
  • Unpack the “sample root filesystem” there using sudo.
  • cd back to Linux_for_Tegra/.
  • Run sudo ./apply_binaries.sh.

Often a VM causes failure to find a Jetson. That’s due to USB setup at the VM side, which Jetson software can’t help with. When a detected Jetson is found, but it thinks it is a different module, then it is usually due to the module and/or carrier board being from a third party (only NVIDIA makes the module, but they sell a separate module with eMMC that differs from the dev kit SD card model).

Also, note that the SD card image needs to be from the same release of software which is flashing the Jetson. A flash would work, but the boot itself might fail due to mismatched boot environment and the final Linux o/s. The failure at the point of “Making system.img...” says it is the rootfs content which is incomplete. Did you run the “sudo ./apply_binaries.sh” (not needed if SDKM installed this)?

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.