related: tegra rcm reboot command doesn't work

I try to automate a burn fuses / flash / test setup in production, which requires several reboots - some of which into recovery. We use a OTG usb cable, wich reboots automatically into forced recovery. Also I mounted some network relay in front of the jetson, so I can power cycle programitically. Now the question is: how to skip forced recovery without manually switching the USB cable.

Is there a way to

  1. power-cycle into forced recovery (automatically due to OTG cable)
  2. use e.g. tegrarcm --reboot coldboot to reboot into normal operation
    → “skip” the forced recovery or “continue” into normal boot?

I tried:
sudo ./tegrarcm --instance 2-2.4 --chip 0x21 0 --reboot coldboot
sudo ./tegrarcm --instance /dev/bus/002/… --chip 0x21 0 --reboot coldboot (what lsusb reports)
→ both commands just hang forever (no error, cannot abort via SIGINT or SIGSTOP, terminal blocked)



OK maybe, just as I wrote the question:

cat rcmbootcmd.txt
python3 tegraflash.py --bct “jetson-nano-emmc-XXXX.bct” --odmdata 0xA4000 --bl nvtboot_recovery_cpu.bin.signed --bldtb rcm_tegra210-p3448-0002-XXXX.dtb.signed --applet rcm_1_signed.rcm --cfg rcm-flash.xml --chip 0x21 --lnx boot.img --tos tos-mon-only.img.signed --eks eks.img --kerneldtb rcm_tegra210-p3448-0002-XXXX.dtb.signed --bins “EBT cboot.bin.signed;DTB rcm_tegra210-p3448-0002-XXXX.dtb.signed” --securedev --cmd “rcmboot”

Seems to work…

Hi zschutschke,

How do you use OTG usb cable to enter into force recovery mode?

Does the above script meet your requirement?

Hi Kevin,

Yes, I tested the script successfully – obviously, one needs to preload some parts of the [device-tree / bct / ??] for it to work.

I still do not understand why “tegrarcm --reboot coldboot” does not do the trick – but again, maybe the recovery-bootloader on the jetson needs some additional info to successfully trigger a reboot…

The OTG cable sets the force recovery pin on our custom-carrier board:

Did I miss some documentation on how the flash process is working? I see the coldboot is working after normal flash succeeds. What piece of info is missing in the jetson recovery-bootloader for coldbooting to work?

I suppose one of:
– applet
– bct
– bl
– bct

Best, Axel

You could refer to the following instruction for flash usage.
Flashing and Booting the Target Device | NVIDIA Docs

You could also refer to the following instruction for boot flow.
Bootloader - Jetson Nano Boot Flow| NVIDIA Docs

Hi Kevin,

Thank you, but I know this part of the documentation. My question is: is there anything describing the details on how the recovery-bootloader and the tegrarcm tool are working? Esp. “Flashing and Booting the Target Device” does not help a lot with tegraflash options, other than echoing the option names. It does not describe how the different parts are working together.

Current questions:

  • what is missing in factory-reset / recovery boot environment to perform coldboot ?
    e.g. maybe the coldboot procedure is defined in bct and the recovery boot does not load the bct from the system, but I need to “download” it to the jetson first
  • what does the uid, reported by tegrarcm, describe ?
  • is there a way to identify an idividual jetson in recovery mode and in operational mode (can I read the eeprom before flashing?) → I need to trace the jetson serial number through the process.




Sorry, we don’t have document to guide how to use tegrarcm. Please try to use existing function provided by flash.sh to flash the board.

Is there a way to read the jetson serial number or other identifier without flashing the device?

You can check the cvm.bin. Serial number is stored in cvm eeprom.

./chkbdinfo -a cvm.bin

Thank you, Wayne - how do I get the cvm.bin?

OK, my last script does this job as well:

tegraflash.py … --cmd “dump eeprom boardinfo mycvm.bin”

Thank you a ton :)

1 Like

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