Jetson Nano doesn't boot properly - "Failed to start Load Kernel Modules"

Autonomous Machines Jetson & Embedded Systems Jetson Nano
, ,
1

I’m using a Jetson Nano with custom carrier board from reComputer. Everything was working fine till yesterday. Now my Jetson won’t boot properly.

At start on the HDMI monitor the message “[FAILED] Failed to start load Kernel Modules” is shown and the GUI won’t come up. I can connect to the Jetson using SSH and putty.

The command “uname -r” shows “4.9.299-tegra”. But “/lib/modules” only contains the directory “/4.9.337-tegra”.
As far as I understand this seems to cause the problem.

The problem appeared after I tried to bring the Ubuntu installation up to date (and install pip if it doesn’t exist) by executing:
“sudo apt update”
“sudo apt upgrade”
“sudo apt install python3-pip python-pip”
“sudo reboot”

How can I resolve this error?
I guess renaming the directory “/lib/modules/4.9.337-tegra” to “/lib/modules/4.9.299-tegra” won’t do the trick.

Thanks in advance!

2

Your steps should not have caused this, but it is possible that a package during the update did have something go wrong. You are correct that you need this content:
/lib/modules/4.9.299-tegra/

I don’t know enough to say if there is in fact a 4.9.337-tegra kernel update package. The implication is that such an update started, but did not complete; seeing “uname -r” as 4.9.299-tegra says there was no update to the kernel itself, but seeing the existence of 4.9.337-tegramodules (plus the missing modules for 4.9.299-tegra) implies it was updated…at least in part. Something went wrong with the kernel update.

What do you see from:
ls -ltr /boot

Can you attach file “/var/log/apt/history.log”? If it is zero bytes in size, then instead attach “/var/log/apt/history.log.1.gz”.

Also, what do you see from “head -n 1 /etc/nv_tegra_release”?

Almost forgot, also show the output of:
ls -ltr /var/lib/dpkg/info | tail -n 30

Do you still have JetPack/SDKM installed on your host PC, and did you ever flash with that? If so, then we can at least recover the old kernel using the module content there. Even so, there might be something messed up in the package database now.

3

jetson_ltr_boot.txt.txt (5.1 KB)
history.log (47.9 KB)
jetson_ltr_dpkg_info.txt (2.1 KB)

Thank you for your reply. I attached the output of the command " `ls -ltr /boot" and “ls -ltr /var/lib/dpkg/info | tail -n 30”. Also the history.log file.
The command “head -n 1 /etc/nv_tegra_release” shows:

asimov-jetson@DD-Jetson-1:~$ head -n 1 /etc/nv_tegra_release
#R32 (release), REVISION: 7.4, GCID: 33514132, BOARD: t210ref, EABI: aarch64, DATE: Fri Jun 9 04:25:08 UTC 2023

I did use the Nvidia SDKManager to flash the OS to my Jetson a couple of weeks ago. But if possible I would like to avoid flashing the OS again and losing all my work in the process.

4

Before fixing anything, you should know that you can clone the existing rootfs partition. This can be loopback mounted on your host PC, and you can save things like your home directory and other non-o/s content.

This is a custom carrier board, so I’m thinking the failure occurred during the nvidia-l4t-kernel-dtbs update. It is possible to edit a clone and fix that from the clone, but the odds are not high. The other update which might have caused problems is the efibootmgr (these are actually all related whereby one triggers the dependency for the other).

Since this is a third party carrier board, then usually one has to use the software from the third party for flash. Did you use that content? Do you have the original flash content on the host PC?

If this were a typical eMMC model of Nano (which isn’t actually typical since all such models use a third party carrier board), then a clone from the host PC, at the “Linux_for_Tegra/” directory, would go something like this:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-nano-emmc mmcblk0p1

The host PC would have to have a lot of spare disk space before starting. The clone would produce a “sparse” image (my_backup.img) and a raw image (my_backup.img.raw). The raw image is the size of the entire partition; the sparse image is roughly the size of the actual content within the partition. So if the partition is 16 GB, and the content within it is 5 GB, then this would require at least 21 GB of host space.

