I was able to re-flash the jetson board and boot up with a GUI properly.
However after shutting down and powering on, the power light is on but I cannot see anything on the monitor.
I think the board still on Force Recovery Mode, any ideas on how to disable the recovery mode?
Odds are high that the board is working fine, but video configuration is not working with your monitor.
By far the best way to see what goes on is a serial console. See this if you are interested in setting up serial console:
http://elinux.org/Jetson/TX1_Serial_Console
Next, if networked, try ping…see if that shows. Better yet, see if you can use ssh to log in.
If you can get in via serial console or ssh, what is the output of:
sudo cat /sys/kernel/debug/tegradc.1/edid
Btw, if you are in recovery mode and the micro-B USB cable (which comes with the Jetson) is connected to your host, then the host will find the jetson via this command:
lsusb -d 0955:7721
Ok, I was able to setup a serial console. I started the Jetson board and it boots up to the message below. Any idea why is that?
Thanks.
...
[ 2.017778] tsec tsec: initialized
[ 2.020390] tsec tsecb: initialized
[ 2.024595] nvdec nvdec: initialized
[ 2.029052] falcon vic03: initialized
[ 2.032053] falcon msenc: initialized
[ 2.035478] falcon nvjpg: initialized
[ 2.038846] tegradc tegradc.1: Display dc.54240000 registered with id=0
[ 2.044629] of_dc_parse_platform_data: DC OR node is connected to /host1x/sor1
[ 2.051947] display board info: id 0x0, fab 0x0
[ 2.056950] display board info: id 0x0, fab 0x0
[ 2.061189] invalid panel compatible
[ 2.064351] parse_tmds_config: No tmds-config node
[ 2.069214] of_dc_parse_platform_data: could not find vrr-settings node
[ 2.075717] of_dc_parse_platform_data: nvidia,hdmi-vrr-caps not present
[ 2.082383] of_dc_parse_platform_data: could not find SD settings node
[ 2.088788] of_dc_parse_platform_data: could not find cmu node
[ 2.094605] of_dc_parse_platform_data: could not find cmu node for adobeRGB
[ 2.101561] tegradc tegradc.1: DT parsed successfully
[ 2.107557] display board info: id 0x0, fab 0x0
[ 2.111660] gpio wake53 for gpio=225
[ 2.127892] V_REF_TO_SYNC >= 1; H_REF_TO_SYNC < 0
[ 2.130620] tegradc tegradc.1: Display timing doesn't meet restrictions.
[ 2.137897] tegradc tegradc.1: probed
It’s failing to find information it wants on the display…looks like whatever it sees is outside the ability of the display controller (or perhaps it has no timing information and has a silly message making it sound like it knows timing and doesn’t like the timing).
Is the monitor HDMI? Are there any adapters involved? Note that anything using the old 15-pin VGA D-sub connectors literally cut the EDID wire used for automatic monitor query.
The monitor is not HDMI. I’m using a DVI to HDMI cable for connecting the Jetson board.
That was working before installing the JetPack, any reason why now is not?
If your DVI is DVI-A, then the digital EDID channel is not supported. This would be the same as older VGA using a newer connector.
Do you have this file, and if so, what is the content:
cat /sys/kernel/debug/tegradc.1/edid
The behavior of video when no monitor responds with details of how to set up for that monitor implies there is a fallback mode. I suspect it worked before because fallback mode defaulted to something the monitor has.
It is DVI-D. I disconnected the monitor and got access to the console.
However, since the board is not connected to the internet, I’m getting the following message constantly scrolling.
[ 1146.421105] rc.local[1296]: RTNETLINK answers: Network is unreachable
[ 1147.448988] rc.local[1296]: RTNETLINK answers: Network is unreachable
[ 1148.491540] rc.local[1296]: RTNETLINK answers: Network is unreachable
[ 1149.537131] rc.local[1296]: RTNETLINK answers: Network is unreachable
[ 1150.575503] rc.local[1296]: RTNETLINK answers: Network is unreachable
I’m trying to sudo to access the edid file, but that message is preventing me to enter the right credentials.
DVI-D does provide analog too, so it may still be that the EDID line is not used.
Is the RTNETLINK message flooding serial console? You may be able to write down the command on your host in an editor, then copy and paste the command to the serial console program:
sudo cat /sys/kernel/debug/tegradc.1/edid
# You know it'll ask for pass "ubuntu", so then mouse copy and paste "ubuntu".
# Similar may be done with scp
sudo scp /sys/kernel/debug/tegradc.1/edid name@host:/tmp
# Blindly mouse copy and paste the password.
Is networking completely inaccessible? If at least partially working it might be possible to just use sftp or scp, but Ubuntu’s use of sudo without true root access could make that difficult. For the boards I work on I always set up with ssh keys to both root and ubuntu (I temporarily unlock root account while I add keys, then lock root back…as a result I can ssh/scp/sftp to root but password is required for any other access just like standard Ubuntu).
When running the cat command above I get: No EDID.
You are correct it is not set.
Some adapters between DVI and HDMI provide EDID pass through, others do not. You may find that if the monitor supports DVI-D, then a different adapter will function. The corollary though is that the DVI-to-HDMI adapter supports EDID, but the monitor itself is just DVI-A…in which case nothing could be done to get EDID. If you have an exact monitor specification, then finding out if the monitor supports EDID would be possible through online searches.
Interesting enough, if I boot up the board without the HDMI cable plugged in, wait for the ubuntu user to login (from the console), and then connect the HDMI cable, then I have GUI access to the board.
But if I start the board with the HDMI cable connected then I have the issue we’ve been discussing.
I guess I should use a more “modern” monitor but for now seems to work.
Sometimes I wonder if monitors themselves try to detect a signal, and upon fail, fall back to something different than if they detect the signal in a working mode right from the start. The Jetson may have different default modes for text and GUI depending on which release of L4T is used…the monitor itself seems more likely to find a fallback mode if something out of range was not found at the start (if the monitor thinks the signal is out of range, then the monitor may have no reason to continue searching until the signal is lost and restarted…a poor man’s hotplug).