Nvidia Jetson TX2 SD Card boot using flash.sh script no GUI

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
,
1

Dear Nvidia Community,

I realize the question on how to boot from an external medium has been discussed in detail in the following topic:
Jetson TX2 : boot on SD Card.

My question is not related to how exactly to make it boot from an external source, but whether correct behavior is exhibited by the Jetson TX2 I am using at the moment, after booting from an sd card.

In order to boot from an SD Card, I followed this tutorial: Jetson/L4T/Boot From External Device. The link to the wiki I found in the “Some Jetson Web Links” nvidia developer forum post here: Some Jetson Web Links.

When an SD Card is not plugged in, the board fails to boot as it does not find the corresponding PARTUUID specified in the l4t-rootfs-uuid.txt bootloader file. This conforms to what is expected so far as behavior.

When an SD Card is plugged in for the first time, a computer monitor attached, the Jetson turned on, the initial Jetson GUI setup is executed as expected (setting up a user, password, etc…). This conforms to what is expected so far as behavior.

When an SD Card is plugged in, a computer monitor attached, the Jetson turned on, there is no GUI. This does not conform to what is expected so far as behavior. The Jetson TX2 is also accesible over SSH.

So my question is - is the lack of GUI expected when booting from an SD Card when using the Jetson/L4T/Boot From External Device method?

Kind regards,
Mihail

2

You would probably need to post a serial console boot log. See:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/

I don’t know if you are hitting this issue, but I will describe it since it is so easy to get odd behavior if you are not aware of it: When you boot the earlier boot stage point at an extlinux.conf. In the case of normal flash and no external media, then this is the eMMC’s “/boot/extlinux/extlinux.conf”.

As soon as you boot to an SD card, then this too has an extlinux.conf. Do you know which one you are booting from?

If the SD card was copied from eMMC and is using an exact match of the eMMC’s extlinux.conf, then you are still booting to eMMC’s version. In that case you want to make sure your extlinux.conf is edited for the SD card boot. Since your system wants the SD card to boot, then it indicates it is using the SD card’s extlinux.conf.

If you are booting via SD card and have serial console, then you can edit the SD card’s extlinux.conf and change the “MENU LABEL” part. The serial console would see that label, and you could confirm which extlinux.conf you are using. For example, if you have:
MENU LABEL primary kernel
…then you could edit to instead be:
MENU LABEL sd kernel
(the label is what you see in the boot output as you boot)

If you know you have the correct extlinux.conf, then you would make sure the actual entry for that boot points at the SD card…if the content was just a copy of the eMMC version, then you are only using the extlinux.conf and nothing else from the SD card.

After you have verified you are booting to the correct rootfs, then that same serial console boot log would provide information about what is going on with the GUI.

3

Hello linuxdev,

thank You for Your reply!

As soon as you boot to an SD card, then this too has an extlinux.conf . Do you know which one you are booting from?

When the SD Card is plugged in, U-Boot reads from the extlinux.conf.
I can verify this when looking at the serial console boot logs (once without an SD-Card plugged in, and once with an SD-Card plugged in).

  1. Without an SD-Card plugged in the U-Boot logs
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
  1. With an SD-Card the U-Boot logs
mmc1 is current device
Scanning mmc 1:1...
Found /boot/extlinux/extlinux.conf

If the SD card was copied from eMMC and is using an exact match of the eMMC’s extlinux.conf , then you are still booting to eMMC’s version. In that case you want to make sure your extlinux.conf is edited for the SD card boot. Since your system wants the SD card to boot, then it indicates it is using the SD card’s extlinux.conf .

I copied the rootfs folder that the SDKManager downloaded.
To copy the rootfs folder, I used the instructions in Step 3 of the tutorial mentioned above Jetson/L4T/Boot From External Device

3. Get partition UUID and copy rootfs to the device:

...
 $ cd rootfs/
 // copy rootfs
 $ sudo tar -cpf - * | ( cd /mnt/ ; sudo tar -xpf - )

If you know you have the correct extlinux.conf , then you would make sure the actual entry for that boot points at the SD card…if the content was just a copy of the eMMC version, then you are only using the extlinux.conf and nothing else from the SD card.

I am almost convinced that the correct extlinux.conf is being used, because when the SD Card is plugged in, the Jetson turned on, and a Serial-to-USB attached, I get a login prompt eventually.
I will nevertheless look at the point You mention before that and get back to You.

