After installing the driver for e cam 130_cum11335 with the camera connected and restarting the Jetson, the system will not boot and the monitor says no HDMI signal is found. Also, the system will not let us into USB recovery mode. What are our options?
Is this the developer kit, or is it some other carrier board? Basically you should always be able to see the Jetson with lsusb when it is in recovery mode…if this doesn’t work there may be hardware failure. FYI, don’t ever expect to see the Jetson under lsusb from a normal boot…it can happen if it was configured to do so, but it isn’t a valid test of whether the system works or not. Recovery mode is different because it is built in at a very low level.
Quite often though people assume the system didn’t boot even if it is nothing more than video not configuring. Be sure to also check your router to see if an address was requested. In the end a serial console is by far the best thing to have because almost every part of the system can fail and you’ll still get some output for debugging.
We are currently using the Jetson TX2 Dev-kit board. We are students working with this board for the first time, so forgive us if our questions are a little silly or incomplete. We are trying to make sense of why we are having this issue. All we did was restart the TX2 after installing the driver. After that, it went through the normal boot-up process then it told us that there was no HDMI input signal. We have no way of interacting with it after that. We tried restarting it, as well as re-flashing it, but nothing works. Is there a way to do a factory reset option? How would we tell if it is a hardware issue? Thank you for your expedient response.
It seems likely it was working, but the video mode was not accepted.
It is ok to flash it, you probably want a newer version than the software it arrives with. R28.2 is highly advisable, this can be installed either on command line (driver package plus sample rootfs), or via JetPack (which is a front end and can also install extra packages, but has more requirements than command line).
To start with, what kind of display do you have in terms of cables/connectors/adapters? Older VGA (15-pin D-sub) lacks a wire (the DDC wire) used for sending display information (EDID data). The video card queries the monitor, the monitor sends EDID data back, and the video chooses a mode. Only EDID modes are accepted, and only those from a list (a large list…not sure what specific modes are available other than no interlaced). Keep in mind that HDMI is hot plug, so sometimes you can work around issues by either unplugging and replugging the cable, or booting without it and only later connecting the cable. A monitor which fails EDID might still get lucky and support a default mode the video is already in (which means sometimes plugging in a different monitor and then replugging the failing monitor might be a temporary workaround as well).
So far as next steps go it is highly recommended to get a serial console (typically a USB serial UART is used…anything with an FTDI chipset is supported out of the box on any Linux desktop PC). See:
[url]http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/[/url]
You can also try ssh. Your router will see the Jetson request an IP address via DHCP. Whatever your router is (either an appliance or a PC) you’ll want to see if an address was issued. I don’t know about your kernel changes, so it is possible it completely failed to boot. If an address was requested, then you’re in luck…you can ssh in.
Regarding drivers and changing the kernel…if you build a kernel starting with the existing configuration and only add a module for something, then you only need to install that module instead of the whole kernel. If you use a serial console, then you can leave the original kernel and setup in place even if you replace everything, and then choose an alternate boot entry…you wouldn’t need to completely remove what was already in place. It’s a good way to test since if the kernel fails you just pick the original kernel at boot time.
If you don’t have anything on the system you need to keep, then you might as well just flash again with the original kernel. If you do need to save content and avoid erasing things with a flash, then you can clone first…this is a long process and takes a lot of disk space. It sounds like you are ok with just flashing again…I’d recommend just using JetPack3.2 (or the driver package plus sample rootfs for R28.2) and start clean.
Once a new system boots one of the first things you want to do is copy “/proc/config.gz” to your PC for backup. This isn’t a real file in “/proc”, it is a pseudo file which exists only in RAM and is the exact current configuration as what is running (well, other than CONFIG_LOCALVERSION…that’s a different topic regarding where the kernel wants to find its modules). Whenever you build a new kernel start with this config…anything else is a risk. I don’t know what the requirements are for your particular driver…some drivers can be a module, others are only allowed if integrated in the kernel…the two options differ in how to proceed.
Do you have a serial console cable (in this case it is “TTL level” serial USB UART for most people)? Does your router show a DHCP request? If not, are you ok with just flashing (and erasing without saving)? FYI, current R28.2 (JetPack3.2) can be found here (you will probably have to log in to see downloads…go there, log in, and then click the link again to get to actual downloads):
[url]https://developer.nvidia.com/embedded/linux-tegra[/url]
FYI, command line is the most flexible and simplest flash…it has very few requirements. Here is an example of using command line flash:
[url]https://devtalk.nvidia.com/default/topic/1031769/jetson-tx2/unable-install-any-jetpacks-jetson-tx2/post/5249710/#5249710[/url]