HELP PLEASE Not able to flash anymore

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

I accidentally deleted something. And then I couldn’t use sudo anymore, everything went black and when I went to flash it again it’s not able to read the board information
This is the output from flashing

        TX2 Version
  1. TX2
  2. TX2i
  3. TX2-4G
  4. Cancel (back to main menu)
    Enter choice: 1
    ###############################################################################

L4T BSP Information:

R34 , REVISION: 1.1

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

Target Board Information:

Name: cti-tx2-asg007-00, Board Family: t186ref, SoC: Tegra 186,

OpMode: production, Boot Authentication: NS,

Disk encryption: disabled ,

###############################################################################
./tegraflash.py --chip 0x18 --applet “/home/ecoation/nvidia/nvidia_sdk/JetPack_5.0.1_DP_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/mb1_recovery_prod.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.0076 ] Generating RCM messages
[ 0.0102 ] tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 0 --download rcm /home/ecoation/nvidia/nvidia_sdk/JetPack_5.0.1_DP_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
[ 0.0118 ] File /home/ecoation/nvidia/nvidia_sdk/JetPack_5.0.1_DP_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin open failed
[ 0.0119 ] Cannot create RCM messages
[ 0.0119 ]
Error: Return value 19
Command tegrarcm_v2 --listrcm rcm_list.xml --chip 0x18 0 --download rcm /home/ecoation/nvidia/nvidia_sdk/JetPack_5.0.1_DP_Linux_JETSON_AGX_XAVIER_TARGETS/Linux_for_Tegra/bootloader/mb1_recovery_prod.bin 0 0
Reading board information failed.
@dusty_nv @AastaLLL @linuxdev help please!!! im sorry for tagging but I really need help right now

3

Usually recovery mode is reliable, but sometimes USB itself is not. I always ask first:

  • Is this a VM? Hopefully not, they have USB issues.
  • Is this the original cable shipping with the dev kit? Charger cables are notorious for poor data quality.
  • Is this another carrier board? They have some different requirements at times.
  • Have you tried a different port on the host PC?
1 Like
4

This is a VM but I did one of the commands I found online that should tell you if it is in recovery mode and it worked properly and I’ve never had problems flashing before. Also it is a cogswell if that helps and I’ll try another port and cable tomorrow. Just please tell me it’s not broken. Thanks @linuxdev

5

It is unlikely that it is broken. VMs are very finicky in whether or not they pass through the USB correctly, and even if they do, they tend to lose the USB during disconnect/reconnect (which occurs during the flash). It isn’t possible to support VM flash here since the USB setup is up to the individual brands of VM. If you can figure out how to get the USB to always pass through to the VM, even if it disconnects and reconnects, then it would probably work.

I know about “Cogswell Cogs” (sorry, my humor…there is a cartoon which is the basis of how the Jetson systems were named; the cartoon was from an era before computers had a chance to be “smart”). Not sure what “cogswell” is in the context you mention it (perhaps a carrier board? If so, ingenious play on the cartoon which named Jetsons). Typically the carrier board won’t stop flash from succeeding, but unless its lane routing is an exact match to the dev kit, then the device tree will be wrong and the Jetson would be only partially functional. Custom carrier boards provide their own board support package, mostly based on the dev kit flash software, but perhaps with a different device tree.

Do try different cables. I think about 2 out of 3 charger cables fail for sustained data.

1 Like
6

I haven’t been using charger cables. The only part I find wierd is the error code 19 thing @linuxdev. Also yeah I am using the cogswell carrier board

7

Why are you flashing “jetson-tx2” with rel-34.1? We don’t support jetson-tx2 with rel-34.1 at all.

tx2-series only support to rel-32.

2 Likes
8

@WayneWWW that’s probably it. I swear to god I got the BSP package for 4.6.2 but I might have made a mistake. I’ll look into it and get back to you. Thanks

9

Also @WayneWWW Do you have any idea what the Error: Return value 19 means? I’m a little confused by it. I know I already asked Linux but it’s been a while

10

OH THANK GOODNESS! YOU SAVED MY JOB
THANK YOU SUCH ALL OF YOU @WayneWWW @linuxdev I really appreciate it. I almost thought i broke the board-- I would have been fired probably. Thank you so much I really appreciate it. Im sorry for tagging you guys by the way I was just so stressed out.
With that being said, why does the SDK give me the following error when I flash but from the terminal it works fine?
Error:

06:09:22 ERROR: Flash Jetson TX2 - flash: command terminated with error
06:09:22 SUMMARY: DateTime Target Setup - target: Depends on failed component
11

Hi,

You better dumping the full log of sdkm out.

SDKM is installing a lot of things, firstly to your host and then to the device. If something goes wrong in the process, then it will tell us “target: Depends on failed component”. Thus, from what you posted we cannot tell where goes wrong…

12

If you want I can get it all in a text file and post it here if you like? It’s not really necessary but it’d be nice?

13

I am not sure what you want to say here. Please just attach it as test file… that was what I want to tell in previous comment… if you want us to help check your issue…

14

Sorry about that, I was just as confused as before. If you’d like to help solve this new problem, here are the logs that I got from the SDK manager after it said installation failed.
SDKM_logs_JetPack_4.6.2_Linux_for_Jetson_TX2_modules_2022-08-12_05-49-13.zip (115.3 KB)

15

Hi,

Just want to clarify, what is the command you run in terminal to flash the board?

16

Well the logs are from the SDK manager, but the command that I use is sudo ./cti-flash.sh and then i press 7 for my board (Cogswell Carrier board) and 1 for TX2 where the options are TX2, TX2i and 2 others

17

Hi,

What are you trying to do here? Sdkmanager only provides the BSP that supports devkit. If you use cti-flash to flash, it means your carrier board is not NV devkit, but a custom carrier board.

In this case ,you don’t need to flash it with sdkmanger.

18

Ok so my understanding from that is that it won’t work trying to flash the board from the SDK?
Because it is a custom carrier board

19

“Flash” may work, but not able to “boot”. We can help you check why the “flash” failed, but in the end you may still get nothing.

20

Alright that’s fine -Ill just keep doing it via the command line. Not the worlds biggest deal

21

Other carrier boards require software from that carrier board manufacturer. Mostly the change is in device tree, and much of it is in common with the NVIDIA’s dev kit software, but chances are something will not work correctly if you don’t use the software from the manufacturer (it won’t break it, but you’d have to reflash it with the correct software to get it working).