Stuck in diagnostic mode after DTB modification

Robotics & Edge Computing Jetson & Embedded Systems Jetson Thor
1

Thor Recovery Status Report

Last updated: September 20, 2025, 4:52 PM PST

Current Situation

Thor remains stuck in “Tegra On-Platform Operator” mode (USB ID: 0955:7045) which is a diagnostic/debug mode, not the proper APX recovery mode (0955:7023) needed for flashing.

What We’ve Tried

✅ Successful Communications

  1. Board Control Tools Work:

    • Can power on/off Thor
    • Can trigger reset
    • Can attempt recovery mode
    • Status shows board is powered and connected

  2. Serial Ports Available:

    • /dev/ttyACM0-3 created when Thor connected
    • These are debug UART interfaces
    • Serial console should work but needs proper terminal setup

❌ Failed Recovery Attempts

  1. Standard Recovery Button: Multiple attempts, always results in 0955:7045
  2. SDK Manager: Cannot detect Thor in this mode
  3. flash.sh: Fails with “probing the target board failed”
  4. tegrarcm_v2: Cannot communicate via USB in this mode
  5. tegraflash.py: Missing configuration files for this mode
  6. USB Reset: Device stays in 0955:7045 mode
  7. Board Automation Recovery: Commands execute but device stays in 0955:7045

Root Cause

The device tree modification (FDT /boot/tegra234-p3737-0000+p3701-0008.dtb) has corrupted the boot chain, causing Thor to enter a diagnostic mode instead of normal boot or recovery.

Why 0955:7045 Mode is Problematic

  • This is “Tegra On-Platform Operator” mode - a debug/diagnostic state
  • Standard NVIDIA flash tools don’t recognize this mode
  • It’s not the proper APX recovery mode (0955:7023)
  • Appears to be used for board automation and testing, not recovery

Remaining Options

Option 1: Serial Console Boot Interrupt

  • Connect via picocom/minicom to ttyACM ports
  • Monitor boot process
  • Interrupt at bootloader to access UEFI or recovery menu
  • Requires catching the right moment during boot

Option 2: Direct NVMe Recovery

  • Remove NVMe drive from Thor
  • Connect to another system via USB adapter
  • Write JetPack image directly to drive
  • Reinstall in Thor

Option 3: NVIDIA Support

  • This appears to be a known but uncommon issue
  • NVIDIA support has tools for 0955:7045 recovery
  • May require RMA if bootloader is permanently corrupted

Option 4: Wait for Complete Discharge

  • Disconnect all power for 12-24 hours
  • Some users report this resets stuck states
  • Worth trying as a last resort

Technical Details for Support Ticket

Device: NVIDIA Jetson AGX Orin Developer Kit (Thor)
Issue: Stuck in diagnostic mode after DTB modification
USB ID: 0955:7045 (should be 0955:7023 for recovery)
Modification that caused issue: Added FDT /boot/tegra234-p3737-0000+p3701-0008.dtb to /boot/extlinux/extlinux.conf
Board control status:

GPIO_ACOK is 0
GPIO_FRC_OFF_N is 1
GPIO_FRC_REC_N is 1
GPIO_MODULE_PWR_ON is 1
GPIO_PGOOD is 1
GPIO_PWR_BTN_N is 1
GPIO_SYS_RST_N is 1

Lessons Learned

  1. Never modify device tree references on-device
  2. The 0955:7045 mode is not a standard recovery mode
  3. Board automation tools can control Thor but can’t change USB modes
  4. Serial console access is available but complex to use

Next Steps

  1. Immediate: Try serial console boot interrupt
  2. If that fails: Contact NVIDIA support with this documentation
  3. Last resort: Physical NVMe removal and direct flashing
  4. Prevention: Never modify DTB files without proper backup/recovery plan
2

UPDATE: I tried directly flashing JetPack to NVMe and it was not successful.

4

Hi jesse75,

Are you using the devkit or custom board for Thor?
What’s the Jetpack version in use?

