Nano 2GB + VGA adapter

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
,
1

Hi,
I’m trying to start using the Jetson Nano 2GB but my monitors do not have HDMI, so I’m using an HDMI to VGA adapter (no EDID).
I’ve been digging about how to convince the Nano to enable display though, so far, no luck. HDMI shows disconnected.
Is there a known way to force HDMI configuration ?
TIA!

2

@tron1,

I have read a couple of articles recently that stated that the Nano 4GB will not work with HDMI to VGA adapters and it is probably the same with the 2GB. HDMI monitors are pretty cheap now and very few SBCs have VGA outputs unless they are very old.
Regards,
TCIII

3

Thanks,
I’ve already a pair of displays that support both DVID and DP but not HDMI, and I’m not adding more displays just for this…
I’ve seen many articles that say how to fiddle with EDID data, bnd managed to build the kernel from sources, so unless the hardware does not allow it, I’m looking forward to use my VGA converter :)

4

I have not personally done this, but you might be able to change the default fallback mode, and if lucky, then the VGA monitor would work with that mode:
https://forums.developer.nvidia.com/t/why-and-how-cboot-select-different-resolution-with-different-display-monitor/148067/4

What it comes down to is that the driver will only accept modes via EDID, and there are some restrictions on that as well (such as no interlaced modes and no extension modes). If a suitable EDID is not found, then it will use a fallback mode, and you can possibly edit the kernel to use a fallback mode which is convenient to you.

5

Thanks,
I’m lost here: the thread you linked too seems to be related to a resolution selection process, from the resolutions posted by the EDID data. But in my case, there is no such data.
If there is a fallback mode, then anything might work but the HDMI port stays in “disconnected”. The monitor I have is reasonably flexible as to resolutions and timings, but I have not been able to kick the port “on” so to say.

6

There is a predefined list of modes in the kernel code, and if EDID fails, then one of those modes is picked to run “blind”. You would be editing the fallback mode used when no EDID is found. The trick is that you’d need to have it pick a fallback mode which works with your monitor and is simultaneously available as one of the predefined “acceptable” modes.

7

Alright then, I’ll search for that code. Happen to know where is it ? :)

8

Within the kernel source “drivers/video/tegra/dc/”. Possible files you might be interested in:

  • dp.c
  • mode.c
  • hdmi2.0.c

Since I have not actually changed the fallback mode used when EDID is missing I couldn’t say what the exact file is to edit (someone else here probably does know). Some functions to check:

  • tegra_dp_mode_filter
  • check_nvdisp_mode_timings
  • check_...hardware specific name...mode_timings
9

I managed to enable fallback mode, but the board still sees hdmi as disconnected (and reports NO EDID).
Using default (as provided) 720p EDID, hoped it would pass the filter of “acceptable” modes, but either it does not, or I’m missing something else.

I’m open to advise :) Thanks.

10

If there is no EDID, then the i2c query on the HDMI cable failed. VGA adapters tend to not even have that wire (the DDC wire), and so there is no possibility of recognizing such an adapter unless it is active and inserts an EDID which you have manually programmed.

11

Well, I’m still looking for a software solution, since I’m using the same hdmi → VGA adapter with other systems and it has no issues. If the software is in control of the hardware, that is.

In trying to understand the control flow of the discovery, I run into another issue: an assertion failure at initial boot :( This after puting a new “kernel” in the SD card to debug “invalid edid” messages. Now I’m stuck :(

12

Most video drivers accept EDID to auto configure, but also accept manually configured values. The Jetson video driver only accepts EDID. EDID itself has a checksum, and if the EDID is not passing the checksum, then this is the same as not having an EDID. Fallback modes are what you’ll have to use, but if you have some sort of passing of an EDID, then it must have a valid checksum.

Did your VGA to HDMI adapter have a step to program the EDID?

13

I don’t think my cable replies with any EDID. No, I have not programmed it.
But I did program fallback mode and it’s not being used either. I hoped that on any error, the fallback would be applie. That seems not to be the case.

14

If you’ve edited to use a default fallback mode through kernel edits, then the fallback would itself need a valid checksum. In the case of editing kernel code for a different fallback there might be something you missed if checksum is not working correctly.

15

I’ve just enabled fallback, the kernel code has a default 720 EDID in place which I assume has a valid checksum! As I said before, I also assume it is valid for the list of supported “filtered” EDIDs.

16

I cannot answer this, but if you post your exact kernel source edits so the issue can be reproduced, then I suspect the question can be answered. Keep in mind that EDID is used to pick modes, but a fallback mode is actually separate from the method of picking the mode. Perhaps the i2c used for query of EDID also needs an edit. Perhaps the message about checksum can simply be ignored. Hard to say without more information. It is the EDID which has a checksum, not the mode.

17

My only source edit is referred elsewhere, in edid.c change use_fallback = false to true. That was supposed to fix things , but it has not.

18

Someone else will need to answer why use_fallback = false comes up with an EDID checksum error. Perhaps there is a second edit required in conjunction with this (related to the i2c).

19

I don’t see where you got the checksum error thingy. I just have a VGA adapter that I suspect does not provide EDID, and I’m trying to have HDMI output with some default resolution…

20

I should have just phrased “invalid” instead of “checksum”, but earlier (post #10) it looks like that whatever fallback might have been used that something was rejected as an invalid edid. If for some reason the system thinks it is using an EDID, then anything failing any part of the EDID sanity checks will cause the mode to be rejected.

I do not know what else might be required for the case of (A) you have a non-EDID monitor, with (B) a default fallback mode which is valid for the monitor. It may be there is some need of a detect pin, but I’d think that even an HDMI-to-VGA adapter would trigger that.

I will suggest posting the log which the video driver itself creates after adding an option to tell the driver to be “verbose” and list every mode checked, accepted, rejected, or enabled. In “/etc/X11/xorg.conf” you will find a Section "Device", and add Option "ModeDebug":

Section "Device"
...
   Option "ModeDebug"
...
EndSection

Then reboot. Upon reaching a graphical stage save a copy of the “/var/log/Xorg.0.log” (in some cases it might be “Xorg.1.log”…either way you could rename it with filename suffix “.txt” and post to the forum). The log will tell us everything the driver sees regarding what hardware is present, and what the driver accepts or rejects, and why.