Hi all,
I have an issue.
I guess it is the same as in the thread :
But :
1- i cant figure it out because i use a Astro Carrier Board and cant display the serial console…
2- i cant test the patch because i dont know where to find the mode.c file.
Could you help find a way to boot with HDMI in ?
thx
I’m not familiar with the Astro carrier board. Does it have ethernet? If so, then I’d check the router to see if there was a DHCP request (which would mean the system works, but video is not configured). Also, is the monitor using a native HDMI cable, or is there a conversion between cable types? Is this a 4k monitor, or something more standard?
I have the same issue using ubuntu 16.04 on VM-Ware on a mac as host.
Jetpack 3.1 was flashed successfully.
Case 1: hdmi plugged in → NOT booting
Case 2: hdmi plugged off, wait for 5-10s, plug hdmi in → booting
This is not what I expect to be normal behaviour.
Any fixes for that?
Do you have ethernet access (can you log in via ssh), or serial console access? Debugging requires some form of access.
same issue…
case 1: with HDMI connected, doesn’t boot
case 2: disconnect HDMI, power on, wait…then plug-in HDMI…boots
also, 1/2 the time the USB HUB doesn’t work - sometimes it works. Do you guys bother to test it before shipping?
So I suppose just log in after it is booted and has the HDMI working with late plug-in. Post a copy of “dmesg” (attach it as dmsg.txt or paste it in the “code block” icon that looks like “</>” in the “reply” edit area title bar) and “/var/log/Xorg.0.log”. In the case of Xorg.0.log, first add this to “/etc/X11/xorg.conf” within the Device Section (reboot with this in place before checking the log file):
Option "ModeDebug"
Also, what is the output from:
sudo -s
<b>cat `find /sys -name edid`</b>
exit
I am assuming when you mention VMware that you mean you flashed with VMware. If the flash succeeds this shouldn’t matter, but it can be quite difficult to get flash to work correctly from a VM. It might be worth looking at a log from a new flash if the other steps don’t show anything.
@keith_schaub
Exactly the same. I have a USB Hub connected with a LED.
As far as i have investigated, it seems that the board is not booting, waiting for some HDMI info…
I think that, because the USB hun is not enlighted when this occurs.
That means that the booting process is blocked before.
Another point that makes me believe that is that if i boot without any HDMI, eveyrthing goes fine.
And then i can plug my HDMI back.
Actually, and i would like to know if this is the same for you, the board boots… but it takes more than 4 minutes. I have made several tests, sometimes it boots normaly (arounf 40sec) but 99 times on 100, it takes more thant 4 minutes.
I am installing the product at a client… It is beginning to become a bit embarrassing.
For information, i am using Astro carrier from connectech.
I have tried to have a debug serial console with FTDI but it doesnt seem to work.
So i have been shipped a RS232 cable. supposed to be better for serial debug on this carrier.
Is there a way to reduce the timer that cause this problem ?
I am pretty sure this is some kind of timer that breaks around 4 minutes.
François
Here is the dmesg.txt
dmesg.txt (66.4 KB)
and here is the xorg.log
Xorg.0.log (137 KB)
The dmesg does not show anything significant (at least nothing I could spot).
The Xorg.0.log shows many allowed modes, but also shows a lot of rejected modes (this is probably normal). To summarize, here are the modes which are valid:
[ 18.762] (II) NVIDIA(GPU-0): --- Modes in ModePool for GLE LCD MONITOR (DFP-0) ---
[ 18.762] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 800 x 600 @ 60.3 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.762] (II) NVIDIA(GPU-0): "1024x768" : 1024 x 768 @ 60.0 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.762] (II) NVIDIA(GPU-0): "1024x768_60" : 1024 x 768 @ 60.0 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.762] (II) NVIDIA(GPU-0): "800x600" : 800 x 600 @ 60.3 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_60" : 800 x 600 @ 60.3 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_75" : 800 x 600 @ 75.0 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_72" : 800 x 600 @ 72.2 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_60_0" : 800 x 600 @ 60.3 Hz (from: NVIDIA Predefined, EDID, Detailed)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_60_1" : 800 x 600 @ 60.3 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "800x600_56" : 800 x 600 @ 56.3 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "720x400" : 720 x 400 @ 70.0 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "720x400_70" : 720 x 400 @ 70.0 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "640x480" : 640 x 480 @ 75.0 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "640x480_75" : 640 x 480 @ 75.0 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "640x480_73" : 640 x 480 @ 72.8 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): "640x480_60" : 640 x 480 @ 59.9 Hz (from: NVIDIA Predefined, EDID, CEA)
[ 18.763] (II) NVIDIA(GPU-0): "640x480_60_0" : 640 x 480 @ 59.9 Hz (from: NVIDIA Predefined)
[ 18.763] (II) NVIDIA(GPU-0): --- End of ModePool for GLE LCD MONITOR (DFP-0): ---
Later on it shows this as actual mode picked:
Setting mode "HDMI-0: nvidia-auto-select <b>@800x600</b> +0+0 {ViewPortIn=800x600, ViewPortOut=800x600+0+0}"
There is nothing obvious there, though I suppose something in a console mode prior to reaching graphical mode could have tried to use a different setting…had this been the case there may have been a failure unless the hot plug mechanism detects the monitor being plugged in again after reaching graphical mode. Nothing particularly obvious suggests this, but it is a possibility.
Earlier I had suggested this command…does this show anything? It would be good to be able to check the checksum:
sudo -s
cat `find /sys -name edid`
exit
Incidentally, logs for Xorg are rotated each boot. So the current boot is “/var/log/Xorg.0.log”, and the prior boot is “/var/log/Xorg.0.log.old”. Perhaps if you boot with the monitor connected such that it does not work, and then reboot, maybe the Xorg.0.log.old would show some information the “working” log does not show (just boot such that the connector is always there and it fails, then reboot, then post the Xorg.0.log.old).
You may find “sysrq” magic keys to be of use (not a joke! though it does sound magical). With a keyboard directly connected to the Jetson there are basically some key combinations useful for triggering some debugging actions, one of which is sync of file system, remounting it read-only, and then forcing a reboot. If your system seems unusable because of a black screen, then you could use this to detect whether the system is actually up and running, and then to force the reboot so that you can see the logs (the “sysrq” key is also the PrtScn key if the right buttons are used):
# sync:
alt+sysrq+s
# remount disks read-only:
alt+sysrq+u
# force immediate reboot:
alt+sysrq+b
See if you can get logs from a failed boot which show something different…those logs above only show success. Don’t forget to get the edid file content so we can see if the checksum is valid.
Hi,
the sysrq is not working because keyboard, as all the other USB devices, is not powered.
it is like if nothing was powered, waiting for HDMI to release something.
strange.
I wanted to ouput the files so i made the manipulation but it didnt boot… i waited for about 10minutes. so i reboot again and after 4 minutes it was ok.
here you will find the dmesg & xorg.log files with and without cable plugged.
(unPlugged means HDMI unplugged & then plugged in 5 secs after powering up, and Plugged means, HDMI plugged in a startup ans the wait for 4/5 minutes for the system to switch on)
For the edid :
00 ff ff ff ff ff ff 00 1d 85 bf 01 01 00 50 63
0c 1a 01 04 b3 30 1b 78 fc 35 85 a6 56 48 9a 24
12 50 54 af c0 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80
14 00 dd 0c 11 00 00 1e 00 00 00 fd 00 38 4b 1e
3c 15 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c
43 44 20 4d 4f 4e 49 54 4f 52 0a 20 00 00 00 10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ef
02 03 14 72 41 01 23 09 ff 07 83 01 00 00 65 03
0c 00 10 00 64 19 00 40 41 00 26 30 18 88 36 00
dd 0c 11 00 00 18 00 00 00 10 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8d
Thx
François
forNvidiaTalks.tar.gz (76.5 KB)
by the way, xorg.log begins @ 19.something.
Is it normal ?
how can i have the “before 19.something” logs ?
Thanks
If anything is attached to the serial console it could be causing boot to halt thinking there is keyboard input. I have no idea what the Astro carrier board has in the way of serial console interface. I would expect magic sysrq keys to work even under circumstances where much of the system has crashed and burned…the lack of ability to use those keys tends to somewhat strengthen the case of U-Boot halting and not getting to the point of even loading the Linux kernel. Is there anything you can say about serial console support on this board and what you might have connected which touches serial console?
EDID is valid (checksum passes). It should be possible for automatic configuration to work. We already know there are times when it does work…the question is why the monitor seems to require being unplugged during boot.
About logs…
xorg.log.1.plugged: Nothing obvious, seems to be ok.
xorg.log.1.unPlugged: Shows GLE LCD Monitor attached. This log probably generated while the monitor was connected. Appears to be a normal X session without notable error.
dmesg.plugged: This log starts once the Linux kernel is running. Nothing sticks out as significant, this seems like a normal boot.
dmesg.unPlugged: This log also seems normal, including USB (I mention this because of the keyboard you said was unable to do the magic sysrq).
xorg.log.2.unPlugged: This was generated with the monitor connected and seems normal.
xorg.log.2.plugged: No content at all. This actually says something because it means that systemd got to the point where it attempted to start X, but there was complete lockup or other failure before X could do anything more than to open the log file. Basically, X attempted to start and had near instant death.
Can you verify that xorg.log.2.plugged was truly empty and it wasn’t a side effect of creating the tar file of logs?
Hi François,
I will look into this for you. Can you please answer the following questions:
What resolution of monitor are you using?
Are you using any adapters/converters?
Can you confirm you are using a TX2 with L4T 28.1?
Do you have our BSP installed (Latest revision is CTI-L4T-V108)
Please feel free to contact us at support@connecttech.com as well.
Parker Newman
I have recreated the issue here and have created a fix for it.
The issue is some monitors will advertise incompatible modes that wont work with the TX2/TX1. The HDMI driver on boot up checks for these compatibility issues, but does not apply any fixes to make the mode compatible. This caused the system to hang.
On boot, the driver also only ever used the first mode advertised by the monitor, this if fine if Mode 0 is compatible (after the fix-ups) with the TX2/TX1 but if it isn’t it will still hang. I also modified it to find the first compatible mode and use that on boot to avoid this issue.
The hotplug detect for HDMI already does this filtering so that is why the monitor would work if plugged in after boot.
I will be adding this patch to our next CTI-L4T releases and will notify Nvidia to get it fixed in the next L4T release as well.
Our new BSP should be on our website either late today or early tomorrow.
Great !
I just see that my later answer is not posted…
I must have done something wrong.
I managed to have something working with another cable / another screen.
I think for this one i will leave it that way.
For the next one, i will install with new BSP.
Thank you
For the monitor issue,
I hope this patch would work. We are working on total solution for it
diff --git a/drivers/video/tegra/fb.c b/drivers/video/tegra/fb.c
index b2bf85a..75839a7 100644
--- a/drivers/video/tegra/fb.c
+++ b/drivers/video/tegra/fb.c
@@ -811,8 +811,14 @@
tegra_dc_to_fb_videomode(&fb_mode, &dc->cached_mode);
dc->use_cached_mode = false;
} else {
- memcpy(&fb_mode, &specs->modedb[0],
- sizeof(struct fb_videomode));
+ for (i = 0; i < specs->modedb_len; i++) {
+ if ((int)specs->modedb[i].vmode & FB_VMODE_IS_CEA) {
+ memcpy(&fb_mode, &specs->modedb[i],
+ sizeof(struct fb_videomode));
+ break;
+ }
+ }
+
}
event.info = fb_info->info;
Wayne,
I did not have any luck using your patch, the system still doesn’t boot.
I have attached my patch which does fix the issue on TX1 and TX2 in L4T 28.1.
hdmi-cti-patch.txt (2.18 KB)
Not to hijack the thread, just curious which monitors you guys are using during bench development with Jetson? Does anyone is using TX2 connected to 4K UHD monitor/TV? I see that it has HDMI 2.0, does 4K @60p work?
-albertr
Hi Albertr,
We use a variety of monitors here. Normally I use either a 1080p@60Hz or 4K@60Hz, both resolutions work fine on our the Connect Tech carrier boards.
With the above fix I was also able to use 1600x900 and 1280x720 monitors that previously did not work.