Boot problems

Hello everyone,

this problem involves two jetson nano and two sd cards, so to be clear let us name them nano1 and nano2 and sd-card-A and sd-card-B

Nano1 was flashed with
sudo ./flash.sh --no-systemimg -k BMP --image ./bootloader/bmp.blob jetson-nano-qspi-sd mmcblk0p1
with bmp.blob being a 0 byte file.
Nano1 is booting up with sd-card-A and sd-card-B, everything is “normal” in both cases and expected how it should be.

Nano2 was flashed with the same command. After that, it didnt boot up, nothing happened. I attached a serial cable for having the serial console, but on minicom nothing happend, no output. So Nano2 seams like dead, then i tried to reflash the QSPI with
sudo ./flash.sh jetson-nano-qspi mmcblk0p1
Now, i have output with the serial console, and in serial console it seems to boot normally up, but the device with sd-card-A isnt acting as it should, so i have no output on HDMI and i cant ping the device on the configured port.
When I insert sd-card-A in Nano1, it is working normally.
When I insert sd-card-B in Nano1, it is working normally.
When I insert sd-card-B in Nano2, it is working normally.
Only the combination sd-card-A and Nano2 isnt working normally. In serial console, i can login and execute commands, so the device isnt dead, but as mentioned before no HDMI output / no network.

In the attachment the relevant files.

flash-nano2.txt (12.0 KB)
reflash-nano2.txt (13.0 KB)
serial-console-nano1-sd-card-a (22.8 KB)
serial-console-nano2-sd-card-a (20.5 KB)
serial-console-nano2-sd-card-b (20.6 KB)

Are you able to login the device through serial console for that NG case?

If so, could you dump the dmesg?

nano2-sd-card-a-dmesg (55.2 KB)
nano2-sd-card-a-dmesg-reboot (55.1 KB)
nano2-sd-card-b-dmesg (55.9 KB)

Yes, i am able to login, “nano2-sd-card-a-dmesg” is the dmesg of the not-good case. for comparison, i also attached the dmesg of sd-card-b with nano2

interesting thing i also found out: in the not-good case, when i reboot the nano from serial console, i get an HDMI signal, so this is working normal then, but the ethernet is still not working with the configuration as expected like on the other nano.
regarding the HDMI bootup vs reboot: during bootup, the output device is slower than the nano. the output device is ready after the nano, and showing an “no hdmi signal” sign. in the case of sd-card-b, it is just showing for a few seconds, until it is normally displaying the nano output. in the case of sd-card-a, it continues showing “no hdmi signal”
regarding the ethernet i have no further observation why it is just working in nano1. for comparison, here is also the dmesg of nano1 with sd-card-a (ethernet working as expected)
nano1-sd-card-a-dmesg (59.2 KB)

I am not sure if you really share the correct log. I see your nano2-sd-card-a-dmesg log still has eth0 working.

Also, I cannot understand what is your purpose to flash a zerop byte file here. What is the purpose?

You want to disable the bmp logo?

It should be the correct log, eth0 in general is existing, e.g. showing up in ifconfig, but it is not configured with static IP address like it is after bootup in nano1, or like it was in nano2 before flashing. before flashing, sd-card-a as-it-is was working in nano2 without the hdmi and the eth0 problem.

yes, the flashing is just to remove the bmp bootup logo.

Will dhcp work?

For the display issue, I think you can compare the bootloader log on nano A when the NG happened and after reboot.

According to the dmesg, the “slow” you saw from previous case seems due to below log.
This is from the reboot one. You can see that kernel directly inherit the EDID from BL (bootloader). However, this does not happen in your slow case. In slow case, kernel seems does not receive any display info from BL. I guess this is more reasonable because no BMP logo there so display should not initiate in cboot.

1.138490] tegradc tegradc.0: DC initialized, skipping tegra_dc_program_mode.
[ 1.138538] tegradc tegradc.0: hdmi: tmds rate:148351K prod-setting:prod_c_hdmi_75m_150m
[ 1.139117] tegradc tegradc.0: hdmi: get RGB quant from REG programmed by BL.
[ 1.139130] tegradc tegradc.0: hdmi: get YCC quant from REG programmed by BL.

I am not sure if you can still see the “slow” behavior after once reboot. If you still can, please check if the cboot log has anything different.

Also, I feel the log your shared in first comment is different from the case you are sharing now. For example, your previous log has “edid invalid” in both kernel log (though not complete), but the dmesg you just shared didn’t have them.

Please make sure you really use the same environment to dump log. Or just remove “quiet” in extlinux.conf so that uart log will include full dmesg.

Thank you, for next logs i will try it without the quiet flag in extlinux.conf for having better comparable logs.

regarding edid invalid: i think in all logs - no matter if uart or dmesg - that are from the not-good case, edid invalid shows up. In the good case logs (nano1 and nano2-reboot) there is no edid invalid, and also there HDMI output is working.
is there some possibility to force HDMI to initialize although there might me no output device attached / to activate “hotplug” for HDMI? i can reproduce this now, with sd-card-a (lxde) it isnt possible to get a HDMI signal when connected after boot, with sd-card-b (default gnome) it is possible.
regarding ethernet, i think it is an issue that nano1 has a wifi card and nano2 hasnt. as i put sd-card-a first time in nano1, it seems to screw up the ethernet settings, and afterwards in nano1 static IP on wired ethernet is still working, but not on nano2 anymore. /e might be independent from wlan, it seems like it creates new wired connections anyway when inserted in different nanos

so i think it all boils down to “HDMI hotplug”, sorry for all the confusion, it took me hours to get this straight…

Is this issue still related to the nano 1 and nano 2? Your latest comment sounds like this issue is more related to lxde and gnome but not the board.

Just some random thoughts to consider:

  • EDID is provided by the HDMI wire and the source is the monitor itself. DisplayPort also has EDID. Many adapters to other formats do not have EDID. At this point your monitor is no longer “plug-n-play”. A PC would be set up to allow installing information/driver files for that monitor, but a Jetson only works with EDID.
  • An invalid EDID is quite different than “no” EDID. If invalid, then your monitor is attempting to reply to EDID, but something in the monitor or cabling is broken.
1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.