TX2 won't boot from dev kit board

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hello
I used the TX2 very successfully on board a drone using an orbitty carrier board.
I wanted to try the TX2 for some other project. I took the TX2 off of orbitty and put
it on the nvidia tx2 dev kit board.
Now it won’t boot. It powers on an the boot screen says
cp: not writing through dangling symlink ‘etc/resolv.conf’ and the CPU1 and CPU2 shutdown.

Can you help resolve this issue, please?
Here is the link to the boot screen image.

Thanks,

3

Hi,

It is normal 2x cpu would shutdown. Could you re-flash your board with jetapck again?

4

I am hesitating to do that since the TX2 was carefully optimized for real time visual odometry that uses tensorRT and other things. If I flash the TX2, I guess I have to re-optimize it. Is there a way to get to the boot loader and fix resolv.conf ?

5

You can clone before flashing, but each carrier board has to have its own board support package (mainly the device tree changes, and the device tree provides information about how the system is wired).

FYI, you can flash from a fresh location without the Orbitty carrier board’s BSP, but you’d need to use the same JetPack/SDK Manager release which provided the original Orbitty flash since the rootfs (the clone) has dependencies on the release version.

What is your current L4T release (see “head -n 1 /etc/nv_tegra_release”)?

Another note is that you can create a clone onto your PC with most any JetPack/L4T/SDK Manager release…it is only the flash step where rootfs clone and release must match. Instructions vary depending on release.

6

I am checking my notes for for Jetpack/SDK Manager release. Meanwhile,
Thanks for your response. Sorry, I am having trouble finding L4T.run

I have a new host machine. I tried to install jetpack-L4T-4.3.1 as per the instructions in:

https://docs.nvidia.com/jetpack-l4t/content/developertools/mobile/jetpack/l4t/3.0/jetpack_l4t_install.htm

(Could not find JetPack-4.3.run anywhere; could not find in nvidia/sdkm_downloads)

The link for jetpack-4.3.3 takes me now to sdk manager. I downloaded the latest SDK manager from

https://docs.nvidia.com/sdk-manager/install-with-sdkm-jetson/index.html

Ran SDK manager, but it does not allow me to install L4T tools, if I skip the target machine (TX2, in this case) flashing. It finished anyways, and after the finish,

autoland@autoland:~$ head -n 1 /etc/nv_tegra_release
head: cannot open ‘/etc/nv_tegra_release’ for reading: No such file or directory

How do you install just L4T?

7

Hi psatya-narayana,

Please run sdkmanager on your host Ubuntu machine (16.04 or 18.04) and connect micro-usb cable from TX2 to host.
Then you can start flash image and install sdk components.
Please reference detail user guide from: Install Jetson Software with SDK Manager :: NVIDIA SDK Manager Documentation

You can skip install host machine (unselect it), but must install Target Hardware (TX2).

8

https://elinux.org/Jetson/General_debug

You may need this wiki page for some guidance.

Sdkmanager is a new tool to replace jetpack after rel-32. It is installed on your host by deb file so there is no .run file. Just type the comannd “sdkmanager” and it would show.

9

I do not want to flash it yet. I need to clone it (back up the image) before cloning.

10

Sorry, I meant to say - I need to clone it before flashing it.

11

Hi psatya-narayana,

You can run below command to clone/restore image:

  1. Put device into recovery mode
  2. Clone image:
    $ sudo ./flash.sh -r -k APP -G backup.img jetson-tx2 mmcblk0p1
  3. Restore image:
    $ sudo cp bakcup.img bootloader/system.img
    $ sudo ./flash -r -k APP jetson-tx2 mmcblk0p1
12

Thank you, Carolyuu
I just installed host components using SDK, finished successfully. Skipped TX2 component install to preserve the
existing image on TX2.
command flash is not found . when I use “which flash” to find out where it is.

Also, in (2) what directory I should be in to do ./flash?
in (3) is there a | (pipe) missing in before the second sudo?

Thanks for hanging with me.

13

Hi psatya-narayana,

Sorry for typo.
The steps 2 “flash” should be “flash.sh”
$ sudo ./flash.sh -r -k APP -G backup.img jetson-tx2 mmcblk0p1

14

Hi,

I just wondering what kind of error do you have now…? Do you mean your system is always booting up fine and you could ssh to it but just no desktop shown up on screen?

15

Thanks for reaching out:
(1) I am going through links to find a better way to do this, because
carolyuu’s suggestions are not viable because I do not have flash.sh installed in the host machine
SDK manager wont install it unless I flash the device, it seems. Did not want to take the risk.
(2) per linuxdev’s tip that I should use the same sdk manager as I first used with the orbitty board: I am fishing for that for the past few days.

16

WayneWWW :
In other words
To use the command
sudo ./flash.sh -r -k APP -G backup.img jetson-tx2 mmcblk0p1
I need to have the SDK manager up and TX2 connected by USB, and get these L4T utilities, right ?
If you could elaborate on that, I would appreciate it

17

This implies the flash content was not valid (the flash operation could succeed, but the content being flashed would not be complete):

FYI, L4T is what JetPack/SDK Manager installs to the Jetson. JetPack/SDKM never installs to the Jetson, and is simply a front end for other flash software. Installing L4T will wipe the system and install defaults.

When the Jetson is in recovery mode it becomes a special USB device understood only by the “driver package” (which is something SDKM downloads for you…the “driver package” creates the “Linux_for_Tegra/” subdirectory content).

