Flash.sh fail when used "sudo reboot force recovery"

After encountering several issues related to UEFI automatic update, I realized that I was unable to reflash the board using the flash.sh script.

Currently, I have a functioning board that allows me to log in via SSH. I can execute the command:

sudo reboot forced-recovery

This successfully lists the device on my computer as:

Bus 003 Device 032: ID 0955:7223 NVIDIA Corp. APX

However, when I attempt to run flash.sh, the process fails with the error:

Error: failed to open USB

Interestingly, if I repeat the process but instead of using sudo reboot forced-recovery, I manually press the Recovery + Reset buttons, the device is listed correctly, and the flashing process proceeds successfully.


At the moment, I am using a custom PCB. I could attempt to replicate the issue on a devkit, but I would like to understand:

  • Is there a difference between sending the forced-recovery command and performing a manual factory recovery?
  • Could this issue be related to a hardware limitation or a change introduced in the latest update?

Our primary concern is that disassembling our already-built devices for manual recovery is highly time-consuming for the hardware team. We would prefer to continue using the “software method” if possible.

Additionally, after flashing JetPack 5.1.3, the same board and SOM allow subsequent software-triggered flashing without issues, suggesting that this problem started after the latest update.

Please let us know what additional information would be helpful in diagnosing this issue. Any guidance would be greatly appreciated.

Hi,
If the device cannot be flashed/booted, please refer to the page to get uart log from the device:
Jetson/General debug - eLinux.org
And get logs of host PC and Jetson device for reference. If you are using custom board, you can compare uart log of developer kit and custom board to get more information.
Also please check FAQs:
Jetson AGX Orin FAQ
If possible, we would suggest follow quick start in developer guide to re-flash the system:
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation
And see if the issue still persists on a clean-flashed system.
Thanks!

So what is the “latest one” that can reproduce issue? Is that Jetpack6.2 or Jetpack5.1.4?

Since that is a custom board, are you sure the BSP you are using is really correct and able to work on that board?
I didn’t hear a custom PCB can really change BSP version in such casual way.

Hello Wayne
We are currently running JetPack version 5.1.3; however, I am unsure which version was applied following the update. I will attempt to reproduce the issue, although I believe it is not hardware-related since all procedures were performed on our custom PCB.

Initially, we were operating on an unknown JetPack version—presumably, one that was automatically updated after 5.1.3. The command sudo reboot --force-recovery successfully placed the device in recovery mode, but the flash script failed, as depicted in the attached image.

Subsequently, we reflashed the SoM by manually entering recovery mode using the buttons on our custom PCB (configured according to the manual’s instructions for the development kit). After this, we were able to execute the flash script successfully.

Once the board was flashed with JetPack 5.1.3, we again placed it into recovery mode using sudo reboot --force-recovery and successfully ran the flash.sh script.
Could you please advise on what steps I might take on my end to clarify this behavior?

Hi,

You may need to find out a method to reproduce this issue.

If an issue is really a bug, you won’t be the only one who reported this. However, we didn’t hear any user hitting this in Jetpack5. Thus, I would need you to locate the exact method to reproduce issue.

I apologize for not expressing myself clearly. I do know how to reproduce the problem; however, I wanted to ask which commands I can execute to provide additional context on the issue—so that I can run everything both before and after the problem occurs.
Could you please advise which additional commands I might execute to gather more detailed system information? For example, aside from the operating system version, Jetpack version, and kernel version, are there other relevant details that would help diagnose the issue more thoroughly?

The command to put a board into recovery mode is correct. This one should work.

sudo reboot forced-recovery

Let’s reply this question with points here

  1. Are you able to reproduce this issue with NV devkit? Please make sure you are pretty sure about it.
  2. Have you checked the UART serial console during this flash failure? That one might provide logs to tell what is wrong.

You could just try either latest Jetapck 5 or 6 version. It does not matter which one you want to use here.

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks

BTW, please attach text log file if you want to share log. Screenshot is not a good idea.

1 Like