The above gives useful information, but more questions follow. Some questions may differ depending on your host’s distribution, e.g., I’m using Fedora, many people here use Ubuntu. Some of this may be more than you are interested in, but serial ports are important enough it may be worth pointing this stuff out. The whole topic of whether flash worked because of video issues makes it worth iterating more about monitors as well.
Serial Console “Stuff”
Looks like the host requires CONFIG_USB_SERIAL_PL2303 in kernel config to use your particular model of serial UART. Since you used the serial UART to read another device you can infer that this driver must be in place and functioning correctly. It’s up to hotplug layers and udev to make it all work together (most of what follows is because of this). Because the driver is a module on your system verified that the particular non-FTDI driver is correctly loaded from the lsmod line:
usbserial 53248 1 pl2303
On the host, what appends to dmesg output when the USB serial UART is plugged in? This could give information about USB port and driver handling. E.g., check “dmesg | tail -n 10” while the serial UART is not plugged in; check “dmesg | tail -n 20” after the USB device is plugged in. Paste the new addition to dmesg here. Even though your USB device works on something else the identifying tty can change so I’m hoping dmesg can help add confidence that the correct tty device is being used at this particular time (changing any device plugin or rebooting can change the ttyUSB).
On the host, does any file get added to “ls /dev/tty*” if you compare the tty list before and after plugging in this serial UART? A device which appears after plugging in the serial UART would be guaranteed as the correct device…but as mentioned above the device can change each time USB has any other change so this file should be used right after plugging in the cable (without adding or removing anything on USB). If no file appears, then it is possible the device special file is static and not added by the module, but this is uncommon. A dynamically appearing device special file is a “smoking gun” evidence that this is the right file at this moment in time.
When you open minicom or gtkterm or any serial terminal program for using the serial UART do you use “sudo” (if not then likely only members of group dialout could access the device…use sudo to be certain)? I personally prefer gtkterm. Note that udev can assign permissions differently from one device to the next which means similar operations which succeeded before may fail if some udev conditional rule kicks in. sudo should always get around that.
A really simple test to substitute for an oscilloscope is to run “sudo strings /dev/ttyUSBwhateverNameItIs”, and then turn on the power to the Jetson (test this on something known to work). Even if the serial port settings are wrong you should at least see some sort of garbage random output. If the serial port settings are correct you will get a literal read-only serial console text feed showing you what is happening play-by-play. If you get such output from another device, and then unplug the DB-9 connector only (don’t touch the USB plugin at the host side), and reconnect to the Jetson, then you have a live stream of bytes and if nothing shows up probably the Jetson itself has a problem…if something does show up, then it is just a matter of getting console access in the Jetson. There will of course only be text if something on the Jetson is actively sending characters to the console (e.g., boot messages…this is why you’d run strings on the port while boot is going on…after boot is complete you won’t get anything). The important point here is that a serial console program can simply be blank if settings are wrong…raw output via strings will work even if serial port settings are wrong…it’s a good indicator.
About the Monitor
The fact that another computer reads the EDID proves the cable and monitor make this data available to the Jetson. This does not guarantee modes are compatible, but it eliminates a lot of outright failures and means automatic configuration is possible. Even if automatic configuration did not work there would still be a possibility that the default mode of the Jetson could be used on this monitor.
That said, the monitor in question does not support newer widescreen formats. I have a similar older monitor which is physically widescreen, but does not make available modern formats like 1080p (any monitor with 1080p probably “just works”). Many of the modes in these older monitors are not available without great effort. During boot monitors such as these may not have output from initial boot…mine does not and I get a brief note from the monitor that scan mode is too fast. Later in the boot when it reaches graphical stage a compatible mode is reached (GUI stage default mode differs from console default mode…compatibility can be missing in both or working in just one…GUI and console modes should be treated as separate issues). At the moment you add power to the Jetson, and for about 60 seconds after, does your monitor give any kind of note that perhaps there was a signal for at least a moment? Perhaps it is like my monitor and complains for about only a second or so that the mode is incompatible and then it shuts off all display of anything but blank. The carrier signal light stays off because it couldn’t lock on to that scan rate. That indication is easily missed because it is so very short. Should there be even a brief moment of complaint about scanning too fast you will know the issue is one of video mode setup…that “scan too fast” complaint could occur at either the moment the text mode is started or at the moment the GUI is started.