In a normal flash the sample rootfs plus NVIDIA-specific drivers are added to a purely Ubuntu arm64 system in the “Linux_for_Tegra/rootfs/” location. The missing “/etc/nv_tegra_release” says the “rootfs/” content was not valid prior to beginning the flash. A normal flash adds a few boot config edits to the “rootfs/” content, and then copies that to the Jetson.

In a clone there is a reverse, whereby the rootfs content is copied from the Jetson to the host PC. Two files are produced: A “raw” bit-for-bit exact copy of the root partition, and a “sparse” (smaller) version. Typically named something like “backup.img” (sparse) and “backup.img.raw” (raw). I throw away the sparse image and keep only the larger raw image. Raw images can be edited and used and examined from the host PC, but sparse files, despite being smaller, have no such ability. Either version can be used to flash with as a substitute to the “Linux_for_Tegra/rootfs/” content to restore that rootfs.

That flash performs many more partition installs than just the rootfs. Those other partitions are used for boot. This could be called the board support package (“BSP”) content. Much of this is related to device trees, memory setup, boot loaders, so on. The default is for the development kit carrier board. As soon as you use Orbitty you need to overlay that content to the host PC somewhere within the “Linux_for_Tegra/” directories prior to flash, or the Jetson will have an invalid idea of how the carrier board is wired. The Orbitty people will have that content and instructions.

The clone is good to have because then you can afford to make mistakes until you get the flash and the BSP edits in place and not loose your original filesystem content.

The more concerning question is why “/etc/nv_tegra_release” was missing (or on the host PC, “Linux_for_Tegra/rootfs/etc/nv_tegra_release”). Two things come to mind…

First, if your host PC ran out of disk space, then the image would have truncated at some random place. An enormous amount of disk space is required to create and flash rootfs images. Each rootfs image is going to consume about 30GB of disk space. Your clone raw file will require about 30GB of space. If that clone is from a nearly empty filesystem, then the sparse file will require nearly 2GB of space…if that clone is from a nearly full filesystem, then the sparse file will require nearly 30GB of space. On your host PC, if you run “df -H -T /where/ever/you/flash/from/Linux_for_Tegra”, do you have plenty of spare space?

The other possibility is that if you flashed manually, or if for some reason SDKM did not download and install rootfs content, then the “Linux_for_Tegra/rootfs/” would itself have never been installed. This is ok if you are using a clone to restore from, but if your clone did not have “/etc/nv_tegra_release”, then your clone is not valid. This is not relevant for creating a clone, but this is relevant for flashing.

NOTE: Any time you use flash.sh without the “-r”, the rootfs is generated from the default “Linux_for_Tegra/rootfs/” content, plus edits. Any time you restore from a clone you put your clone in the correct place, and then flash using “-r” to avoid having this overwritten by default content. More details on that are available, but let’s first find out why your original flash was missing part of the filesystem.

18

(1) I am going through links to find a better way to do this, because
carolyuu’s suggestions are not viable because I do not have flash.sh installed in the host machine
SDK manager wont install it unless I flash the device, it seems. Did not want to take the risk.

I don’t know why this step is not viable. If you read my link in below, you should know where to find out flash.sh.
https://elinux.org/Jetson/General_debug

Please do read this page.

I need to have the SDK manager up and TX2 connected by USB, and get these L4T utilities, right ?

Flash.sh would be installed on your host after you run sdkmanager. It does not matter the flash is successful or not. If you choose the board in sdkm, then sdkm will download flash.sh.

Also, what was your original driver package on that orbitty board? How did you flash it on orbitty board? It sounds like you are new to sdkm.

19

Thank you for the nice tutorial. With respect to your query:
“The more concerning question is why “ /etc/nv_tegra_release ” was missing (or on the host PC”

We have TX2 processors: TX2-1 and TX2-2
TX2-1 was originally flashed using SDK manager, the version of which is unknown, because while TX2-1 was on board a drone (drone-1) , the host PC died and we had to rebuild it. So, the original sdk that we used to flash it is gone.
TX2-1 was working fine on board the drone-1.

TX2-2 was flashed more recently using JetPack_4.3_Linux_P3310. This is currently on the rebuilt host system:
autoland@autoland:~$ df -H -T ~/nvidia/nvidia_sdk/JetPack_4.3_Linux_P3310/Linux_for_Tegra
Filesystem Type Size Used Avail Use% Mounted on
/dev/nvme0n1p10 ext4 458G 38G 397G 9% /home

I have enough space on the host system.
TX-2 is on board a second drone, drone-1, and doing fine.

drone-1 is retired and want to use TX2-1. TX2-1 wont reboot . I guess the only way is to flash it with jetpack_4.3_Linux_P3310 and rebuild the TX2-1 all over, according to the replies.

20

If you changed carrier boards, then you could clone rootfs to save content, but you would have to flash again using the correct BSP for that carrier board. Otherwise you have to go through @WayneWWW 's comments for https://elinux.org/Jetson/General_debug. While doing so keep in mind that any Jetson without the file “/etc/nv_tegra_release” had something go terribly wrong during either flash or creation of the image used in flash. No TX2 will be without this file if the NVIDIA drivers are in place.

21

All those files flashed to your TX2 would be put under Linux_for_Tegra/rootfs first. Please check whether etc/nv_tegra_release is there.