How to build kernel with additional features enabled and flash it to Nvidia AGX Orin dev kit

[pankaj.bharti1]

I am trying to recompile kernel with release version 36.4.0 and jetpack version 6.1.
I am unable to find clear steps to do so in developers guide. Can someone enumerate exact steps that I need to follow? I am able to do this with native compilation on AGX Orin 64 Dev kit. I wanted to know the host-based compilation steps.

[linuxdev]

Incidentally, the docs at your L4T release (R36.4.0) will have a “kernel customization” section. This is the section you want for cross compile and adding the new kernel to the flash content. L4T release URLs:
https://developer.nvidia.com/linux-tegra

[pankaj.bharti1]

I have followed below steps on another of my jetson Orin box with jetpack version 5.1.2-b104 and kernel L4T 35.4.1.

SOURCES=$(pwd)/kernel_src

TEGRA_KERNEL_OUT=$(pwd)/kernel_build/jetson_linux_35.4.1_image
KERNEL_MODULES_OUT=$(pwd)/kernel_build/jetson_linux_35.4.1_modules

mkdir -p $TEGRA_KERNEL_OUT
mkdir -p $KERNEL_MODULES_OUT

Start with default kernel config currently running on board.

make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra tegra_defconfig

Enabled vrf module in kernel config

make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra menuconfig
make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra -j$(nproc) Image
make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra -j$(nproc) dtbs
make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra -j$(nproc) modules_prepare
make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra -j$(nproc) modules
make -C $SOURCES/kernel/kernel-5.10/ ARCH=arm64 O=$TEGRA_KERNEL_OUT LOCALVERSION=-tegra INSTALL_MOD_PATH=$KERNEL_MODULES_OUT modules_install

After this since I just need to add vrf.ko to my running machine, if I try to do insmod for vrf.ko I get following warning message in dmesg:

[36636.264626] audit: type=1400 audit(1733756593.932:44): avc: denied { module_load } for pid=312101 comm=“insmod” path=“/home/orin14/nvidia-jetson-source/Linux_for_Tegra/source/public/kernel_build/jetson_linux_35.4.1_module/lib/modules/5.10.120-tegra/kernel/drivers/net/vrf.ko” dev=“mmcblk0p1” ino=2512570 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=system permissive=1
[36636.271564] vrf: module verification failed: signature and/or required key missing - tainting kernel

Any idea how to fix this warning or avoid this message without replacing the existing kernel ? The kernel module is loaded though and available for use.

[linuxdev]

If you are natively compiling, then typically you should avoid naming the ARCH. For directly/natively building a kernel on the Jetson I would avoid this (but this isn’t the issue):
ARCH=arm64
(it is true that this ARCH is correct, but sometimes an explicit naming will also tell the build system that you need a cross compiler; there might be changes you don’t expect)

Warnings from avc audit like this are SElinux. It is possible to have SElinux with only a warning level set, but I have other suspicions about the build process perhaps mixing to cause the error.

First, you might want to install package selinux-utils:
sudo apt-get install selinux-utils

Some questions to answer:

• How did you configure kernel options before you reached the actual kernel compile step? The default options have changed when going from L4T R35.x to R36.x (because R36.x uses mainline kernel). It used to be “tegra_defconfig”, but in R36.x it should be “defconfig”. If you used tegra_defconfig, then this probably did something with SElinux that you don’t want (but perhaps default is to enable SElinux).
• Run “getenforce”. What do you see? If this is enforcing, then keep going with the check list below:
  • What is the output from “uname -r”?
  • What is the output from “zcat /proc/config.gz | grep -i 'selinux'”
  • What is the output from “cat /proc/cmdline”?

There are ways to keep the SElinux ability without enforcing it. This includes booting with the feature disabled, and it also includes treating the feature into a warning instead of enforcing. Policies themselves can be modified, and individual files can have labels set up. I will suggest though to start with the above and let’s see what is currently configured.