Infinite restarting after flashed Jetson Linux 6.0 production release

I’m using an AGX Orin 64G developer kit and flash its eMMC with JetPack 6.0 production release.

The Ubuntu 22.04 host and the SDK manager are a clean install.
After flashing the Jetson Linux, the AGX Orin rebooted infinitely when it showed “A start job is running for End-user configuration after running OEM installation.”

I retried many times, including setting pre-config to set username and password, but no luck.

The AGX Orin connects a USB keyboard, a USB mouse, and a monitor.

The message disappears when I power down and then up, but it keeps rebooting infinitely.

The UEFI setup seems to work fine. At least the keyboard works.

Because I can’t capture logs at this stage, I check the booting outputs, and there are a few suspicious logs:
IRQ255: set affinity failed(-22)
tegra-ivc-bus bc0000.rtcpu:ivc=bus:echo@0:ivc channel driver missing
tegra-ivc-bus bc0000.rtcpu:ivc=bus:dbg@1:ivc channel driver missing
tegra-ivc-bus bc0000.rtcpu:ivc=bus:dbg@2:ivc channel driver missing
tegra-ivc-bus bc0000.rtcpu:ivc=bus:ivccontrol@3:ivc channel driver missing
tegra-ivc-bus bc0000.rtcpu:ivc=bus:ivccontrol@4:ivc channel driver missing

I re-insert the NVMe, which contains a 6.0 DP installation. It boots and runs with no problem.

Please use the serial console log to dump the log. (the micro usb port on NV devkit).

Here is the dumped serial console log

minicom.cap.txt (287.5 KB)

Update: I checked logs and saw a line usb usb2-port2: config error.

My host PC is a Ryzen 8845HS mini PC, and I connect the AGX Orin to a USB 4 port with a USB 3.2 cable.
I move to a USBC 3.2 port, the Orin boot.

Could you reproduce my case on your side? The USB 4 can do the flash but block boot, so maybe there’s an issue with the AGX Orin’s firmware.

Thank you.

Update 2:
My previous successful attempt is flashing to NVMe.
I retried to flash the eMMC again, but it rebooted infinitely after flashing Jetson Linux.

Here are the serial console outputs

minicom.cap.txt (251.0 KB)

Hi @jasl9187

Thanks for sharing the log. It is helpful.

According to the log, I saw the error log is from register 0x155c00b4.

This is related to display. Could you help remove any display cable on your side and see if this could make the board boot into prompt in console?

Also, could you clarify how is your display connection?

You’re right. I disconnected the cable, and the AGX Orin no longer rebooted.

Logs here: minicom.cap.txt (41.5 KB)

This AGX Orin was bought about one year ago. I use a portable HDMI display for it, but it mostly runs headless as an edge AI server.

Because the display only has a HDMI-in, I use a UGreen HDMI-DP adapter to connect them. This works fine before this time.

I also tried to connect it to my Dell 2723QX monitor with a DP cable, but it had the same trouble.


Is Dell 2723QX monitor a pure DP one without adapter?

Could you dump the log with pure DP cable/port case too? Thanks.

Yes, it has a pure DP port, and I connect it with a DP 1.4 cable.

Here’s the log: minicom.cap.txt (145.1 KB)

By the way, I don’t know if they’re related. In my successful attempt, I tried to enable Wayland but failed.
I posted a topic Can not enable Wayland on JP 6.0 GA - #2 by jasl9187


Just to clarify. I actually don’t see any error in your DP case.

What I saw here is

  1. HDMI-DP adapter case → It hits cbb error from display related register.

  2. Pure DP cable case → I don’t see any error. There is no reboot error in the log either. What happened on your side exactly? A blanked screen?
    Is pure DP case log based on Weston/Wayland? Or default X11/Xorg?

This one just flashed the system (you can see the message from logs “Please complete system configuration setup on desktop to proceed”), and I hadn’t done anything yet.
It should be the default X11/Xorg.

I can see the display on the system booting, and then it reboots, so I don’t see GUI.

