Boots to flashing cursor - what next?

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

This is a Seeed J1020 v2 (a 4GB Nano in other words).

I’m trying to boot the QEngineering image installed on a 256GB NVME SSD card (which fits into a slot under the board).

I am using the technique described in ‘can I install it in external SSD and run it from there?’ of having two entries in the extlinux.conf file. The same extlinux.conf file is on both the storage units.

When I boot I get some scrolling text with some errors, and then the screen clears to just a flashing cursor.

Here is a dodgy screenshot of the text:

IMG_0047
IMG_00471920×2560 492 KB

I reflashed the unit once (as I thought I had broken the install) but then learnt about the serial interface…

Using this and uboot I can select the NVME drive, boot it, and log in to it but there is nothing on the ‘normal’ screen (Iusing the HDMI port using a DVI adapter, which works fine for the standard installed boot).

Here’s the boot from the serial interface:

U-Boot 2020.04-g4335beb (Jun 08 2023 - 21:16:44 -0700)

SoC: tegra210
Model: NVIDIA Jetson Nano Developer Kit
Board: NVIDIA P3450-0000
DRAM: 4 GiB
MMC: sdhci@700b0000: 1, sdhci@700b0600: 0
Loading Environment from MMC… *** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Tegra210 (P3450-0000) # boot
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1174 bytes read in 30 ms (38.1 KiB/s)
L4T boot options
1: NVME drive
2: eMMC drive
Enter choice: 1
1: NVME drive
Retrieving file: /boot/initrd
7159654 bytes read in 183 ms (37.3 MiB/s)
Retrieving file: /boot/Image
34707464 bytes read in 785 ms (42.2 MiB/s)
append: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resiz
Flattened Device Tree blob at 83100000
Booting using the fdt blob at 0x83100000
ERROR: reserving fdt memory region failed (addr=83410000 size=10000)
ERROR: reserving fdt memory region failed (addr=83400000 size=10000)
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
Using Device Tree in place at 0000000083100000, end 000000008317dfff
copying carveout for /host1x@50000000/dc@54200000…
copying carveout for /host1x@50000000/dc@54240000…

Starting kernel …

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.337-tegra (buildbrain@mobile-u64-5434-d8000) (3
[ 0.000000] Boot CPU: AArch64 Processor [411fd071]
[ 0.000000] OF: fdt:memory scan node memory@80000000, reg size 32,
[ 0.000000] OF: fdt: - 80000000 , 7ee00000
[ 0.000000] OF: fdt: - 100000000 , 7f200000
[ 0.000000] Found tegra_fbmem: 00140000@92cb4000
[ 0.000000] earlycon: uart8250 at MMIO32 0x0000000070006000 (options ‘’)
[ 0.000000] bootconsole [uart8250] enabled
[ 1.158526] tegradc tegradc.1: dpd enable lookup fail:-19
[ 1.351928] imx219 7-0010: imx219_board_setup: error during i2c read probe ()
[ 1.351994] imx219 7-0010: board setup failed
[ 1.375840] imx219 8-0010: imx219_board_setup: error during i2c read probe ()
[ 1.375899] imx219 8-0010: board setup failed
[ 1.737775] cgroup: cgroup2: unknown option “nsdelegate”
[ 2.170609] systemd[1]: Failed to start Load Kernel Modules.
[ 2.552347] squashfs: SQUASHFS error: Xattrs in filesystem, these will be igd
[ 2.560667] squashfs: SQUASHFS error: unable to read xattr id index table
[ 2.597254] squashfs: SQUASHFS error: Xattrs in filesystem, these will be igd
[ 2.604911] squashfs: SQUASHFS error: unable to read xattr id index table
[ 2.696583] squashfs: SQUASHFS error: Xattrs in filesystem, these will be igd
[ 2.704173] squashfs: SQUASHFS error: unable to read xattr id index table
[ 2.720113] squashfs: SQUASHFS error: Xattrs in filesystem, these will be igd
[ 2.727678] squashfs: SQUASHFS error: unable to read xattr id index table
[ 3.184014] random: systemd-journal: uninitialized urandom read (16 bytes re)
[ 3.194523] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.201389] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.215097] random: crng init done
[ 3.218549] random: 142 urandom warning(s) missed due to ratelimiting
[ 3.474012] using random self ethernet address
[ 3.478654] using random host ethernet address
[ 4.508125] using random self ethernet address
[ 4.551852] using random host ethernet address
[ 7.907400] tegra-i2c 7000c000.i2c: no acknowledge from address 0x50
[ 7.914821] tegra-i2c 7000c400.i2c: no acknowledge from address 0x50

Ubuntu 20.04.6 LTS nano ttyS0

(I removed a double hash sign from the front of ‘Flattened Device Tree blob at 83100000’ as it was causing markup formatting!).

As I said, I can log into the running 20.04.6 image through the serial interface, but there is nothing on the ‘normal’ screen.

What could be wrong, and what should I do next?

Many thanks,
Peter

2

It is likely that the Seeed carrier board requires different firmware (device tree). The lane routing when designing a carrier board has options, and unless Seeed makes this a 100% exact match to the dev kit, then parts are going to fail.

Incidentally, NVIDIA does not support any Ubuntu 20.04 on a Jetson Nano. If this is a Jetson Xavier Nano or Jetson Orin Nano, then it is supported, but you’d still need Seeed’s flash software. Somewhere Seed will state one of these:

  • Their software is an exact match for the NVIDIA flash software.
  • Provide a patch to the NVIDIA software.
  • Provide a rebranded flash software.
3

Thanks for the reply.

I’m pretty sure that the J1020 is totally compatible with the NVIDIA products, you flash it using the NVIDIA SDK Manager - this is documented on the Seeed website.