I throw away the smaller sparse image. The larger image can be loopback mounted, examined, edited, so on. Either image can be used to flash the Jetson with the right command line arguments and placing the clone as “Linux_for_Tegra/bootloader/system.img” before the flash. I think you might be able to use the previous flash content to restore kernel modules, and then flash it back in place. This does nothing to fix whatever package database failure is now occurring and would have an effect in the future even if it gets things working now.

You could also take the default image, and rsync some of the loopback mounted clone’s content into that image before flashing. There’s actually a couple of variations to that, but it could for example save your home directory and “/usr/local” (or whatever it is you are concerned with keeping0.

Here is the real problem: I suspect the updates were for a regular Jetson dev kit, which is incompatible with the custom third party carrier board. Flash should use that third party content, or at minimum parts of the hardware won’t work. What is the exact carrier board and manufacturer? Where did you get the flash software, and is there some other version available from the manufacturer?

5

I use a reComputerJ101 carrier board from seeed studio. (Purchased from Farnell GmbH from where we receive a lot of electronic components since years.)

There is a tutorial on how to flash the JetPack OS to this carrier board. You can find it here: reComputer J1010 | J101 | Seeed Studio Wiki
In this tutorial using the Nvidia SDKManager is recommended and it is not mentioned to use a customized version of the JetPack OS for this carrier board.

I’m a Windows user and my knowledge/experience working with Linux distributions is limmited. I actually don’t have a real Linux host PC. Which is the reason why I had to use WSL on Windows11 to flash the JetPack OS with the SDKManager in CLI mode according to this: Windows Subsystem for Linux :: NVIDIA SDK Manager Documentation
I don’t know if this could have caused the problem.

Are there any known issues with carrier boards from seeed studio?
On the carrier board was a JetPack preinstalled. But with this version we had performance issues when using a HDMI monitor and the Nvidia OpenGL drivers weren’t installed properly.
So I guess there was a customized version preinstalled. I’m trying to clarify that.

Thank you for mentioning flash.sh. I will have a look at that.

Edit: I forgot: I don’t have or know which JetPack version was preinstalled on the custom carrier board.

6

This is long since it covers a few different topics, and it jumps around, so please bear with this…

Assuming the Nano still boots, what do you see from “lsblk -f”? I’m betting “/dev/mmcblk0p1” (which is eMMC; it could be “/dev/mmcblk1p1” if it is an SD card model, which it is not) is mounted on “/”. I need to verify this is an eMMC model, and that command will answer this.

If you wish to clone (you might not care): Cloning should work regardless of carrier board so long as the device mode USB wiring is present (that’s the micro-OTG USB connector). However, any software used for actual flash likely has to come from Seeed for that particular carrier board/module combination (there are exceptions, and you might have such an exception). Furthermore, if Seeed says to use the NVIDIA SDK Manager, then it implies the firmware and carrier board layout match the dev kit; this simplifies things, but if they are not matches, then this can cause a lot of frustrating problems. Incidentally, adding an SD card slot to the carrier board, with all else being a match to the dev kit, means everything would work except for the SD card until the firmware (device tree) is set up for this.

WSL is very problematic. VMs in general tend to fail USB during a flash since they don’t handle USB correctly unless the user has manually set this up. There is also an issue with “loopback”, which I’ll describe since it might or might not matter. Note that the original WSL (the original WSL, not WSL2) stands no chance at being adjusted for loopback, but WSL2 does (though it probably is quite a learning curve). eMMC models don’t have pre-built o/s partitions, and require loopback to build. Just to emphasize, WSL2 has the ability to modify the kernel, and thus can get loopback, but by default I don’t think it does. Doing so is not trivial.

Each Jetson has a lot of software which is pre-built, and is used during boot. These are all binary images, and flash neither understands what is in that data, nor does it need to understand. There is also the root filesystem, or rootfs (partition label “APP”, it is Linux), which is not normally just a binary image (flash treats it that way, but generating the rootfs/operating system is not just binary data). Some Nanos are “SD card” models, and Linux goes on the SD card, but some are an eMMC model, whereby the solid state memory is on the module itself, and not on an SD card. The two work the same, but have different driver setup and firmware (device trees). When flashing, one has to correctly pick what to flash (for an SD card model or an eMMC model; this is in addition to other modifications if this is a third party carrier board, so it isn’t just third party versus NVIDIA, it is also eMMC versus SD card models).

Assuming your Nano uses NVIDIA’s flash software, which sounds like this is the case, your flash target would be for the eMMC model. This would make everything functional except for the SD card (this is because the SD card is present on the carrier board, and not on the module; NVIDIA’s device tree does not know this). One would either edit the device tree or add a device tree overlay (which is in essence an edit) to make the SD card visible. When visible you could monitor “dmesg --follow” and see log lines as you insert an SD card (assuming the SD card itself is not defective, which happens; it is good to see if the SD works on other computers). Note that an overlay does not require flash. In some cases a device tree edit does not need flash either.

Getting back to loopback, consider that if this were an SD card model (and likely it is not), then you could use a pre-built image. For eMMC, this image is built by the flash software prior to upload to eMMC. This requires loopback, and WSL (the original) cannot do this. WSL2 can only do this if you are able to install a new Linux kernel to it (and perhaps you might also have to configure and build that kernel yourself, I don’t know).

Assuming we can confirm this is an eMMC model, then you can either add the overlay, or else you can flash with a loopback-enabled Ubuntu. The easiest thing you can do is to get the overlay to work. Next to that, installing a dual boot Ubuntu 18.04 would be the easiest (you’d have to partition your existing disk with enough space for Linux, then you pick Linux or Windows at the boot prompt). The most difficult path would be to make sure you have WSL2 (not the original WSL), and get instructions on installing a kernel with loopback capability (followed by correct VM setup for USB, which I can’t help with).

7

Forget virtual machines for flashing Jetson boards. It seems you are using them in a company. Your wasted working hours will certainly exceed the cost for a well-equipped Intel NUC or a similar machine by a huge amount. Penny-pinching on tools is never a good idea.

8

jetson_lsblk.txt (678 Bytes)

I’ve attached the output of “lsblk -f”.

To clarify things:

  1. There is an eMMC. 16 GB in size.
  2. On the board is a SD card slot. I put a 64 GB card into that.
  3. I have WSL2 (sorry for being not specific enough). But I’m not sure it has loopback capability. “ifconfig” in WSL2 shows:

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0"
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 4 bytes 200 (200.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4 bytes 200 (200.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

  1. I used WSL2 to flash the JetPack OS. I used Nvidia instructions for that and the reference for enabeling USB inside WSL2. During flashing there was a step “preparing image”, “building image” or something like that. Only after finishing that the image was flashed to the Jetson. The process succeded without errors.
  2. I had to enable the SD card slot according to instructions from Seeed. J101 Enable SD Card | Seeed Studio Wiki As you mentioned: SD card was not visible and the device overlay had to be changed.
  3. I followed instructions from Seeed to boot the Jetson from the SD card instead of the eMMC. J1010 Boot From SD Card | Seeed Studio Wiki They provide a “copyRootToUSB.sh” file and as far as I understand this is basicly just “sudo rsync -axHAWX --numeric-ids --info=progress2 --exclude=/proc / “$DESTINATION_TARGET”” which copys the OS from the eMMC to the SD card. (Really simplified.)

This is getting more complicated than I thought and I think my primary problem isn’t the faulty boot process. If I understand you correct:

  1. Flashing with WSL2 doesn’t work properly despite the SDK Manager showing no errors. Getting this to work is possible, but time consuming.
  2. Images for eMMC models are not entirely compatible to SD models. Which would mean: Using rsync to copy the content from eMMC to SD (like Seeed suggests) could cause Problems.
  3. According to your first replys: Fixing the boot problem and saving my progress could be possible but is also time consuming.

I’m starting to think for me it would be more practicable to just buy a regular Jetson from Nvidia.

9

Your lsblk -f indicates:

  • This is an eMMC model.
  • The SD card is read and visible (at least while running that lsblk).
  • It is the SD card which is the rootfs.

I did not expect you’d have an eMMC model running the rootfs on SD. My guess is that the update modified the eMMC, yet you are booting from SD, and thus the update was not entirely correct. This is a breakthrough, as it explains more of what is going on.

Incidentally, if you remove the SD card, does it boot? I’m curious because this might answer if it chain loads versus if it goes directly to the SD card. Can you provide a serial console boot log without the SD card?

Can I verify that all of the previous posts with the error are using this SD card?

Now, with it running with the SD card, which is presumably the case of the recent “lsblk -f”, can you do the following:

sudo -s
mount /dev/mmcblk0p1 /mnt
cd /mnt/lib/modules
ls
cd
umount /mnt

If so, what is the output of the ls from that location?

10

I’ve attached the serial console log from a boot without the SD card.
jetson_boot_log.txt (21.2 KB)

The Jetson also doesn’t boot properly without the SD card. On the HHDMI monitor a bash shows the last lines which are also in the serial log. Additionally in the bash it shows:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-4.4#

linuxdev
Can I verify that all of the previous posts with the error are using this SD card?

This is correct. All my previous post are for a boot with the SD card.

linuxdev
Now, with it running with the SD card, which is presumably the case of the recent “lsblk -f”, can you do the following:
…
If so, what is the output of the ls from that location?

After mounting “/dev/mmcblk0p1” the “ls” command shows:

4.9.299-tegra

11

With that new log, I cannot tell exactly what is wrong. However, this does suggest a device tree issue:
[ 1.294151] tegradc tegradc.0: hdmi: edid read failed

Is there an HDMI monitor attached? Is this purely HDMI, without any adapter?

Note that HDMI is a “hot plug” device, meaning it can unplug and replug at any time, and the device (monitor) which is plugged in will report its capabilities. This is done with an i2c protocol, and in order to make a spec query available even when the monitor is turned off, the power to do this is provided by the GPU over the HDMI cable. In the case of a custom carrier board, then probably the power rails must be set up differently via device tree.

The imx219 issues could occur simply by not having that camera, so this isn’t an issue. However, boot should not stop right there.

I am suspicious that the wrong device tree is being used. Since this is an eMMC model, it is likely that the carrier board needs a modified device tree. Maybe the information from reComputer/Seeed is correct and the default device tree is ok, but I wonder.

Tell me about the monitor: Is it purely HDMI? If it is, then I think it is time to flash again, but to double check if Seeed has custom software.

12

The monitor is a DVI one. Conneted to the Jetson with an adapter cabel HDMI to DVI-D Dual.
I’m not sure if the monitor has something to do with the problem. I’m having trouble with this monitor since the beginning. The GUI isn’t displayed properly and I often have to reconnect the monitor after boot to actually see something.
But these problems are pressent since I started working with the Jetson a couple of months ago with the preinstalled OS provided from Seeed and also after flashing a JetPack OS directly from Nvidia.

I connected a HDMI monitor to the Jetson. This doesn’t change the boot process (as far as I can tell). I’ve attached the serial console log from boot with the real HDMI monitor.
jetson_bootlog_HDMI.txt (22.6 KB)

13

In theory, if a DVI-D is adapted to HDMI via the “digital” side (DVI also has analog), then all should be ok on the cable. If it uses analog, then it is still a problem. In the case of analog, there is a dependency on default display settings being compatible, and not having available all valid modes.

I am concerned though about the lost i2c. The HDMI’s DDC wire is i2c, and although this is where I would normally look first, your use of an actual HDMI monitor has still failed. See:

[    1.109885] tegradc tegradc.1: dpd enable lookup fail:-19
[    1.242819] tegradc tegradc.0: hdmi: edid read failed

Just to emphasize, even if the monitor itself is not the problem, there is an i2c problem. For example, power rails for i2c hardware might not be on. This, in turn, is controlled by the device tree. I would expect the imx219 to fail i2c since it is unlikely you have an imx219 camera, but to see all those “arb lost” at 0x50 (in addition to EDID failure) says device tree is the likely cause (that or failed hardware; bad device tree settings are at fault an enormous percentage of the time).

Are you sure that model from reComputer does not have a custom device tree or any particular content from the manufacturer which is applied first before a flash? The earlier mention of either an incorrect kernel, or a failed kernel 4.9.337-tegra install, suggests an update occurred which would have altered both device tree and kernel (the two often go together). An update to a newer kernel which does not understand any customization of the carrier board would result in using the wrong device tree, and would very likely cause similar i2c failures.

14

Actually I had an imx219 camera connected to the csi port. I disconnected the camera now.
I also had other hardware connected to the board.
An USB audio card, a GPIO extension board and a battery pack. The battery pack uses i2c to communicate with the Jetson. The thing is: the battery pack i2c communication has to be enabled and I didn’t do that after I flashed the JetPack. I only tested that with the preinstalled JetPack.

I disconnected nearly every additional hardware. Now only HDMI monitor, keyboard, Mouse, LAN, serial-to-USB converter for serial log (RX, TX, ground) and a Wifi module are conneted to the Jetson wich is powered over the USB-C port. Attached is the serial log from that boot. The problem still remains.
jetson_boot_log_no-peripheral.txt (22.5 KB)

I’ve checked the flashing instructions from reComputer. Customizations to the device tree are not mentioned.
The flashing instructions are basically: Put the device in recovery mode, connect to host machine over USB-C data port and use SDKManager for flashing.
Adjustments to the device tree only need to be done after flashing when using the SD card.

I didn’t follow the flashing instructions from Seeed entirely. Differences are:

  1. Using WLS2 since I have no real Linux host machine. As mentioned earlier.

  2. Using SDKManager in command line mode because I didn’t get the GUI to work in WSL2. But I think this won’t make a real difference concerning the flashing.

  3. I didn’t use the preconfig option but OEM instead. So the user has to input username, password and so on at first boot. Again I thnk this won’t make a difference.

  4. Seeed recommends JetPack version 4.6.1. But I flashed version 4.6.3 to have the latest available version.

  5. Seeed says to choose “Jetson Nano” as target device. I selected the “Jetson Nano (developer kit version)” instead. Because I thought that would be the right target.

Is it possible that point 4 and 5 caused the problems after “sudo apt update” and “sudo apt upgrade”.

15

I made a new post instead of an edit of my previous one because there are new Iinformations.

I now have a second Jetson Nano Developer Kit from Nvidia. I flashed the JetPack to a SD card and tested it with the DVI monitor.

The Jetson Nano developer Kit from Nvidia works perfectly fine with the DVI monitor.
The Jetson Nano from Seeed with the custom carrier board had problems with the DVI monitor. When powering the Seeed Jetson the displayed output was unreadable. It look a lot like static noise. I always had to replug the HDMI cable to get a readable display where the aspect ratio was wrong.

I’m starting to think there might be a hardware issue with the Jetson from Seeed right from the start.

Is it worth a try to insert the SD card from the Seeed Jetson into the new Jetson from Nvidia and try to boot?
Or can I damage the new Jetson with the OS on the SD card from the Seeed Jetson.

16

I do expect WSL2 to fail. In some cases it might succeed. In the case of using any kind of loopback feature, WSL2 would fail (in addition to other VM issues) unless you’ve installed a new kernel with loopback.

Your results suggest that the custom carrier board is missing a custom device tree.

Do expect that any time a video type without EDID (the DDC wire; in this case using EDID2 protocol) would merely use some default. True HDMI (or DVI digital…we don’t really know your adapter is using that as some DVI uses analog) would allow EDID to work. Even with EDID, the i2c has to function, or the EDID cannot be read (and this is configured in device tree). The “arb lost in communicate to add 0x50” is an i2c failure.

It is a firmware failure, not hardware. Hardware which cannot be found due to missing device tree configuration is the same as failed hardware, but it isn’t the hardware itself at issue…it is the driver not being able to find that hardware.

An SD card will not solve this unless it provides the correct device tree. Sadly, with an external SD card on a carrier board, the SD card itself requires a new device tree. It is my belief that the hardware is working perfectly, but the device tree needs to be on eMMC, and must be one provided for the Seeed carrier board.

Trying different modules on that carrier board won’t hurt anything. Parts of the hardware will be non-functional though until device tree is correct.

17

One of your posts in a different thread for august 2021 helped me to “solve” my boot problem.

But I don’t fully understand why the problem occurred because I don’t fully understand what is happenning during th boot process on the custom carrier board.

When using the custom carrier board from Seeed with a SD card to boot from the OS files from the eMMC are copied to the SD card and the extlinux.conf is edited. But it seems to me that during boot some information are still read from the eMMC (or somewhere else). Performing “sudo apt upgrade” upgrades the kernel files on the SD card but misses to upgrade the parts on the eMMC still neccessary for booting. So the files on the eMMC also needed the “sudo apt upgrade”.

This is never mentioned in the tutorials provided by Seeed.

I’m going to describe in detail what I’ve done to “create” the boot problem and how I “solved” it. Maybe somebody else will face a similar problem.

  1. Using a Seeed carrier board either with preinstalled JetPack or newly flashed JetPack on the eMMC.
  2. Insert a SD card in the carrier board and enable it following the instructions provided from Seeed here: J101 Enable SD Card | Seeed Studio Wiki
    (Thats an update of the device tree overlay I think.)
  3. Flash the JetPack OS from eMMC to the SD card following the instructions from Seeed: J1010 Boot From SD Card | Seeed Studio Wiki
    In the tutorial rsync is used to copy content from the eMMC to the SD card. In the /boot/extlinux/extlinux.conf file the “root” entry to the SD card (/dev/mmcblk1p1)

After that the device boots from the SD card. The eMMC is mounted under “/media/”.
Performing “sudo apt upgrade” upgraded the kernel on the SD card. But during boot process the device tries to load the old kernel files which fails.

To solve that I had to:
4) Using putty and SSH to connect to the device.
5) Mount the eMMC like linuxdev describe in his post from 30th of june.

sudo -s
mount /dev/mmcblk0p1 /mnt

  1. Change the root entry from /mnt/boot/extlinux/extlinux.conf back to the eMMC (/dev/mmcblk0p1).
  2. Reboot.
    The device should now boot again from the eMMC.
  3. Performe “sudo apt upgrade”.
  4. Enable the SD card again following the instructions from Seeed.
  5. Change the root entry from /boot/extlinux/extlinux.conf back to the SD card (/dev/mmcblk1p1).
  6. The device should now boot from the SD card.

This doesn’t solve the HDMI problem (and every other issue which might lurk somewhere on this custom board). But since I’m going to use the Jetson developer kit from Nvidia from now on this doesn’t concern me right now.

18

Just for the sake of the curious, consider some of the differences between eMMC models and SD card models, and then some of the different ways software and firmware might be found during boot…

An eMMC model has many partitions, and only one of them is the root filesystem (rootfs). The rest are the equivalent of a BIOS and boot content. The SD card models do not have eMMC, but they do have QSPI memory directly on the module, and it is the QSPI of an SD card model containing the same thing as those other non-rootfs partitions.

A very important part of boot, both during bootloader stages and during Linux o/s stage, is being able to find hardware which is not plug-n-play. Much of the hardware has no ability to self-report, and must be told which physical address to be found out, and also what the hardware actually is at that address. Usually the device tree does this.

For any model the device tree can be found either in a file in “/boot”, or in a partition or QSPI (some eMMC models actually do have QSPI as well, but ignore it). That content, when not part of a file in “/boot”, is signed (the key is a NULL “test” key unless purposely signed otherwise). The file content in “/boot” takes precedence; the exception is if security fuses are burned, in which case only partition content is allowed (SD card models do not have security fuses). If either there is no file version of the device tree or kernel, or if not named in extlinux.conf, then boot reverts to the partition (or QSPI) content to find that.

Any partition or QSPI content occurs during flash. Official documents tend to mention flashing to add kernel or device tree, but usually it is easier to work with files in “/boot”. Package updates can also sometimes alter files and/or partition content.

So there are two sources of both kernel and device tree. Circumstances change which one is used. The required device tree for an eMMC model differs from an SD card model.

Also, the device tree which Linux sees can be edited by bootloader stages before Linux sees it (mostly it isn’t edited).

HDMI is plug-n-play. The mechanism for this requires the i2c protocol. The i2c hardware is in the monitor itself. The power rails which provide power to the i2c though is in the HDMI wiring and provided by the host. The pins which provide that power from the module, and the wiring which uses i2c, is variable and not set to particular pins. The device tree is needed to tell the module which pins to use for the i2c of HDMI plug-n-play, and is also needed to apply power to the correct rails to reach the HDMI connector. If and only if i2c completes will the plug-n-play “EDID” data be read.

If the “/var/log/Xorg.0.log” indicates EDID failed, then your device tree is likely bad. If the EDID is found and valid, then problems are likely to not be device tree. One of the first steps for HDMI is to look at “/var/log/Xorg.0.log” (sometimes the “0” is a different number) in order to see if EDID is found.

If EDID is valid, but display is still a problem, then it is important to know that the GPU will only allow modes which are the intersection of (A) the monitor’s reported EDID, and (B) the modes the GPU has available. This intersection is known as the “mode pool”. One cat edit “/etc/X11/xorg.conf” to make the log explicitly list every single mode, and whether or not that mode is intersected or excluded.

To edit xorg.log to show this extended information, look for Section "Device", and edit like this to add a line:

Section "Device"
    Option "ModeDebug"

Then reboot, and check the new Xorg.0.log.

If you lack HDMI, then it is important to show this information:

  • Is the monitor truly HDMI, or is it using an adapter? If the adapter uses EDID (is digital), then it is ok (the logs would show EDID succeeded).
  • If the EDID succeeds, but video still fails, then you want the log with ModeDebug.
  • If EDID succeeds, then you can conclude that this part of the device tree’s i2c is correct, including power rails.
  • If EDID fails, and if the monitor is truly HDMI, then one should suspect the device tree or HDMI cable.
19

Thank you for the informations for the boot process.

Concerning the HDMI:
With the carrier board from Seeed the monitor is recognized as “Nvidia”.
With the carrier board from the developer kit from Nvidia the monitor is recognized as a Dell monitor which it actually is.
With the carrier board from the developer kit the monitor also works without problems.

So I guess this indicates an issue with the custom carrier board from Seeed.

Anyway: I’m going forward using the developer kit from Nvidia from now on. The goal is also to work without a monitor in headless mode with Yupiter Lab. So I’m not going to dig any deeper into the HDMI issue with the Seeed carrier board.

Thanks again for all the information you provided and your support. It was much appreciated.

20

The reason for the boot problem was the usage of a custom carrier board. A reComputer J101 from Seeed Studio.

The problem can be replicated with the following steps:

  1. Insert a SD card into the custom carrier board.
  2. Enable the SD card following the instructions from Seeed.
  3. Bott from SD card following the instructions from Seeed.
  4. Execute a “sudo apt upgrade” command after booting from SD card.

When the upgrade leads to an upgrade for the kernel to a higher version the Jetson won’t boot anymore properly. During boot the Jetson tries to load the previous installed kernel for which no files under “/lib/modules/” are present anymore.
The upgrade seems to only affect contents on the SD card but during boot some partitions of the eMMC are read which point to an older kernel version.

Solution:
The Jetson can still be accessed through a serial connection.

  1. Mount the eMMC.
  2. Follow the instructions from Seeed to boot from eMMC again instead from SD card. (Chanhging the root entry in extlinux.conf back to eMMC)
  3. Execute the “sudo apt upgrade” after booting from eMMC.
  4. Enable the SD card again following the instructions from Seeed.
  5. Change the root entry in extlinux.conf to boot from SD card again.

After this the Jetson should boot properly from SD card again.

Thanks to linuxdev for the support!