Trouble Flashing Jetson Nano Dev Boards

Hi,

I’m having an issue with trying to reflash 2 of our Jetson Nano Devkit units (4GB, B01 revision). When attempting to flash a fresh L4T image to our system using Nvidia SDK Manager, I get an error when parsing the baseboard EEPROM which causes the flash procedure to fail:

Parsing baseboard EEPROM:
--- Parsing board ID (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board version (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board SKU (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board REV (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
Parsing module EEPROM:
--- Parsing board ID (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board version (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board SKU (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
--- Parsing board REV (ERROR: calculated CRC8 0x81 != stored CRC8 0xdf) succeeded.
Error: Target board not found.
Info: [ Component Install Finished with Error ]
Info: [host] [ 88.00 KB used. Disk Avail: 57.51 GB ]
Info: [ NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP Install took 12s ]
Error: [error]: : [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FLASH_NANO_WITH_OS_IMAGE_COMP.sh; [error]: 

I’ve tried both Jetpack 4.6 and Jetpack 4.5. I’ve also tried using flash.sh script and had that fail as well with the message “Parsing board information failed.”.

I’ve attached some log files below to hopefully shed some light on the issue:

flash_script_failure.txt (2.2 KB)
SDKM_logs_JetPack_4.5.1_(rev.1)Linux_for_Jetson_Nano[developer_kit_version]_2021-09-07_10-00-25.zip|attachment (72.1 KB)
SDKM_logs_JetPack_4.6_(rev.1)Linux_for_Jetson_Nano[developer_kit_version]_2021-09-07_08-43-16.zip|attachment (73.3 KB)

Has anyone seen this behavior when attempting to flash before? I would appreciate any insight.

Thanks.

Use your error log to search this forum and you will find out similar posts.

I am not sure why so many users hit this problem recently. Is your board still able to boot into kernel? If so, use i2c tool to modify the module eeprom crc value to 0x81.

Are you also installing some camera driver/ tool and cause this problem?

Jetson Xavier case:

Jetson Nano case:

Hi @eblinux14,
If you have another jetson nano dev board try to read the EEPROM data in the working jetson board copy the same into the one troubling you.

Unfortunately both units I have exhibit this issue. I am unable to boot either one at all, which means I can’t fix the eeprom data on the board itself. Is there a way to flash the EEPROM from the host PC? I did notice that the checksum of the saved off EEPROM file when flashing is incorrect which might be causing complications.

I did try the suggestion in one of the linked threads of using the SKIP_EEPROM_CHECK parameter, but I find the script either errors out when attempting to flash the EBT partition, or freezes completely at:

[   2.8193 ] Boot Rom communication
[   2.8215 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
[   2.8245 ] BR_CID: 0x00000020000000090000000100000002

The applicable full logs are below:

flash_ebt_hangs.txt (13.7 KB)
flash_ebt_send_error1.txt (10.6 KB)

Can you also try the method that provide the board id and sku id to the flash.sh? As mentioned in the jetson nano post link.

I just gave that a try as well and still no luck, always seems to hang at:

BR_CID: 0x00000020000000090000000100000002

Can you share what command did you try?

When you provided the board/sku in flash.sh, please do not add SKIP_EEPROM_CHECK in your board config, just use t he default one.

I admit I’m not sure what the FAB number is for my boards, so I tried several different ones, the commands I’ve tried recently are:

sudo BOARDID=3448 FAB=400 ./flash.sh -k EBT jetson-nano-devkit mmcblk0p1
sudo BOARDID=3448 FAB=200 ./flash.sh -k EBT jetson-nano-devkit mmcblk0p1
sudo BOARDID=3448 FAB=000 ./flash.sh -k EBT jetson-nano-devkit mmcblk0p1

I went and tried them without having SKIP_EEPROM_CHECK enabled and it still locks up in the same spot.

I am not sure why you use -k EBT in your command… this is wrong. Please remove it.

Sorry, not sure where I got the idea to use the -k EBT flag, must of read it on a forum post or something.

Regardless I tried all 3 combinations again but this time without the -k EBT flag. I found that in all 3 attempts the script hangs at the following spot:

[   0.6706 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml --skipuid
[   0.6723 ] RCM version 0X210001

It stays there regardless of how long I wait, I left it for ~20-30 minutes and it still hadn’t completed, so I force killed the application.

Attached is the full log for reference.

tegrarcm_hangs.txt (8.5 KB)

Please also try this post. This one is actually same as your problem.

The difference is you are using sdcard module while he is using emmc. You should append below line in “p3448-0000.conf.common” and flash:
BCFFILE=“bootloader/${target_board}/cfg/board_config_p3448.xml”;

Also, make sure board_config_p3448.xml has the correct info of your board.

Good news, I followed the steps from the post provided by Wayne and I managed to get both boards to flash and boot again. Below are the steps I performed:

  • Add lines BCFFILE="bootloader/${target_board}/cfg/board_config_p3448.xml" to file p3448-0000.conf.common
  • Add lines BOARDID=“3448”; and FAB=“000”; to file p3449-0000+p3448-0000-qspi-sd.conf
  • Ran flash script: sudo ./flash.sh jetson-nano-devkit mmcblk0p1
  • The process was able to flash successfully and attempted to boot. However I found that the boot process would result in a black screen for several minutes before showing console stuck (unable to reach 1st time setup). I believe this is due to EEPROM checksum being invalid.
  • I had to Ctrl+Alt+F2 to reach alternative TTY. Root is locked out by default so I had to insert SD card manually into a PC and modify /etc/passwd to allow root to login without password.
  • Upon performing i2cdump, I found that the EEPROM appeared correct except for the checksum, so I calculated the proper checksum for the data (CRC8) and modified the checksum using i2cset i2cset -f 2 0x50 0xFF [checksum byte]
  • I noticed that even after this the system still took several minutes to boot and show anything and still wouldn’t show the greeter. So I re-flashed using flash.sh again but without the modifications to the conf and common files detailed above (stock L4T scripts).
  • After 2nd flash system booted and 1st time setup came up.

One thing I found that is strange is that the mac address of the Ethernet port doesn’t match whats in the EEPROM. ip link reveals that the mac address is 96:44:19:58:f6:cf for both of the jetsons I repaired. The eeprom for one of them has a mac address of 00:04:4b:eb:d9:75. I’ve attached a boot log as I saw some messages about reading the mac address for the r8168 device (ethernet).

journaloutput_jetson.log (364.4 KB)

please file a new topic for your mac if you can flash the board now.

Ok I can create a new topic for the mac address. I’m glad to at least have the devices booting again. Thanks for the help!