Some clarification required for USB boot

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hi all,

I need some clarification on preparing a USB drive for booting on the Jetson Nano
So for starters: I am on JetPack 4.5.1 and I know that now the boot loader is in the QSPI internal flash.

I have seen these two instructions for this topic around:

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0HM0HA

and

https://elinux.org/Jetson/L4T/Boot_From_External_Device

So now the Qns I had was:

  1. Where did the folder Linux_for_Tegra and its contents come from ? Downloaded or prepared by the SDK Manager ?

  2. How do we get into recovery mode ? Is it by removing the SD Card and connecting the nano via micro-usb to host pc ? Or by some pin configuration.

Sorry about these basic questions as I have not used the SDK Manager method of flashing yet so I am missing some background information …

And final question:

Is it possible to prepare a USB drive without using the jetson nano, plug it in and boot ?

2

  1. The Linux_for_Tegra is prepared by the sdkmanager. Or you can download it manually. But the manual way needs you to install all the things by yourself manually.
    It is actually the full package that includes all the binaries/tools for flashing jetson. Sdcard image is just an easy entry for some newbie trying to use jetson nano/NX.

  2. Please refer to the quick start guide in this download center it will teach you which pin to jumper and let the board get into recovery mode. Also, you need to prepare the x64 16.04 or 18.04 ubuntu host for using Linux_for_Tegra. VM is not supported.

  1. Is it possible to prepare a USB drive without using the jetson nano, plug it in and boot ?

Both methods are preparing the usb drive on the ubuntu host but not jetson nano. You can see the first line in the first document : 1.Connect the flash drive to the host computer.

In embedded system, we usually say “host” and “device” to tell the x86/64 host machine and the arm64 device (nano).

3

Thanks for the hints. There was some confusion about this because the step 7 says :

“Put the Jetson device into recovery mode, then enter the following commands to generate the rootfs without flashing the device:”

So we need to be connected here even to flash a USB drive using host computer ?

4

Yes, the usb drive is still on the host at that step.

After the umount command is done, you can remove it from the the host.

5

Sure. What I meant was that we need connect USB Drive to host computer and the jetson device also to host computer (via micro-USB cable) for the flashing process.
I wondered about its significance.

I found a beginner guide for USB flashing:

https://robroyce.dev/2021/02/11/how-to-boot-jetson-nano-from-usb-3-0-natively-with-jetpack-4-5/

Which I will try out. Have to first find a jumper cable somewhere…

6

Actually. when you do the work in this line, you don’t really need the usb disk plugged on the host. But the later work still needs it on the host.

$ sudo BOOTDEV=sda1 ./flash.sh --no-flash sda1

7

I would like to have some additional information on the sample rootfs. Is this rootfs not created from a standard tool like debootstrap ?

I mean when I chroot into rootfs, I am unable to connect to the network nor do a apt listing of the installed packages (nothing appears on screen)

I would like to have this list of installed packages of the sample rootfs and customisation if any.

8

Hi,

Does your host have qemu-user-static installed?

sudo apt-get install qemu-user-static

9

Hello @WayneWWW ,

I am doing this on jetson nano itself. Yes, I am aware of the process for flashing and using Ubuntu 18.04 on x86 for the process .I believe the qemu-user-static is used on x86 to run a arm64 binary within the chroot.

But here I am just trying to build a custom roootfs on the jetson nano itself.
So this question is about that.

10

We didn’t try that on jetson nano before. Better moving this job to the driver package on the host. Run the apply_binaries.sh to install necessary libraries/drivers to the rootfs.

11

I can confirm that first set of steps work on jetson-nano also. That is until the apply_binaries.sh.

After reading some posts in the forum on booting from usb I have a few questions.
Now that I have prepared a custom rootfs, I also found we can create an sdcard image.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/flashing.html#wwpID0E0HM0HA

Under the section “To generate an image to be flashed to an SD card”, it describes how to generate an image for the SD Card with whatever rootfs we have created.

What will happen this image is flashed to an USB drive and then try to boot it (maybe with or without sdcard ?). Will it boot like how it boots from an sdcard ?

(If needed I would edit the extlinux conf to set the correct root device)

12

Are you saying that you want to use etcher or dd to write this image directly to your usb drive and try to boot?

13

You can also refer to this post I just wrote to another user few days ago to understand some concepts about those boot from external device.

We didn’t try to flash sdcard image to a usb drive before, so I cannot give you a solid answer. But if you want to remove the sdcard and only let usb to do the work, you need to make sure usb is able to load the extlinux.conf on the usb but not the sdmmc.

14

Yes.

So my guess is if the bootloader on the QSPI of Nano is sort of independent then any image found on either sdcard or USB it shoud work (with exlinux.conf editing), unless there is some specific bootloader stuff (like a stage2) that is there on the APP that is specific to sdcard or USB.

Maybe only way is to try it out…

15

So now that I tried I can confirm that flashing the sd-blob.img to a USB drive also works. We only have to mount the image’s APP partition and edit the extlinux.conf and set root device to /dev/sda1. So this can be an alternative to people who want to move from an sdcard to USB

In my case I had created a custom rootfs starting with a ubuntu base and kubuntu-desktop installed on that. It boots the kernel and I get a login. I will have to continue the customization.

So I believe if I just used the sample rootfs of Nvidia I would have booted normally and got the setup and customisation screen

1 Like