Jetson Nano boot sequence is stuck on uboot

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Greetings

I just installed my Nano using the standard Jetson Nano Developer Kit SD Card Image, booted, completed the installation, and could successfully build and test jetson-inference, which was great by the way!

The issue is that after a while it would not reboot, the screen freezes on the NVIDIA image.

So I connected my laptop to the Nano via the Nano’s UART, and after I hit Enter, here is what I got on the terminal:

Unknown command ‘ra210’ - try ‘help’
Tegra210 (P3450-Porg) #

The boot sequence was stuck because of that ra210 ‘command’ that somehow was sent to TegraBoot. It stroke me that ‘ra210’ are the last characters of Tera210.
So I entered boot on the terminal and the boot completed successfully:

Tegra210 (P3450-Porg) # boot
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
733 bytes read in 160 ms (3.9 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
5487751 bytes read in 287 ms (18.2 MiB/s)
Retrieving file: /boot/Image
34191368 bytes read in 1532 ms (21.3 MiB/s)
append: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,2 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 tegra_fbmem=0x800000@0x92cb4000 is_hdmi_initialised=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 quiet
Flattened Device Tree blob at 83100000
Booting using the fdt blob at 0x83100000
reserving fdt memory region: addr=80000000 size=20000
Using Device Tree in place at 0000000083100000, end 00000000831776f0

Starting kernel …

[ 1.083127] tegradc tegradc.1: dpd enable lookup fail:-19 [ 1.258460] imx219 6-0010: imx219_board_setup: error during i2c read probe (-121) [ 1.258487] imx219 6-0010: board setup failed [ 1.269771] tegra124-dfll 70110000.clock: dfll_one_shot_calibrate_mv: use unstable monitor output 103 [ 1.983497] cgroup: cgroup2: unknown option "nsdelegate" [ 3.830351] random: crng init done [ 3.833787] random: 7 urandom warning(s) missed due to ratelimiting [ 4.141411] using random self ethernet address [ 4.150108] using random host ethernet address [ 4.856116] using random self ethernet address [ 4.860651] using random host ethernet address

Ubuntu 18.04.4 LTS jetson ttyS0

jetson login:

This behavior is totally reproducible although this is not always ‘ra210’. For example, I now got ‘MC’, the end of ‘MMC’?:

Unknown command ‘MC:’ - try ‘help’
Tegra210 (P3450-Porg) # boot

I was curious to see when that invalid command was received during the whole boot process, and with the terminal still connected, forced a warm reboot and got the complete boot sequence (that you can see here), that completed this time around without being stuck.

You’d find, line 396, the prompt allowing to stop autoboot:

U-Boot 2016.07-g0536cf2a27 (Dec 09 2019 - 22:40:32 -0800)

TEGRA210
Model: NVIDIA P3450-Porg
Board: NVIDIA P3450-PORG
DRAM: 4 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
SF: Detected MX25U3235F with page size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: No ethernet found.

Hit any key to stop autoboot: 0

switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
733 bytes read in 159 ms (3.9 KiB/s)
1: primary kernel
Retrieving file: /boot/initrd
5487751 bytes read in 287 ms (18.2 MiB/s)
Retrieving file: /boot/Image
34191368 bytes read in 1532 ms (21.3 MiB/s)

The remarkable thing is that the boot sequence always succeeds when a terminal is connected to the serial port, and always fails when not. For information, here is the whole cold boot sequence, that indeed succeeded because the terminal was connected.

Note that I re-installed and flashed the latest image (Jetpack 4.3 l4t-r32-3-1) via the SDK Manager. After completing the installation to the minimum (completing the OS installation, without apt-get update / apt-get upgrade) I obtained the exact same behavior: cannot reboot unless a terminal is connected to the Nano’s UART.

Why is that, have you ever seen this?

Thanks for any tips!
JP

3

Hi,

Actually it is “uboot” but not tegraboot. We don’t see such error on jetson nano before. What carrier board are you using?

and with the terminal still connected, forced a warm reboot and got the complete boot sequence (that you can see here), that completed this time around without being stuck.

Do you mean if you connect UART and enable serial console, then you could enter the system w/o problem?
It feel like there are some garbage key event that already interrupted the UART before you use console to check the log and this does not happen if you always connect the console…

4

WayneWWW,

Thanks, I updated the title of the post (from Tegraboot to uboot).

I didn’t do anything to enable console on tty, as it is done by default, which is a good thing.
Now to clarify the UART connection, I connected a USB to TTL serial cable to the serial port header (J44):

UART
UART1024×768 140 KB

And the other side to my laptop’s USB port.
The remarkable thing is that I don’t even have to run a terminal app (such as TeraTerm).
I only have to connect the USB side of the USB to TTL serial cable to the laptop, and this even before applying power to the Jetson Nano, to have it working.

5

Does it always in uboot console when you hit this error? If you set the boot delay ot 0, do you still hit this issue?

6

Thank you for reproducing! Does it means that you too got the case where the boot sequence was stopped in uboot? This happens to me all the time when there is nothing connected to the UART.

One of the first things I tried is to set boot delay to 0, but alas still the same issue.

11

Problem solved.

It was caused by the TTL serial to USB cable that I was using. Somehow that cable (that probably includes a FTDI circuit) was introducing interference with uboot when not plugged on the USB side. Lesson learned for me: either use the cable to connect to the PC, or disconnect the cable at the level of the Jetson Nano UART altogether.

12

I see. Thanks for sharing.

13

Perhaps it needed the ground on the USB end to prevent noise.