Are you using AGX Thor or AGX Orin?

Is there any log output from /dev/ttyACM0?
If so, please share it for further check.

Do you mean that there’s no issue before your customization?

5

Thank you for your response. Let me clarify with accurate details:

Device Clarification:

  • Hardware: NVIDIA Jetson AGX Thor Developer Kit

  • This is AGX Thor, not Orin

  • Using official Thor devkit, not custom board

  • 128GB memory, Blackwell architecture

JetPack Version:

  • Original installation version unknown (inherited device)

  • Attempted recovery with both JetPack 6.0.1 and JetPack 7

The Critical Issue:

  • Device is stuck showing USB ID 0955:7045 (“Tegra On-Platform Operator”)

  • Should show 0955:7023 for proper recovery mode

  • SDK Manager cannot detect device in this 0955:7045 state

Exact Modification That Caused Issue:

  • Added line to /boot/extlinux/extlinux.conf: FDT /boot/tegra234-p3737-0000+p3701-0008.dtb

  • Intent was to enable 25GbE networking capability

  • After reboot: boots directly to UEFI Shell only

Recovery Attempts (All Failed):

1. Standard recovery button procedure - remains in 0955:7045, won’t enter 0955:7023

2. SDK Manager - cannot detect device in current USB state

3. Direct NVMe flashing - results in UEFI Shell boot

4. Power drain/USB reset - no effect

/dev/ttyACM0 Output:

I will check for logs from /dev/ttyACM0-3. Could you specify:

  • Which ACM port to monitor?

  • Baud rate settings?

  • Any UEFI Shell commands that might help?

Key Question:

How do we recover Thor from “Tegra On-Platform Operator” (0955:7045) state? The device

seems stuck in diagnostic mode rather than proper APX recovery mode. Standard recovery

procedures aren’t working because SDK Manager expects 0955:7023.

Is there a specialized procedure for Thor in this USB device state, or does this require RMA?

Thank you for your assistance!

6

For the Thor, it can support only Jetpack 7, please use Jetpack 7.0 GA(L4T r38.2) to verify.

Please try to press REC button before power up the board and connect the USB-C cable to your host to check if it can be recognized.
Have you confirmed that you connect the correct power for flash?

This DTB is for AGX Orin Industrial rather than AGX Thor..
I don’t think you need to do any customization as you are using AGX Thor devkit.

/dev/ttyACM0, 115200 baud rate, please share the full serial console log first.

Do you have other AGX Thor devkit hitting the similar issue?

7

Hi, thank you for your response. We are trying to reset to original condition. I do not have the other Thor yet, it should be here tomorrow and will be fine because we won’t modify these files. We don’t need customizations and made an error with doing what we did. Please see update below:
Summary for NVIDIA:

1. Thor boots directly to UEFI Shell (not Linux)

2. Found the wrong DTB file in /boot/tegra234-p3737-0000+p3701-0008.dtb (this is for

AGX Orin Industrial)

3. No extlinux.conf file found in expected locations

4. Serial console via USB-C not accessible (device shows as 0955:7045, not proper mode)

Key finding: The wrong DTB file confirms their diagnosis - we accidentally used an Orin

Industrial DTB on Thor hardware.

Since we can’t get serial console output over USB in this state, tell NVIDIA:

  • You can access UEFI Shell directly with keyboard/monitor

  • The wrong DTB file is confirmed present

  • Boot configuration appears missing/corrupted

  • Need recovery procedure for device stuck in 0955:7045 mode

8

Okay, please ensure that the correct DTB been used for AGX Thor devkit.
As my understanding, it should be /boot/dtb/kernel_tegra264-p4071-0000+p3834-0008-nv.dtb

For the devkit, we would strongly use SDK manager to flash it. You don’t need to modify anything in BSP package.

9

Hello, I am not able to flash to Thor, it is still showing the wrong mode, which won’t allow flashing as the board is not recognized. Is there any way to fix or RMA this? I attempted the manual walkthrough in SDK as well.

