There are some methods to prove what you think is correct or not…
- If you think “xorg” is the cause of your issue, then we just disable it and see what will get print over the monitor.
In the uart console (or any console), use first command in below and reboot.
sudo systemctl set-default multi-user.target → this will disable GUI desktop
sudo systemctl set-default graphical.target → this will restore it.
-
IIRC, disable GUI desktop will give you the framebuffer console on the screen. You can use the devkit to validate what I am saying too.
-
Depends on whether fb console appears, you can try:
a) If you see the fb console, then run the overlaysink. Overlaysink does not need xorg to run so it shall work.
b) if you don’t even see the fb console, then maybe xorg is not the cause of your issue.
Hi @WayneWWW,
We disabled the GUI and now have a fb console on bootup. However, the resolution is wrong - it’s 2128x1076 instead of 1920x1080. We always see the nvidia logo at 1920x1080, then the kernel framebuffer at 2128x1076.
We were able to run the nvoverlaysink and see the video test pattern.
I attached the result of checking the modes and EDID. It looks like the kernel believes it’s outputting 1920x1080. I have no idea how to parse that EDID data. I will enable the extra X debug info and post that soon.
Hi,
How do you tell you resolution is 2128x1076?
That is what the monitor reports it is receiving. We tried a different monitor and it would not display that resolution so we could only see the nvidia logo but no kernel messages
Hi
Sorry that I am not sure about what you said here.
We tried a different monitor and it would not display that resolution
What is “it” in this comment? Jetson NX? or the specific monitor ? And are you saying that your jetson NX tries to output 2128x1076 to every 1080p monitor?
With the monitor we are currently using, the monitor reports 1920x1080 when the nvidia logo is displayed and 2128x1076 when the kernel messages/console are displayed. With the other monitor, the monitor displayed the nvidia logo but that’s it, no kernel messages.
We re-enabled X and added the ModeDebug option. Log attached.
xorg.verbose.txt (230.9 KB)
Also, what would you see if you use devkit + this monitor? Will it also tell you it is output 2128x1076?
Hi @WayneWWW,
In the monitor’s menu there is an option to display the current resolution on screen. That’s what we’ve been using.
Moving the som to a devkit connected to the same monitor shows 1920x1080 for everything, the 2128x1076 never shows up.
I will get you the clock summary soon.
Please also share the clock summary when you use same monitor but with devkit.
Also, I think it is kind obvious that this issue may not be a software problem because same software gives out different results and the variable here is just the carrier board itself… you moved SOM from board A to B without flashing the board and the result is changed. I think it is obvious that the board may have something wrong.
Xorg has been disabled, so what you guess is not the cause of it.
You can do any kind of comparison between devkit and your board. For example, compare the edid, the xorg log, the dmesg. Check if any of them differs when using same monitor.
After checking the all of them, if there is nothing wrong, we can only ask you to provide schematic.
Hi @WayneWWW,
Here is the clock summary using the devkit and the custom carrier. The summaryNoMonitor-* files were collected after a cold boot with no monitor plugged in. The summaryWithMonitor-* files were collected after hotplugging the monitor.
I am still working on trying to get you schematics, but I don’t know yet whether I will be able to. Looks like I can get a video of the screen during bootup if that is still useful.
summaryNoMonitor-custom.txt (34.4 KB)
summaryNoMonitor-devkit.txt (34.3 KB)
summaryWithMonitor-custom.txt (34.3 KB)
summaryWithMonitor-devkit.txt (34.3 KB)
Hi,
Just want to double confirm. Is this clock tree dumped with the “2128x1076” monitor connected scenario?
Also, what can you see on the monitor so far? It sounds like you can see fb console in one monitor, overlaysink in another one monitor and totally blanked in the rest of monitors.
Could you make a summary of all these? For example, share the brand of monitor and what did you see over it.
These clock summaries were taken with X enabled. I’ll get you clock summaries with X disabled shortly.
I think I misspoke about the other monitor above. We see nothing at all from that monitor, not even the logo.
Monitor 1: we see nothing at all, ever.
Monitor 2: we see the cboot logo at 1920x1080, then framebuffer at 2128x1076. We can display a test pattern over the framebuffer using nvoverlaysink. If we enable X, then the monitor reports no signal when we should see the gdm. Nothing will restore the signal except a reboot (manual unblanking doesn’t work).
If we switch to the devkit, everything is fine, framebuffer is 1920x1080 and starting X doesn’t kill the display signal.
Please also take the clock when using fb console. I would like to check if it is really output the pclk for 2128 x1076.
And could you paste your edid in text file so thay I can copy it and check the content?
Hi,
Do you always see such log on your custom board when you switch to fbconsole?
av@av-rmb3:~$ [ 347.400285] edid invalid
[ 347.510631] tegra-i2c 3190000.i2c: no acknowledge from address 0x50
[ 347.543347] tegra-i2c 3190000.i2c: no acknowledge from address 0x50
[ 347.555979] tegra-i2c 3190000.i2c: no acknowledge from address 0x50
[ 347.564767] tegra-i2c 3190000.i2c: no acknowledge from address 0x50
I think we only see that on hotplug. But then it looks like it retries and gets a good edid. My thought was that it tried to negotiate edid immediately before the pins were fully seated and failed, and then retried and succeeded. Does that sound right to you? What’s at address 0x50?
Generally, edid will be fused on the i2c bus with slave address 0x50. This info could be found over the Internet.
Are you sure your D2 and D0 are correctly connected?