After you have verified you are booting to the correct rootfs, then that same serial console boot log would provide information about what is going on with the GUI.

I have attached both console logs (Without a SD-Card and once with a SD Card)

screenlog_no_sd.log (22.0 KB)
screenlog_sd.log (22.3 KB)

An excerpt from the console log for when the SD-Card is plugged in:

U-Boot 2020.04-g6b630d64fd (Jan 15 2021 - 14:41:30 -0800)

SoC: tegra186
Model: NVIDIA P2771-0000-500
Board: NVIDIA P2771-0000
DRAM:  7.8 GiB
MMC:   sdhci@3400000: 1, sdhci@3460000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   
Warning: ethernet@2490000 using MAC address from ROM
eth0: ethernet@2490000
Hit any key to stop autoboot:  2  1  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
734 bytes read in 44 ms (15.6 KiB/s)
1:	primary kernel
Retrieving file: /boot/initrd
7236790 bytes read in 823 ms (8.4 MiB/s)
Retrieving file: /boot/Image
34338824 bytes read in 3790 ms (8.6 MiB/s)
append: console=ttyS0,115200 androidboot.presilicon=true firmware_class.path=/etc/firmware root=PARTUUID=8363108c-d01b-49b1-ba0a-f6aa8a4202f8 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2  video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt rootfs.slot_suffix= usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 quiet
## Flattened Device Tree blob at 80000000
   Booting using the fdt blob at 0x80000000
ERROR: reserving fdt memory region failed (addr=0 size=0)
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 0000000080000000, end 0000000080060699
copying carveout for /host1x@13e00000/display-hub@15200000/display@15200000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15210000...
copying carveout for /host1x@13e00000/display-hub@15200000/display@15220000...

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x100
[    0.000000] Linux version 4.9.201-tegra (buildbrain@mobile-u64-4551) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Fri Jan 15 14:54:23 PST 2021
[    0.000000] Boot CPU: AArch64 Processor [411fd073]
[    0.000000] OF: fdt:memory scan node memory@80000000, reg size 80,
[    0.000000] OF: fdt: - 80000000 ,  70000000
[    0.000000] OF: fdt: - f0200000 ,  185600000
[    0.000000] OF: fdt: - 275e00000 ,  200000
[    0.000000] OF: fdt: - 276600000 ,  200000
[    0.000000] OF: fdt: - 277000000 ,  200000
[    0.000000] earlycon: uart8250 at MMIO32 0x0000000003100000 (options '')
[    0.000000] bootconsole [uart8250] enabled
[    3.533442] cgroup: cgroup2: unknown option "nsdelegate"
[    5.820916] random: crng init done
[    5.824320] random: 7 urandom warning(s) missed due to ratelimiting
[   11.594909] using random self ethernet address
[   11.602355] using random host ethernet address
[   14.252689] using random self ethernet address
[   14.257401] using random host ethernet address
[   17.539468] CPU1: shutdown
[   17.588054] CPU2: shutdown


Ubuntu 18.04.5 LTS nvidia-sd-card ttyS0

nvidia-sd-card login:
4

Calling startx after logging into the Jetson TX2 after booting from the SD Card actually starts the GUI.

I consider this topic closed!

Thank You for contributing!

5

I don’t know how this would get the UUID. Certainly this would get the “rootfs” using tar and prevent many possible errors which a simple cp operation would be subject to, but the UUID would be applicable only to an actual partition, not the files (in fact the partition could be empty, and it would still have an ID). If you want to see an example of UUIDs, just run the command “lsblk -f”. UUID is one method for naming a partition which is independent of how the device is mounted and independent of what kind of media it is on.

FYI, you did confirm the SD card version of the extlinux.conf is used. Was this edited within the file itself to name SD card instead of pointing back to the eMMC? You might want to attach a copy of the SD card version of extlinux.conf. Something in that file which might have been mmcblk0 would now require mmcblk1. If you now use the SD card version of the extlinux.conf, but that is a copy of the original extlinux.conf, then you are missing edits and pointers will go back to eMMC unless you’ve manually fixed this. I want to confirm what is within the SD card version of extlinux.conf now that we know it is the SD card version being used.

Please note that the extlinux.conf file can change access to the firmware, so this must be confirmed before anything else can be confirmed.

1 Like