Issue Description

Device is completely bricked after incorrect DTB flash. Cannot enter recovery mode properly for reflash.

Root Cause

Accidentally flashed with Orin Industrial DTB instead of Thor DTB:

  • Used (incorrect): tegra234-p3737-0000+p3701-0008.dtb (Orin Industrial)
  • Should have used: tegra264-p4071-0000+p3834-0008-nv.dtb (Thor)

Recovery Attempts

1. Recovery Mode Attempts

  • Put device in recovery mode (middle button + power)
  • USB device detected as ID 0955:7045
  • However, flash tools do not recognize this as valid Thor recovery mode
  • SDK Manager and flash.sh both report “No board detected”

2. Software Environments Tested

  • Host OS: Ubuntu 22.04 LTS on Mira (10.0.0.163)
  • SDK Manager: Version 2.2.0.12019
  • JetPack: 7.0 (downloaded specifically for Thor)
  • BSP: Linux_for_Tegra from JetPack_7.0_Linux_JETSON_AGX_THOR_TARGETS

3. Flash Commands Attempted

# Standard flash attempt
sudo ./flash.sh jetson-agx-thor mmcblk0p1

# With explicit board config
sudo ./flash.sh -r jetson-agx-thor mmcblk0p1

# With environment variables
sudo BOARDID=p4071 BOARDSKU=0000 ./flash.sh jetson-agx-thor mmcblk0p1

# All result in: "Error: probing the target board failed"

4. Troubleshooting Steps

  • Verified USB cable (data capable)
  • Tried multiple USB ports (USB2 and USB3)
  • Installed all required dependencies
  • Downloaded fresh BSP for Thor
  • Confirmed correct permissions (sudo)
  • Verified lsusb shows device (0955:7045)

Current State

  • Device powers on but cannot boot
  • Cannot enter proper recovery mode recognized by flash tools
  • USB ID 0955:7045 appears to be corrupted recovery state
  • Bootloader likely damaged from incompatible Orin DTB

10

Is there a VM involved? This would cause the expected behavior. It sounds like you are using a full o/s and not a VM, but it has to be asked. You might also save a log of the flash attempt, and post the error which shows up. Example:
sudo ./flash.sh jetson-agx-thor mmcblk0p1 2>&1 | tee log_flash.txt

Sometimes a USB port works at slow speeds, but fails during data transfer, so you might try a different port on the host PC. I doubt this is a problem with a USB-C cable, they tend to be of much higher quality than the older micro-OTG cables.

11

Hi jesse75,

Have you also tried to capture if there’s any serial console log output?

For the RMA, please refer to Jetson FAQ | NVIDIA Developer for details.

12

Hi linuxdev, thanks for weighing in. The issue is that an Orin boot file was errantly inserted into the boot sequence and now we are unable to flash. We can’t get any log output because we can’t access anything as we do not have access to the correct recovery state.

13

You might want to include the serial console output @KevinFFF asked for. People normally only think of serial console logs for a booting or booted system, but you can also get such a log with useful information when a Jetson is in recovery mode and being flashed.

Even a bad device tree file should not be an issue to flash since much of that data is just treated as binary content during a flash. Have you ever tried to clone the rootfs of the Jetson? I don’t ask this for the purpose of backing up so much as the fact that it is a recovery mode operation which is read-only and it tests functionality.

Cloning a recovery mode Jetson rootfs for test purposes would use a lot of disk space and take significant time for the host PC, but might go something like this (I have not tried on Thor, but likely it is the same; if not, just describe what went wrong and someone can probably state if Thor differs in a way which would cause the failure):
sudo ./flash.sh -r -k APP jetson-agx-thor mmcblk0p1

If this does succeed, then you are pretty much guaranteed the Jetson is fully functional (but as I said, Thor is new, so although I think this procedure would work I have not tested). You would also have a raw partition (system.img.raw) you could loopback mount and examine if you wished; if not, then you can delete the cloned partitions (they are quite large). A loopback mount, if the clone is named system.img.raw, would go something like this:

sudo mount -o loop system.img.raw /mnt
cd /mnt
ls
cd ./boot/extlinux
cp extlinux.conf ~/Downloads
cd
sudo umount /mnt

If you can clone and loopback mount the raw image, then perhaps you can post a copy of the “/boot/extlinux/extlinux.conf” file. extlinux.conf lists device trees; so long as security fuses are not burned the named file would be used. If such a file cannot be used, then it would revert to using a binary partition's signed copy of that device tree. There is a possibility that something would cause the /bootcopy to not be readable, and in that case, revert to the binary partition's file. Serial console information is useful in part because it allows seeing which file is being attempted;extlinux.conf` from a loopback mounted raw image clone can tell us which file is intended to be used.

As mentioned I can see a bad file in “/boot” as easily causing a boot failure, but not a flash failure. Beware though that during a normal flash (not command line; this does not apply to command line) via JetPack/SDK Manager the system automatically reboots and then gets optional packages installed over ssh to a fully booted system once first boot setup is complete.

I’m not quite yet set up where I can attempt the clone or flash of a Thor, I have some host PC issues to get past before I can do that, otherwise I’d test this.

Also, if a Jetson can be cloned, then you might want to log the clone itself since it will show some information which would also be used in flash. Clone is read-only, so it might succeed where flash does not. An example of clone with log:
sudo ./flash.sh -r -k APP jetson-agx-thor mmcblk0p1 2>&1 | tee log_clone.txt

14

Reading this thread and I can not see any information how you have connected your dev-kit to your PC. The USB device 0955:7045 is from the debug port, not the recovery port. I had kind of similar issues and found out that I needed to use a USB-C to USB-A cable (the one that was shipped with the dev-kit) from connector J81(closest to HDMI/DP) to my PC. Initially I tried with a USB-C to USB-C cable and then I was not able to detect the dev-kit in recovery mode on my PC.

Getting in to recovery mode on the device shall be a really low-level thing and your dtb change shall not affect this.

My advice is to look in the log on your PC while putting you dev-kit in recovery mode. You should be able to see that the device is detected. In my case when I had the USB-C to USB-C cable I got a lot of errors in the log. Switching to USB-C to USB-A cable it showed up as normal.

HTH
/Peter

15

Thank you all for your replies. I’m on Ubuntu machine and have tried all USB connections including 2.0. My underlying issue is that the boot files for Orin were used in error and overwrote the Thor files, so this device is not recognized and cannot be flashed. It is not recognizable. The unit shows but with the wrong ID so it shows as no board. The files are in FS2 in shell. If I remove the NVMe, can I flash it directly with BSP files and would that work? Or how can I get the correct files back on this unit without connecting to the unit directly? I can’t access logs or anything or generate them.

16

I’m surprised such a thing happened where it used the wrong files. So far as I know recovery mode does not care about the flashed files (there are probably some difficult-to-find-or-use i2c commands which could harm something). You really need the serial console log to be able to say more though, it is almost impossible to say anything useful without that at this point.

Regardless, you’d have to have direct physical access. If the Thor does not show up with the correct “lsusb” ID when in recovery mode, then you probably would need to RMA it (see @KevinFFF’s post). Jetsons do not have the same BIOS scheme that a desktop PC has, and so this changes what you can do and increases how important that serial console log is.

17

Hi,

I am just curious. Did you ever use same host and pure Jetpack7.0 BSP to flash this devkit before all these problems happened?

18

Hello, I was trying to install Omniverse but it showed errors and since them even my board is struck in debug mode. It shows ID/; 0955: 7045, tried everything but I am unable to reflash. Kindly help.

I am using NVIDIA AGX Thor Developer Kit.

20

Hi @farhafarhi21

I think this post was to focus on the situation that @jesse75 met. If you have your own issue, please file another topic.

21

Thanks everyone. I’m not sure what did it, but was able to get the BSP flash working to the correct 7026 port.

22

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