My somewhat simplistic view is that the graphical interface is simply not coming up. I did see another thread about the flashing cursor that suggested some checking, so I did that through the serial interface -

jetson@nano:~$ sudo service gdm3 status                                                                  
��● gdm.service - GNOME Display Manager                                                                  
     Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: en>                         
     Active: active (running) since Wed 2023-09-13 13:27:55 CEST; 29s ago                                
    Process: 3841 ExecStartPre=/usr/share/gdm/generate-config (code=exited, sta>
    Process: 3885 ExecStartPre=/usr/lib/gdm3/gdm-wait-for-drm (code=exited, sta>
   Main PID: 4669 (gdm3)
      Tasks: 3 (limit: 4179)
     Memory: 4.5M
     CGroup: /system.slice/gdm.service
             ��└��─4669 /usr/sbin/gdm3

sep 13 13:27:45 nano systemd[1]: Starting GNOME Display Manager...
sep 13 13:27:55 nano systemd[1]: Started GNOME Display Manager.
sep 13 13:27:55 nano gdm-autologin][4674]: gkr-pam: no password is available fo>
sep 13 13:27:55 nano gdm-autologin][4674]: pam_unix(gdm-autologin:session): ses>
sep 13 13:27:56 nano gdm-autologin][4674]: gkr-pam: gnome-keyring-daemon starte>
sep 13 13:27:56 nano gdm3[4669]: GdmDisplay: Session never registered, failing
sep 13 13:27:57 nano gdm-launch-environment][4740]: pam_unix(gdm-launch-environ>
sep 13 13:27:58 nano gdm3[4669]: Child process -4809 was already dead.
jetson@nano:~$ sudo service gdm3 restart
jetson@nano:~$

but no difference. Some of the lines are truncated in the Minicom interface.

There was also a section in the login ‘welcome’ text saying that Ubuntu was minimized (?) and that you could run ‘unminimize’ to restore extra functionality. Could this mean that the build was minimized and needs to be unminimized to add a working GUI back in?

Sorry, I have lots of computer experience but not much with Linux, so any help is much appreciated.

5

Hi,

We don’t officially support Jetson Nano with Ubuntu 20.04, so not much we can help here.
It’d be better you file a issue on the GitHub page.
Anyway, you can try re-flashing the device with vanilla JetPack using SDK Manager, and see if it gets video output to make sure it’s not some kind of bootloader issue.

6

You can ignore “unminized” because this is just saying that documentation content (through “man pages”) has not been installed. It is unrelated.

If you can verify that this really is just an older Nano, and not Xavier or Orin Nano, then it is possible to continue, but you’ve posted in the forum for older original Nano (which is really a small form factor TX1). Older original Nano does not support Ubuntu 20.04.

Regarding DVI, some are digital, and others are analog (some offer both). The digital DVI passes through the DDC wire (which contains EDID data for configuration), analog does not. If you don’t have the DDC wire, then you might get lucky and a default mode works, but most of the time you would be out of luck, so analog DVI is expected to fail. The driver software ignores any configuration other than through the DDC wire. There is more than one i2c bus, but if the bus without i2c acknowledge is for the HDMI connector, then it is video because the DDC wire sends EDID data using i2c protocol at address 0x50. Lack of 0x50 response on another bus indicates a device tree issue, but on HDMI it indicates failure of the DDC wire. Just to reiterate, you might get lucky with a default mode without the configuration data, but this is far less common that the symptoms you mentioned.

If this is just a Nano, and not Xavier or Orin, then you must revert back to the NVIDIA provided Ubuntu 18.04 (L4T R32.x; L4T is just Ubuntu plus NVIDIA drivers, and R32.x is Ubuntu 18.04).

7

Thank you DaveYYY and linuxdev, your help is much appreciated.

linuxdev said

…then you must revert back to the NVIDIA provided Ubuntu 18.04…

No need to revert, I have dual boot here, the 18.04 provided by NVIDIA is still bootable on the 16 GB eMMC, and I can boot the 20.04 QEngineering image from the NVME SSD. The best of both worlds!

The NVIDIA image boots fine (using uboot through the serial interface), and the GUI loads, so nothing wrong there.

linuxdev, thanks for the detailed notes on HDMI and DVI. I’m not sure I understand it all, but I get two messages that may be relevant:

tegra-i2c 7000c000.i2c: no acknowledge from address 0x50

and identical text but with the address 7000c400.i2c

As an experiment I tried booting the QEngineering image without the HDMI cable in, and put it in once it had booted. I got output saying

edid invalid

three times in a row, I think this may be what you’re talking about.

Would there be a reason why the NVIDIA image would be able to use the HDMI>DVI connection, but the QEngineering image can’t?

8

One of the two i2c busses is probably one to the HDMI cable. The invalid EDID might be due to issues with the i2c protocol (including power bus powering that wire), or the monitor itself might have an actual invalid configuration listing in its EDID data. Odds are quite high that the i2c talking to the monitor is failing. This, in turn, suggests a device tree edit is required (I couldn’t tell you what specifically to edit).

The DVI would be valid on both if it is digital DVI, or failing on both if it is analog DVI. If this is working on one case, then it suggests you have digital DVI and this can work. Maybe you got lucky though with a default resolution. I think the case is that the QEngineering image needs different firmware to properly route the i2c wires and i2c power to the HDMI connector. It is a device tree edit which is needed. Does QEngineering provide a device tree or other install media?

9

Many thanks linuxdev, I’ve got an issue open on the GitHub page, and I’ll update this thread if I find a solution.

I’m also going to find an HDMI monitor to try with a normal HDMI cable.

Once again, thanks for the help.

11

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