When developing on a Jetson Orin, you might need custom kernel modules or specific settings for your project. While NVIDIA recommends building on an x86 host, you can streamline the process by building directly on the Jetson itself. Here we discuss the essentials, from downloading sources to avoiding version mismatches, with practical scripts to simplify the task. Looky here:
Background
When you read the official NVIDIA documentation about building the kernel and modules from source, you are advised to build them on a x86 host machine. For a lot of developers and makers, this seems a little much. After all, you can build kernel and modules onboard most Linux machines, right?
As it turns out, you can build everything on the Jetson itself! The issue is deployment, which we’ll talk about a little later.
Backups of course
Before you start building, you’ll need a plan. Try to use as unmodified an environment as possible. Take into consideration that changes that you make are at a very low level in the machine. Those changes could break it.
You don’t want to work on a system that has all your work on it with no backup. Make backups (which I know you always do religiously, right?) if there are valuables on board. There is a great case for using a different storage device all together for working on new kernel components.
A big SSD can be useful for this task:
Useful Tool: NVMe to USB Docking Tool
Let’s get to building!
There are convenience scripts to help with the process on the JetsonHacks Github account in the Jetson-Orin-Kernel-Builder repository. This repository contains convenience scripts to simplify the process of:
Downloading Kernel and Module Sources (Board Support Package Sources – BSP)
Editing Kernel Configuration (Both GUI and CLI options available)
Building the Kernel Image
Building Kernel Modules (in-tree (tested) and out of tree (untested) )
These scripts help automate common tasks involved in kernel modification and module development on Jetson Linux 36.X.
These are well documented in the repository and video, let’s talk about a couple of more things you need to know.
Board Support Package (BSP)
The sources for the kernel, in tree modules and out of tree modules are located in the Jetson Linux Archive. We are currently working with Jetson Linux 36.4.3. You can get the sources in the Download and Links table in the Sources area. You want the Driver Package (BSP) Sources. The convenience script in the JetsonHacks repository will attempt to download the version that matches the version of JetPack that is on your machine.
After downloading, the script will decompress the sources into the /usr/src directory. This is the traditional Linux directory which the kernel source is placed. Be aware that it is in a system area, so you will need to use ‘sudo’ for most file operations.
Another task the script does is create a .config file from the running system. The .config file is a reflection of all the kernel and module settings of the system. The configuration is stored in /proc/config.gz.
Version Magic
If you are new to building kernels, you should know about Version Magic or vermagic for short. The kernel has a release associated with it, along with a local version. You can retrieve this using uname -r, an example would be 5.15.148-tegra.
The vermagic is stored in both the kernel and modules built against that version of the kernel. When the kernel loads a module, it checks to see if it has a matching vermagic. If it does, everything is happy. If not, it’s summarily rejected.
When you are building modules, people will forget to add the local version. This is kept in the .config file. Using a configuration editor (make menuconfig or make xconfig in the repository), you should set the local version. For 5.15.148-tegra, the local version is -tegra. The preceding dash should be present. Many people have forgotten the dash and spent a frustrating hunt trying to figure out what’s wrong.
Debugging
Because this is at a very low level in the system, it’s easy to muck things up. So much so that you may not have a reliable system. Follow the instructions in the video about setting up an alternate boot path, and make sure you have backups. You should be building on a clean system, with the least amount of work and customization on it.
If things really go south, you may need to use a serial debug console for debugging. See the article: Jetson Nano & NX Style – Serial Debug Console
In Tree, Out of Tree
When you first start working with the kernel, you’ll hear the term “in tree” and the corresponding “out of tree”. In tree refers to modules that are in the Linux source tree. Out of tree modules, on the other hand, are usually kept in different directories not related to the Linux source. You’ll notice the Jetson Linux BSP has the directory nvidia-oot where it keeps its out of tree modules.
Who’s this for?
As mentioned before, this is a suitable process for many developers and makers. Things get more complicated when you are using production features such as Secure Boot and Over The Air updates.
These require that the kernel be PKC Signed and/or have SBK encryption. To do that, you have to run a script on an x86 host. Also, the OTA places the kernels in different partitions on the drive other than the normal rootfs.
But production is much different than development, and in most cases we only need in-tree kernels or different flag settings in the kernel image for our projects. This is a good way to do that without having to fiddle with two machines.
Notes
In the video, we use a Jetson Orin Nano Super Developer Kit
We build a kernel for Jetson Linux 36.4.3, JetPack 6.2
Tested on Jetson Orin Nano Super and Jetson AGX Orin
The post Build Jetson Orin Kernel and Modules appeared first on JetsonHacks.
