I have a Jetson Nano B01 AI development kit that isn’t booting correctly from an SD card image. I have followed the steps below as instructed to by the Jetson nano getting started page and am a Windows 10 user.
Download the jetson-nano-jp451-sd-card-image from the Nvidia website
Prepare a 64GB Sandisk Ultra micro-SD card by clearing and formatting to exFAT
Download Balena Etcher
Select the downloaded image and the target as the micro-SD card
Let Etcher flash and validate the flash and then eject the card and insert it into the nano
Initially I connected my monitor via HDMI and plugged in a mouse and keyboard before the first boot and tried to power it through the micro-USB with the jumper removed. This resulted in no output to the monitor via HDMI but the green power light did come on
After trawling some forums I suspected I had an unstable or insufficient power supply, so I purchased a 5V, 4A power supply for the barrel jack connector and tried the same again with the jumper in place this time. Again no output on the HDMI but still a green light
I have tried the same process on my TV and using different HDMI cables on different monitors and TVs, all with no luck.
I have tried several different micro-SD cards of 32GB and 64GB capacity and also tried reverting back one version of the image to see if that worked, but it did not.
I have tried to enter the setup via headless mode. To do this I plugged in the micro-USB cable (one capable of transmitting data) and then powered on the nano via the barrel jack. I opened device manager to try and detect the COM port so I could connect using PuTTy, but no COM ports were shown (tried showing hidden devices in device manager) so I couldn’t progress further down that route (are there any specific drivers I would need for this?).
I then got hold of a cable to allow me to access the board’s UART pins via PuTTy and a serial connection to monitor the boot process. The log of which I have pasted below.
From my search of the forums here, it seems like the log is showing an issue with how the SD card has been formatted and a lot of the solutions point to using SDK manager…
Can anyone see a glaring issue with why the formatting of the SD card is going wrong and offer a solution to this that I can carry out using Windows 10? I don’t have access to a Linux machine and from what I have read, SDK manager is not supported on virtual machines.
Thanks for any help!
[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.300] PT: Partition TBC NOT found !
[0000.304] Warning: Find Partition via PT Failed
[0000.308] BoardID = 3448, SKU = 0x0
[0000.311] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.315] Nano-SD: checking PT table on QSPI …
[0000.320] PT: Partition TBC NOT found !
[0000.323] Warning: Find Partition via PT Failed
[0000.327] Error is 1`
I downloaded the image from the ‘Getting Started with Jetson Nano Developer Kit’ page and then the sub-page ’ Write Image to the microSD Card’.
I have just opened the download from the page you posted and the folder title of the download is the same as the images I have already downloaded and tried. Just to confirm the title of the download should be ‘jetson-nano-jp451-sd-card-image.zip’ and that this would be the correct image for my B01 kit?
I have downloaded the image from the download centre and tried flashing it to two separate 64GB Sandisk Ultra micro-SD cards, one formatted as exFAT and the other as ext4. Both produced the same boot log below and no output over HDMI.
[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: 0x1409a2
[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.300] PT: Partition TBC NOT found !
[0000.304] Warning: Find Partition via PT Failed
[0000.308] BoardID = 3448, SKU = 0x0
[0000.311] QSPI-ONLY: SkipQspiOnlyFlag = 0
[0000.315] Nano-SD: checking PT table on QSPI …
[0000.320] PT: Partition TBC NOT found !
[0000.323] Warning: Find Partition via PT Failed
[0000.327] Error is 1
I checked this error again.
If this error is on QSPI, then replacing sdcard is not able to resolve this issue. The only way that can work on your side is finding a ubuntu host and try the sdkmanager.
Sdkmanager is able to reflash the QSPI but sdcard image cannot.
OK so I have tried quite a few things to get past this and nothing has worked.
I have got access to a Linux machine running Ubuntu and downloaded SDK manager.
I Installed a freshly formatted 64Gb micro-SD, both exFAT and ext4 tried
Discovered the device in SDK manager and tried installing the latest version of Jetpack (I have also rolled back several versions of Jetpack on SDK manager, all not working for me)
accepted the agreements and allowed SDK to download the required files and install them.
On some versions of the Jetpack the host material errored and didn’t install, but I found Jetpack 4.4 installed the host materials correctly
On the target device side of things, regardless of whether the host materials installed or not, the process always got stuck on flashing the jetson nano image at 99% completion. Then a message would come up saying it was taking longer than usual and did I want to continue. I have tried letting it continue several times and it never seems to complete. I don’t seem to get an error, it just hangs on 99%. I have tried using different USB cables which I know to be working previously.
I have most recently tried downloading the most recent Jetson Nano L4T Driver Package from the Nvidia website and then with the Nano in recovery mode I have entered: cd Linux_for_Tegra sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
in the terminal where I have unpacked the contents of the driver package.
This produced the below output. is this any help in figuring out why SDK manager has also been unsuccessful at flashing the nano?
###############################################################################
./tegraflash.py --chip 0x21 --applet “/home/Downloads/Tegra210_Linux_R32.4.2_aarch64/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.0016 ] Generating RCM messages
[ 0.0029 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/Downloads/Tegra210_Linux_R32.4.2_aarch64/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
[ 0.0040 ] RCM 0 is saved as rcm_0.rcm
[ 0.0047 ] RCM 1 is saved as rcm_1.rcm
[ 0.0047 ] List of rcm files are saved in rcm_list.xml
[ 0.0047 ]
[ 0.0048 ] Signing RCM messages
[ 0.0058 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0069 ] Assuming zero filled SBK key
[ 0.0154 ]
[ 0.0155 ] Copying signature to RCM mesages
[ 0.0164 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[ 0.0176 ]
[ 0.0176 ] Boot Rom communication
[ 0.0185 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[ 0.0193 ] RCM version 0X210001
[ 0.0705 ] Boot Rom communication failed
[ 0.0744 ]
Error: Return value 3
Command tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
I’m fairly new to using Linux so could you please break down those steps a little further?
When you say use jetpack 4.5.1, is that downloading the jetson-nano-jp451-sd-card-image.zip?
Assuming 1. is correct, do I then follow the same steps as above i.e:
go into the same directory in the terminal where I have unpacked the zip and use the command cd Linux_for_Tegra sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
or is there a different step here?
So here I should connect to the GND, TX and RX pins on the Nano and monitor it on a program like PuTTy while it tries to execute point 2.?
Please check the quick start guide from our download center.
Sdkm installs a driver package “Linux _for_Tegra” on your host and flash.sh is over there.
I followed the quick start guide and managed to execute the flash.sh command (the command I used was: sudo ./flash.sh jetson-nano-devkit mmcblk0p1). However,
the ‘full log from flash.sh’ still looks the same as the logs posted before (included below for completeness).
###############################################################################
./tegraflash.py --chip 0x21 --applet “/home/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.0013 ] Generating RCM messages
[ 0.0023 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm /home/Linux_for_Tegra/bootloader/nvtboot_recovery.bin 0 0
[ 0.0032 ] RCM 0 is saved as rcm_0.rcm
[ 0.0038 ] RCM 1 is saved as rcm_1.rcm
[ 0.0038 ] List of rcm files are saved in rcm_list.xml
[ 0.0038 ]
[ 0.0039 ] Signing RCM messages
[ 0.0049 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0058 ] Assuming zero filled SBK key
[ 0.0134 ]
[ 0.0135 ] Copying signature to RCM mesages
[ 0.0148 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[ 0.0164 ]
[ 0.0164 ] Boot Rom communication
[ 0.0175 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[ 0.0189 ] RCM version 0X210001
[ 0.0659 ] Boot Rom communication failed
[ 0.1041 ]
Error: Return value 3
Command tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
Reading board information failed.
Could you also try some old release like rel-32.4.4? If the error is still “read board info failed”, I would give you another method but would be more complicated.
Have tried rel 32.4.4 and the flash.sh process just hangs on the line ‘RCM version 0X210001’, no error but does not progress. This seems like the same thing that was happening through SDK manager when it would hang on 99% flash complete.