Hardware
- Jetson Orin NX 16GB module (p3767-0000)
- Waveshare JETSON-ORIN-IO-BASE-B carrier (DisplayPort only, no HDMI)
- Monitor connected via native DisplayPort cable (also tested DP->HDMI adapter)
- Root filesystem on NVMe
Symptom
The bootloader/UEFI drives the monitor correctly — the NVIDIA logo and boot
messages are displayed over the same cable and monitor. The moment Linux takes
over, the screen goes black and the monitor reports “no signal” and enters
standby. This never recovers. The system is otherwise fully functional and
reachable over SSH.
What I have tested
-
L4T 36.4.3 (JetPack 6.2), as originally flashed
/sys/class/drm/card1-DP-1 : disconnected : edid = 0 byte
dmesg:
dce: dce_ipc_channel_init:311 Invalid Channel State [0x0] for ch_type [2]
dce: dce_admin_setup_clients_ipc:585 Channel Reset Complete for Type [1]
dce: dce_admin_setup_clients_ipc:561 Get queue info failed for [2]
dce: dce_admin_setup_clients_ipc:585 Channel Reset Complete for Type [3]
dce: dce_start_boot_flow:166 DCE_BOOT_DONE
nv_platform 13800000.display: [drm] Cannot find any crtc or sizes
NVRM rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0xffff
(the NVRM line repeats hundreds of times, and a new burst appears every
time the DP cable is unplugged/replugged — so hotplug IS detected)Xorg.0.log (with the stock configuration):
(–) NVIDIA(GPU-0): DFP-0: Internal DisplayPort
(–) NVIDIA(GPU-0): DFP-1: Internal TMDS → disconnected -
Forcing the display in xorg.conf
With Option “ConnectedMonitor” “DFP-0”, Option “UseEDID” “false” and an
explicit 1920x1080 modeline, X does set the mode:
(II) NVIDIA(0): Setting mode “DFP-0:1920x1080_60.00”
but the monitor never wakes up, so no link is established. -
Removing video=efifb:off from the kernel command line
No change — the bootloader framebuffer is torn down when nvidia-drm loads. -
apt upgrade to L4T 36.4.7
I discovered the firmware was out of sync: kernel/drivers were at 36.4.7
while nvbootctrl still reported 36.4.3 and “Capsule update status: 0”.
I applied the capsule manually (TEGRA_BL_3767_super.Cap to
/boot/efi/EFI/UpdateCapsule/TEGRA_BL.Cap + OsIndications), after which:
Current version: 36.4.7
Capsule update status: 1
DMI: … BIOS 36.4.7-gcid-42132812 09/18/2025
Display behaviour unchanged. -
Full clean flash to L4T 36.3.0 (JetPack 6.0) using
l4t_initrd_flash.sh --external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_t234_nvme.xml
-p “-c bootloader/generic/cfg/flash_t234_qspi.xml”
–showlogs --network usb0 jetson-orin-nano-devkit internal
“Flash is successful”.On 36.3.0 the situation is different but still broken:
/sys/class/drm/ contains only: card0 renderD128 version
→ there are NO connector directories at alldmesg:
drm drm: [drm] Cannot find any crtc or sizes
dce: dce_ipc_channel_init:311 Invalid Channel State [0x0] for ch_type [2]
dce: dce_admin_setup_clients_ipc:561 Get queue info failed for [2]
dce: dce_start_boot_flow:166 DCE_BOOT_DONElsmod shows nvidia, nvidia_modeset, tegra_drm, drm_kms_helper, host1x all
loaded.
Device tree / board identification (on 36.4.x)
/proc/device-tree/model:
NVIDIA Jetson Orin NX Engineering Reference Developer Kit Super
/proc/device-tree/compatible:
nvidia,p3768-0000+p3767-0000-super
nvidia,p3767-0000
nvidia,tegra234
Questions
-
Is “dce_admin_setup_clients_ipc:561 Get queue info failed for [2]” together
with “Invalid Channel State [0x0] for ch_type [2]” expected on a healthy
system, or does it indicate that the display IPC channel genuinely failed
to come up? It is present on both 36.3.0 and 36.4.7 here. -
On 36.3.0 no DRM connectors are created at all, while on 36.4.x a DP-1
connector exists but is permanently “disconnected” with a 0-byte EDID.
What would explain the difference, and does it point to the DCB/pinmux
being wrong for this carrier? -
The module is on a third-party carrier (Waveshare IO-BASE-B) flashed with
the jetson-orin-nano-devkit configuration, which is what the vendor’s
documentation instructs. Is there a way to verify from the running system
which DCB was actually applied, and whether DP is enabled for SOR on this
configuration? -
Given that UEFI successfully drives the same monitor over the same cable,
can this still be a hardware issue (for example AUX AC-coupling on the
carrier), or does the bootloader use a path that would work regardless?
I can provide full dmesg, Xorg.0.log or the flash log on request.
I am happy to test JetPack 6.2.3 / Jetson Linux 36.5.2 if you think that
could change anything — I have not tried it yet.