How to build OS-image for Jetson Nano

Hello,
I am using Jetson Nano Developer Kit and i want to build it’s OS image from starting.
I tried to follow it’s manual where kernel customization was written but i am getting some problems regarding steps to be followed like from where to download pinmux script and where to put it similarly with other files and download ,how to interlink each files.Please enlighten us with proper steps to be followed to build OS image(e.g. how to download file where to put it how to use it and what to do to after that).

This probably is not what you had in mind, but a description of how the image is normally created during an ordinary flash might help.

JetPack/SDK Manager is just a front end to the actual flash software. The entire “Linux_for_Tegra/” content, other than the “Linux_for_Tegra/rootfs/”, is from the “driver package” (which is named this because it understands the recovery mode Jetson, a custom USB device in need of a driver). It is the driver package which performs the actual flash after a few steps with the “rootfs/”. Almost all of the image is from the “rootfs/”.

You can find the different L4T releases of the driver package here:
https://developer.nvidia.com/linux-tegra

If you were to look at each JetPack/SDKM release, then you’d find it associates with a specific L4T release.

If you were manually installing flash software to your host PC without JetPack/SDKM, then the procedure would go something like this:

  1. Unpack the driver package into an empty directory as a regular user (which creates a “Linux_for_Tegra/” subdirectory).
  2. Unpack the sample rootfs into the new “Linux_for_Tegra/rootfs/” directory as root/sudo.
  3. Go back to “Linux_for_Tegra/”, and overlay the NVIDIA-specific content into “rootfs/” via
    sudo ./apply_binaries.sh
  4. Flash with the correct target and other information using the flash.sh command.

Note that the sample rootfs does not have any proprietary content. The end user running apply_binaries.sh adds NVIDIA content through QEMU chroot into “rootfs/”. These steps need only be completed once. The image created is almost an exact copy of this content. The actual flash.sh command parameters will cause specific kernel and device tree setup and copy content into the rootfs/ which is for boot configuration. Then the image is generated which is an exact copy of this.

One of the best tools you can have to understand how to put things together is a boot log from a manual flash.sh flash. This will tell you which device tree and kernel was used for that specific category of flash. If you were to flash a dev kit Nano the command, if apply_binaries.sh were already performed, would go like this:
sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1 2>&1 | tee log_flash.txt

Then you’d be able to see the exact steps in log_flash.txt.

I have not set up a custom config, but look at the Linux_for_Tegra/ files, where some of these are “.conf” files named after the flash target named in the flash.sh command line. Inside this you will see it names a PINMUX_CONFIG and a directory. I think if you look at what you’ve created for any custom PINMUX (via the PINMUX spreadsheet macro), then this is how the PINMUX is integrated during flash. That boot configuration addition which occurs to rootfs/ during the actual flash.sh based on its command line arguments ties in with this.

If you go to the document downloads URL, and filter for Nano, then a set of documents will show up:
https://developer.nvidia.com/embedded/downloads#?tx=$product,jetson_nano

If you then search for “pinmux”, you’ll find an entry, “Jetson Nano Developer Kit Pinmux”. This is a spreadsheet, and if you enable macros, this is how you’d configure what you want by changing this and generating files. You would correlate what is generated to what the flash log used and you’d replace those files in the original “Linux_for_Tegra/” content with yours. Or you would create a new config for a target based on how the files would have been replaced.

Note: The same is true for a custom kernel, but you may have to manually copy in any modules to the rootfs/lib/modules/$(uname -r)/kernel/ if the “uname -r” changes.

Thank you so much for your help. i will surely inform you after if at all i get any further issues

Sorry to hijack this thread. But what if I do want to create an image out of the rootfs that is created following the documentation of Nvidia. I dont want to use flash.sh because i cant at the moment. I would like to create a .img file and flash it to an sdcard and check…

Thanks in advance…

Is the image on an SD card to start with? Then this is easy to do from another computer. If this is an eMMC model of Nano, then it isn’t so easy. Which model do you use?

I am using Jetson Nano B01. Yes I know I can flash a sdcard with the an image that Nvidia provides https://developer.nvidia.com/jetson-nano-sd-card-image using Balena Echter.

But here I want to make my own custom image and flash it. I have used the enter_chroot script to customize the rootfs. But I dont have a jumper that will enable me to enter recovery mode and flash in the usual way. So I would like to know how I can create an image file just like what Nvidia provides. Then I can flash that image on an sdcard and try.

For reference, keep in mind that anything shorting the recovery pin to ground during power start or power reset will do the job at putting the Jetson in recovery mode. The pins are not left shorted, but are instead shorted only at that power up/reset moment. Recovery mode is needed when using flash software from a Linux host PC.

You can use JetPack/SDK Manager to create an image on an Ubuntu 18.04 host PC. You can find the JetPack/SDKM versions here:
https://developer.nvidia.com/embedded/jetpack-archive

This should include the ability to create an image. For reference, running SDKM on your host PC creates directory “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/”. SDKM works as a front end to install flash software to the host PC, followed by actual flash (or creation of an image). Typically you’d run this once to install the software to host PC. You can find docs which then tell you how to flash. Some utilities are available which you might read about in the documentation for that specific release (the JetPack URL will list instructions for the SD card models).

Basically the image you use with Balena Etcher was originally created with the above named software.

I tried these steps which I found on the net, but no luck.
Anyway I will try to make an sdcard image.

Power down the Nano
Put the Nano into “recovery” mode.
    For revision B01, place a jumper wire across pins 9 and 10 of the button header (J50, underneath the heatsink module)
    For revision A02, place a jumper wire across pins 3 and 4 of the button header (J40, near camera header)
    Correct configuration for revision B01 is shown in the image below.
Connect the mini-USB cable from the Nano to your host machine.
Apply power to turn the Nano on.
After 3 seconds, disconnect the jumper wires.
Verify that the Nano is in recovery mode by executing lsusb on your host. You should see something like Bus 001 Device 011: ID 0955:7f21 NVidia Corp.

I used this SDKManager. It also seem to need the Jetson Nano in recovery mode I suppose. Because if I unselect the Target components (I am unable to unselect he Host components) then it proceeds to download the Host components and that it - it exits. Is this the default behavior when no target is connected.

For NVIDIA:
I dont have a way to unselect Host components.
Even after downloading them the tool downloads them again.
Thankfully there is an option to say only download and dont install.

So now what exactly should I so to create an image file ? Have I to use this tool itself and download the OS and drivers and rootfs with the tool, stop in between and customize the roofs and return back ?

So now I got the answer:

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.