jetsonusbdwc3jetpack 6bspdevice tree

DWC3 error -71 on Jetson: the JetPack 6 clock reference fix

Andres Campos ·

Key Insights

  • dwc3: probe of 3610000.xhci failed with error -71 means the DWC3 USB controller couldn’t acquire its ref clock during driver probe — USB is completely dead
  • L4T R36 (JetPack 6) made the ref clock mandatory; L4T R35 (JetPack 5) treated it as optional, so device trees ported from JP5 don’t include it
  • The fix is a device tree change — add TEGRA234_CLK_CLK_M as ref to the xhci@3610000 node; no kernel rebuild required
  • Custom carrier board DTS files and vendor BSPs are the most common source of the missing clock entry
  • We’ve applied this fix three times this year across Orin NX, Orin Nano, and a custom board with a six-level-deep vendor DTS

What DWC3 error -71 actually means on Jetson

When your Jetson shows this in dmesg:

[    4.83] dwc3 3610000.xhci: Failed to get clk ref
[    4.84] dwc3: probe of 3610000.xhci failed with error -71

USB is dead. Not intermittent, not degraded — dead. No enumeration happens because the DWC3 host controller never completed its probe sequence. lsusb returns nothing. /dev/bus/usb/ is empty. Any USB peripheral you plug in does nothing.

Error -71 is Linux EPROTONOSUPPORT. In this context it’s a driver probe failure: the DWC3 driver tried to get the ref clock handle, the clock framework said it doesn’t exist in the device tree, and the driver bailed out.

The 3610000 address is the USB3/xHCI controller on Orin NX and Orin Nano. On AGX Orin you’ll see a different address but the same error pattern. If you’re on Thor (T5000) the clock tree is different enough that the fix path diverges — we’ll cover that at the end.

Why DWC3 error -71 regressed in JetPack 6

JetPack 5 ran on L4T R35.x. JetPack 6 runs on L4T R36.x. NVIDIA made significant changes to the USB subsystem in this transition, and one of them bit a lot of custom carrier board teams.

In L4T R35, the ref clock in the DWC3 driver was optional. The driver would attempt to get it, and if it failed, it would log a debug message and keep going. In L4T R36, that changed: the driver now returns -EPROTONOSUPPORT and aborts probe if the clock isn’t found.

NVIDIA updated their reference DTS files alongside the driver, so teams on standard devkits never saw this. Custom carrier board teams are a different story:

  • If you ported your JP5 DTS to JP6 without checking the USB clock entries, you hit this immediately
  • If you’re on a carrier board vendor BSP that hasn’t been updated for JP6, same problem
  • Orin NX and Nano teams are disproportionately affected because their reference boards are newer designs and some vendor SDKs still ship older DTS derivations

We saw this on three separate engagements in the past year — each time the team had a working JP5 setup and hit the wall when they tried to move to JP6.

How to diagnose DWC3 error -71 on Jetson Orin

Run this from the Jetson (or from serial console if USB is completely dead):

# Confirm the probe failure
sudo dmesg | grep -E "(dwc3|xhci|usb)" | head -40

# Look for the specific error pair
sudo dmesg | grep "Failed to get clk"
sudo dmesg | grep "probe of.*failed with error -71"

If you see:

[    4.83] dwc3 3610000.xhci: Failed to get clk ref
[    4.84] dwc3: probe of 3610000.xhci failed with error -71

That’s your bug. You don’t need to look further.

If USB is working but flaky, or if you see Set TR Deq Ptr cmd failed instead, you’re on a different failure path — those are xHCI command timeout errors and have a separate diagnosis.

Also confirm you’re on L4T R36 and check your active DTS:

# Confirm JetPack version
cat /etc/nv_tegra_release

# Find your active DTB
cat /proc/device-tree/nvidia,dtsfilename 2>/dev/null || ls /boot/*.dtb | head -5

If you’re on L4T R36 and the DTS file predates L4T R36, you’re almost certainly hitting the missing clock.

The device tree fix

The fix is in the USB controller’s DTS node. You need to add the ref clock entry.

Find your device tree source. On Orin NX or Orin Nano with a custom carrier board, you’ll have a top-level DTS that includes the SoC dtsi. The USB controller node looks something like this (missing the ref clock):

/* Before — missing ref clock */
xhci@3610000 {
    clocks = <&bpmp TEGRA234_CLK_XUSB_CORE_SS_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_CORE_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_FALCON_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_FS_DEV>;
    clock-names = "ss_src", "hs_src", "fs_src", "falcon_host";
};

