Cli equivalent to sdkmanager usage for flashing a jetson Orin NX

Hello experts,

I can flash my custom Orin NX board if I use the sdkmanager in GUI mode. My board is recognized as ‘Jetson Orin NX modules’ either with a Jetson Orin NX 8GB or Jetson Orin NX 16GB, depending on the SOC I plug on it. I can flash it perfectly with ‘Jetpack 5.1.2’ and ‘NVMe’ as ‘Storage Device’.

Now we plan to produce many of those boards, and using a GUI to flash them will become tiresome and error-prone.

What is the command-line equivalent (using e.g.) to flash that board ?


sudo ./tools/kernel_flash/ --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --showlogs --network usb0 jetson-orin-nano-devkit internal

OK Thank you, but …
previously it was possible to create a file named ‘myboard.conf’ and then run something like

sudo ./ myboard nvme0n1p1

Is that deprecated, or not supported anymore ? only supports eMMC/SD card, but not NVMe drive.

1 Like

OK Thank you

How can I add the pre-config (user and password) options to the command line ?

You have to run this script before flashing:

1 Like

OK that works !

I have found how to specify the board specific PINMUX_CONFIG, PMC_CONFIG and DTB_FILE, but how can I specify the kernel that must be run after the installation ?

You mean you want to replace the kernel image at runtime?

Yes, I want to run a self-compiled kernel tailored for the board, with additional drivers. This kernel is tested and runs perfectly if installed instead of the default kernel afterwards, but I would like to install it at the flashing time.

Replace Linux_for_Tegra/boot/Image with your own kernel.

Will Linux_for_Tegra/boot/Image be run during the flashing process ? If yes, are there any driver or config options that must be provided by that kernel ?

I don’t really know what your question is.
What is your config/driver here?

Is Linux_for_Tegra/boot/Image used in the flashing process or merely copied into the NVMe and run only after the final reboot ?

If it is merely copied into the NVMe and run only after the final reboot, ignore my next question :)

If it is run during the flashing process, e.g. to provide initrd or usb gadget support, then which menuconfig option should I take care to preserve while configuring my linux kernel before compilation, to avoid breaking the flashing process ?

PS: actually there is no Linux_for_Tegra/boot/Image. In Linux_for_Tegra there are only rootfs/boot/Image and kernel/Image. If you meant rootfs/boot/Image, please ignore my question.

YES. It’s used in the flashing process.

You just don’t disable configs that you are not fully familiar with, especially regarding USB and RNDIS.

Oh YES, I mean Linux_for_Tegra/kernel/Image.

I copied my kernel Image to kernel/Image but the flashing process did not terminate successfully. Here are its last words :

cp: cannot stat '/home/phdm/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NX_TARGETS/Linux_for_Tegra/rootfs/lib/modules/5.10.120-00303-g49d2b8514377-dirty/kernel/drivers/mtd': No such file or directory
Cleaning up...

I investigate.

How did you build kernel modules?
How are you getting these kernel string 00303-g49d2b8514377-dirty?
Are you doing it intentionally?

the hash in the name is intentional, the dirty is not. I always compile the linux kernel for embedded computers like here with all the needed drivers builtin, so that I have only one file to copy, backup etc .

I found the failing command in tools/kernel_flash/

I’ll try to bypass it and its friends.

OK, so if you make sure every drivers are built-in, then you can safely remove that code from the script.
But you’d like to be careful that the same thing will no longer work if you move to JetPack 6, as we pull a lot of NVIDIA’s custom device drivers out of the kernel source tree, and make them external modules.

I know. I already asked for that feature to come back. See JetPack 6.0 Developer Preview - Release Announcement - #37 by phdm

Looking only at the flashing process, it would be useful to be able to install a different kernel for runtime than the one used for the flashing process itself.