I record another output, although there is no cbb error, but you can see it restart infinitely:
minicom.cap.txt (288.7 KB)

So the reboot here is not triggered by you?

墁 11.212568] IRQ255: set affinity failed(-22).
[ 13.206582] using random self ethernet address
[ 13.206595] using random host ethernet address
[ 13.395983] using random self ethernet address
[ 13.395994] using random host ethernet address
[ 19.836708] Please complete system configuration setup on desktop to proceed…
?[0000.061] I> MB1 (version:
[0000.066] I> t234-A01-0-Silicon (0x12347) Prod
[0000.071] I> Boot-mode : Coldboot
[0000.074] I> Entry timestamp: 0x00000000
[0000.077] I> last_boot_error: 0x0
[0000.081] I> BR-BCT: preprod_dev_sign: 0
[0000.084] I> rst_source: 0x13, rst_level: 0x0

If so, could you help me do one more test to configure the user account by running on your host PC, reflash the board again and check the uart log again?

Yes, I don’t do anything. any of the reboots are not triggered by me.

The last time I used command-line to configure Jetson was several months ago.
Could you give me more hints or docs about what I need to do?

Sdkmanager will install the BSP directory to your host PC. The default path of this package is ~/nvidia/.

This package will have flash tool which sdkmanager is using to flash your board. Thus, you can also manually flash your board by using these tools without running sdkmanager.

The thing I need you to run is

  1. Following the " Skipping oem-config" in below document in your BSP directory.
    Flashing Support — NVIDIA Jetson Linux Developer Guide 1 documentation

  2. After running (1), flash the board again manually (put the board into recovery mode before running command).

$ sudo ./ jetson-agx-orin-devkit internal

After these steps, your board won’t get stuck in “Please complete system configuration setup on desktop to proceed”.

I would like to know if you get reboot again even in this situation. Thanks.

I think I need maybe an hour to do this, will reply you with the result later.

Thank you for the help.

1 Like

No problem. Also thanks for reporting this issue to us.

I’ve tested it, and it boots successfully without issue!
So, there is probably an issue with the oem-config stage.

Here’s the output: minicom.cap.txt (96.4 KB)


Thanks for testing this.

Let me make a summary here and we will investigate this issue further

  1. When using HDMI-DP adapter, CBB error happened and causes reboot.
  2. When pure DP cable in use, oem-config case will lead to system reboot (reason unknown).
  1. When using HDMI-DP adapter, CBB error happened and causes reboot.
  • I can consistently see the CBB error before restarting, even though it works now.
    • It does not relate to the HDMI-DP adapter. I can see it on pure DP, too.
    • I uploaded an output on Can not enable Wayland on JP 6.0 GA - #2 by jasl9187 you can see the CBB error on my configured installation (on the NVMe) too
    • Although I see this in my working installation (when I reboot it), it seems no harm to my usage, it’s boring because I can see the serial console flood the CBB error outputs
  1. When pure DP cable in use, oem-config case will lead to system reboot (reason unknown).
  • No matter whether using pure DP or DP-HDMI adapter, it always reboots infinitely, and no GUI shows on the oem-config stage
  • I can see it can boot to Gnome Desktop, and no visible issue if skip oem-config (use the technique you taught me),

To summarize:

  • The CBB error is an issue but not critical.
  • Connect host PC with a USB 4 port can get usb usb2-port2: config error. but not critical, too
  • An unknown issue causes the oem-config to reboot infinitely.
    • This is the critical issue

Hi @jasl9187 ,

I just want to clarify these two issues but not mess them altogether.

Could you help confirm if the criteria to trigger the CBB error is due to the I don’t really care about whether Gnome tells you it is X11 or other Window system. I just want to know the steps to trigger CBB error.

Also, your summary here does not match to the log I saw previously.

In previous log, that CBB error leads to reboot too. Are you talking about the one that leads to reboot is just the oem-config? For example, you still see lots of CBB error in UART console now but they didn’t cause reboot.