I flashed unmodified Jetpack 6.2.1. on my Orin NX with:
sudo ./tools/kernel_flash/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-super internal
but Jetson recognizes only 1280x720 resolution on my 2560x1440 display (connected via displayport). Is there some display driver issue when using initrd flash?
*** Please note that this reply is generated by LLM automatically ***
To address the issue of the Jetson Orin NX recognizing only 1280x720 resolution on a 2560x1440 display connected via DisplayPort after flashing an unmodified Jetpack 6.2.1 using initrd flash, we need to consider several factors, including the display driver, the initrd flash process, and the configuration of the DisplayPort interface.
Firstly, the DisplayPort interface on the Jetson Orin NX supports higher resolutions, including 2560x1440, as indicated in the Jetson Orin NX Series and Jetson Orin Nano Series Product Design Guide. However, the actual resolution supported may depend on the specific display driver configuration and the settings used during the initrd flash process.
The initrd flash process is used to flash the Jetson Orin NX series and Jetson Orin Nano series with NVMe as the external storage device. The command provided in the context for flashing the default case includes options for specifying the external device, configuration files, and other settings. However, it does not explicitly mention display resolution or DisplayPort configuration.
To resolve the issue, you may need to modify the display driver configuration or the initrd flash settings to support the higher resolution. Here are some potential steps to consider:
In comparison to other Jetson modules, the Jetson Orin NX has a similar DisplayPort interface configuration to the Jetson AGX Orin, but with some differences in terms of pin compatibility and interface usage. The Jetson Orin NX is not pin-compatible with the Jetson Xavier NX series modules, but you can design a carrier board to support both modules by using the common I/O interfaces.
In summary, to resolve the issue of the Jetson Orin NX recognizing only 1280x720 resolution on a 2560x1440 display connected via DisplayPort, you may need to modify the display driver configuration, initrd flash settings, or update Jetpack to a newer version that supports the higher resolution. Additionally, you should verify the DisplayPort configuration and ensure that it is properly set up to support the higher resolution.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Can I have an answer from a human? Thank you.
You better clarifying some points here because initrd flash is never the cause of such problem.
So the carrier board is a custom one. I believe that the displayport is wired quite standardly.
An interesting thing happened when I went to take the logs. So initially, after re-flash
screen was reliably stuck at 1280x720 reboot after reboot.
These are the logs collected:
xorg_log.txt (46.3 KB)
xrandr_log.txt (246 Bytes)
dmesg_log.txt (65.7 KB)
Then just to try things out i tried a different displayport cable, and the screen got its 2560x1440 mode detected. However, it was OK even after I switched back to the old cable. I collected a second round of logs:
dmesg_log_2.txt (65.1 KB)
xorg_log_2.txt (37.7 KB)
xrandr_log_2.txt (273 Bytes)
ChatGPT gave me the following reasoning:
What likely happened
The DisplayPort link or connector pins (especially the hot-plug detect or DDC pins that carry EDID data) weren’t making good contact initially.
Plugging in a different cable caused a full re-initialization of the DisplayPort link, resetting the hot-plug detect line and power to the monitor’s EDID chip.
Once that happened, even the old cable started working because the GPU/monitor pair had resynchronized electrically.
Which seems quite plausible, although it does not explain why at first the display was persistently not being properly detected reboot after reboot. Is the behaviour of the Jetsons displayport somehow different to the behaviour of normal ubuntu PCs (i haven’t had any issue there, regardless of cable used)? What do you think is happening here?
Hi,
There are some debug tips here to clarify things.
The first thing I think you could do is get a NV devkit and put this DP monitor onto it and check if this is really “even NV devkit only gives you one mode”.
Another thing that you could try is enable the full verbose log in xorg. It will tell you why only one mode is shown in the list.
#Add below option in /etc/X11/xorg.conf, 'Section "Device"'. Verbose mode logging will be shown in /var/log/Xorg.0.log
Section "Device"
...
Option "ModeDebug"
...
EndSection
[ 13.653] (II) NVIDIA(GPU-0): --- Building ModePool for Apple LED Cinema (DFP-0) ---
[ 13.653] (WW) NVIDIA(GPU-0): Validating Mode "2560x1440_60":
[ 13.654] (WW) NVIDIA(GPU-0): Mode Source: EDID
[ 13.654] (WW) NVIDIA(GPU-0): 2560 x 1440 @ 60 Hz
[ 13.654] (WW) NVIDIA(GPU-0): Pixel Clock : 241.50 MHz
[ 13.654] (WW) NVIDIA(GPU-0): HRes, HSyncStart : 2560, 2608
[ 13.654] (WW) NVIDIA(GPU-0): HSyncEnd, HTotal : 2640, 2720
[ 13.654] (WW) NVIDIA(GPU-0): VRes, VSyncStart : 1440, 1443
[ 13.654] (WW) NVIDIA(GPU-0): VSyncEnd, VTotal : 1448, 1481
[ 13.654] (WW) NVIDIA(GPU-0): Sync Polarity : +H -V
[ 13.654] (WW) NVIDIA(GPU-0): Mode is rejected: DP Bandwidth check failed.
[ 13.654] (WW) NVIDIA(GPU-0): GPU extended capability check failed.
[ 13.654] (WW) NVIDIA(GPU-0): Mode "2560x1440_60" is invalid.
[ 13.654] (WW) NVIDIA(GPU-0):
I re-flashed the Jetson to get it back to the original state.
xorg_log_3.txt (283.6 KB)
Upon checking the debug log and nvidia-settings, it seems that the Displayport link training managed to get only 2 lanes instead of 4 or more, which makes the Jetson think there is not enough bandwidth to support higher resolution.
Upon further consults with chatGPT i tried to refresh the displayport connection
#!/bin/bash
xrandr --output DP-0 --off
sleep 2
xrandr --output DP-0 --auto
Which worked (displayport now shows 4 lanes), so I at least got a usable workaround. What do you think caused the original issue?
Hi,
Please get a NV devkit and connect same monitor to it.
I can say we need to check what is default behavior or NV devkit with this monitor first.
I unfortunately do not posses a devkit bard that this could be tested with.