Hi everyone.
I have been working with the Jetson Nano for 2 months now and i always had a FullHD 1080p Signal on my Monitor. But when i turned the Nano on today, it started with a resolution of 720x576. A couple minutes later 1280x720 was also available. I tried with 3 different HDMI Cabels and also a Displayport Cable as well as 3 different FullHD-Screen but i can’t get 1080p. I also flashed a new MicroSD-Card with the latest Jetpack version, but this didn’t help either.
Is there a way i can activcate 1080p Output again or might this be a hardware problem?
Best regards
Daniel
As you’ve tried various cables and displays, it looks reasonable to think the issue is in Nano.
Be aware that EDID reading is done through I2C, so you may power off and remove any I2C connected device, including CSI/MIPI/HDMI cameras or others, then power on and retry.
If this doesn’t work out, you may investigate. You may find the provided EDID from /sys:
sudo find /sys -name edid
You may post the read EDID from these nodes here or paste to edidreader for details.
You would also want to know what the NVIDIA X server thinks about available modes.
As root, you would edit /etc/X11/xorg.conf” and in Section Device enable:Option "ModeDebug". Upon reboot, have a look to /var/log/Xorg.0.log and you’ll find what it thinks about your display modes.
Thanks for the answer.
I have not connected anything via I2C, but last week i attached a CSI Raspberry Camera and suddenly it didn’t show a signal anymore. I thought that the camera is broken but maybe there is a correlation with my current problem.
I attached the edid file.
Daniel
edid.txt (784 Bytes)
This might require someone from NVIDIA commenting, but basically what I see is a valid EDID, and your earlier mentioned 720x576 is an extension mode. The natively supported mode 640x480@60Hz is probably supported, but extension modes are not supported. If a mode is somehow set to a valid mode, and then a monitor is disconnected while a new monitor is then connected, it is possible the mode can end up working…but it would be luck where a native mode of a previous monitor happens to equal an extension mode of another monitor (the mode might be supported, but the setting of that mode must not be via an extension…one monitor with a native mode can be used to set a mode which is the extension to another monitor).
Similarly there may be some default mode which happens to work with a monitor and that monitor uses that mode via extension…this would simply work, but it wouldn’t be due to EDID succeeding.
Do you have another more “standard” monitor you can check to see how it works?
Note what was said earlier by @Honey_Patouceul, about “ModeDebug” in the X config file. If this is in place, then once you’ve booted with a given monitor attached the Xorg log file will verbosely tell you what it thinks about every single mode reported by the monitor. This could confirm accept/reject of particular modes, and the driver itself would tell you why the mode is rejected for reject cases.
Hi,
Please share the boot up log(dmesg) for reference. It sounds like the hardware board is broken. Need to check if we can get more information from the log.
If the board is broken, you can follow RMA process:
Hi.
Thanks for the reply.
Here is the dmesg.dmesg.txt (66.4 KB)
An excerpt of some interesting content (EDID uses i2c protocol):
[ 16.490291] tegradc tegradc.0: unblank
[ 16.501027] edid invalid
...
[ 31.602867] tegra-i2c 7000c700.i2c: i2c transfer timed out addr: 0x50
...
[ 123.937834] tegra-i2c 7000c700.i2c: --- register dump for debugging ----
[ 123.944777] tegra-i2c 7000c700.i2c: I2C_CNFG - 0x22c00
[ 123.950186] tegra-i2c 7000c700.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 123.956956] tegra-i2c 7000c700.i2c: I2C_FIFO_CONTROL - 0x1c
[ 123.962656] tegra-i2c 7000c700.i2c: I2C_FIFO_STATUS - 0x800040
[ 123.968552] tegra-i2c 7000c700.i2c: I2C_INT_MASK - 0x6c
[ 123.973789] tegra-i2c 7000c700.i2c: I2C_INT_STATUS - 0x2
[ 123.979198] tegra-i2c 7000c700.i2c: i2c transfer timed out addr: 0x50
[ 123.986166] tegradc tegradc.0: hdmi: edid read failed
[ 123.991267] tegradc tegradc.0: hdmi: using fallback edid
When you posted the earlier EDID (edid.txt), had any other monitor touched the system prior to recovering the EDID? If i2c fails, then there should not be any “valid” (checksum good) content from the “sudo find /sys -name edid” file content. That file’s content is from the i2c query. Admittedly, it is possible for i2c to work and store content there, and then fail at some future time. I don’t know what the content of that file would be if EDID used a fallback…or if the fallback ever reaches that file.
Hi,
For confirming it is a hardware issue, could you re-flash the system to r32.4.3(Jetpack 4.4 GA) through SDKManager and try again? It shall work fine after a clean re-flash.
Sorry i am not familiar with the SDKManager. I flashed the image directly on the SD Card.
Is it possible to install the SDKManager on the Jetson Nano or do I need a host PC for that?
SDK Manager (sometimes also referred to by its older version, JetPack) must run on an Ubuntu Linux PC (preferably 18.04 release). A Jetson in recovery mode becomes a custom USB device, and the software used in flash understands that custom device. The part which understands this runs on a desktop PC architecture only. The GUI part of this adds the requirement of being Ubuntu.
The different JetPack/SDKM releases can be found here (you might need to go there, login, and go there again):
https://developer.nvidia.com/embedded/jetpack-archive
NOTE: VMs are problematic and rarely handle USB correctly. A VM can be made to work, but it isn’t officially supported and will be a pain to work with.
Ok thanks for the explanation. I will try it.