Add CLK_M (the 38.4 MHz crystal reference clock) as the ref entry:

/* After — with ref clock */
xhci@3610000 {
    clocks = <&bpmp TEGRA234_CLK_XUSB_CORE_SS_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_CORE_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_FALCON_DEV>,
             <&bpmp TEGRA234_CLK_XUSB_FS_DEV>,
             <&bpmp TEGRA234_CLK_CLK_M>;
    clock-names = "ss_src", "hs_src", "fs_src", "falcon_host", "ref";
};

After the patch, compile and deploy:

# In your L4T build tree
make dtbs

# Copy new DTB to target
scp tegra234-p3767-xxxx.dtb user@jetson:/boot/

# Reboot and confirm
sudo reboot
sudo dmesg | grep "Failed to get clk"  # Should return nothing
lsusb                                   # Should show your devices

If your DTS already has clock entries but you’re still getting error -71, the clock name might differ. Check the L4T R36 reference DTS for your SoC under hardware/nvidia/platform/t23x/ for the exact clock names NVIDIA uses in the updated reference.

When the DTS patch isn’t enough

The two-line fix above handles the straightforward case. It gets more complicated when:

You’re on a carrier board vendor BSP. The vendor’s DTS may override the USB node in ways that conflict with your patch. You’ll need to trace the full DTS include chain to find where the clock entries live and which override wins. Depending on how the vendor structured their BSP, this can take a few hours.

You’re using device tree overlays (DTBOs). Overlays can fail to apply correctly if phandle structures changed between L4T versions. The overlay may look correct but silently not patch the right node.

USB works after the fix but drops under load. That’s a separate failure mode — typically missing or mismatched firmware (xusb_sil_rel_fw.bin), PCIe spread-spectrum clocking conflicts, or VBUS power sequencing on your carrier board. The clock fix just gets probe to succeed; runtime stability is a different problem.

You’re on Jetson Thor (T5000). Same error code, different clock tree. The fix path exists but it’s more involved.

We’ve resolved this exact error three times in the past year — on Orin NX, Orin Nano, and once on a carrier board with a vendor BSP that had layered DTS overrides six levels deep. If you’re past the self-service path, book a 30-minute scoping call and we’ll scope it out.

For related Jetson USB debugging, see our post on JetPack 6 USB enumeration failure which covers the broader class of USB bring-up issues on Orin. For the full JetPack 5 to 6 DTS migration scope, see what breaks when upgrading from JetPack 5 to 6.

The upstream DWC3 driver behavior is documented in the Linux kernel DWC3 driver source. NVIDIA’s L4T-specific changes are tracked in the NVIDIA Jetson Linux release notes.

Frequently Asked Questions

What does “dwc3 probe of failed with error -71” mean on Jetson?

Error -71 is Linux EPROTONOSUPPORT, meaning the DWC3 USB driver failed during its probe sequence. On Jetson Orin under JetPack 6, this specifically means the driver couldn’t acquire the ref clock from the device tree. USB will not work at all until this is resolved.

Why does DWC3 error -71 only appear in JetPack 6 and not JetPack 5?

L4T R36 (JetPack 6) changed the DWC3 driver to require an explicit ref clock declaration in the device tree. In L4T R35 (JetPack 5), this clock was optional — the driver would silently continue if it wasn’t found. Device trees ported from JP5 to JP6 without this clock entry will fail.

Can I fix DWC3 error -71 without rebuilding the kernel?

Yes, in most cases. The fix is in the device tree (DTB), not the kernel itself. You modify the DTS source, recompile the DTB, and copy the new DTB to /boot/. No kernel recompile required.

Does DWC3 error -71 affect USB 2.0 and USB 3.0 equally?

Yes. The DWC3 controller handles both USB2 and USB3 on Orin. When the probe fails, neither works. You won’t get partial USB2 functionality — the host controller never comes up.

What if USB works after fixing the clock but then drops under load?

That’s a different failure mode. Probe success with load-dependent drops typically points to firmware issues (xusb_sil_rel_fw.bin missing or wrong version), PCIe spread-spectrum clocking conflicts, or VBUS power sequencing on custom carrier boards. Check dmesg | grep -i "xhci\|trb\|deq" during a failure event.

ProventusNova helps hardware startups get Jetson BSP problems resolved fast. If DWC3 error -71 is blocking your custom carrier board bring-up, book a scoping call — we’ve fixed this exact pattern three times this year.

← Back to Blog