Jetpack-5.0.2 - Kernel Customization - How to update loadable kernel modules?

[khang.l4es]

Dear Community,

I follow the instructions in this link to cross-compile the kernel of my custom board : Kernel Customization — Jetson Linux<br/>Developer Guide 34.1 documentation

So far, I finished “Building the Kernel” session using nvbuild.sh script and have up-to-date Image, device-trees and nvgpu.ko at following locations :

kernel_out/arch/arm64/boot/Image
kernel_out/arch/arm64/boot/dts/nvidia/tegra194-p3668-0001-p3509-0000.dtb (this includes custom .dtsi)
kernel_out/drivers/gpu/nvgpu/nvgpu.ko

For my manual flashing method, I will update above files in /path_to/SDK_downloads/JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/

// Image
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/kernel/Image

// dts - not sure which one is the most important
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/rootfs/boot/tegra194-p3668-0001-p3509-0000.dtb
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/rootfs/boot/kernel_tegra194-p3668-0001-p3509-0000.dtb
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/kernel/dtb/tegra194-p3668-0001-p3509-0000.dtb // probably only this one needs to be overriden
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/bootloader/kernel_tegra194-p3668-0001-p3509-0000.dtb
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/bootloader/tegra194-p3668-0001-p3509-0000.dtb
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/bootloader/temp_user_dir/kernel_tegra194-p3668-0001-p3509-0000.dtb

// nvgpu.ko
JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/rootfs/usr/lib/modules/5.10.104-tegra/kernel/drivers/gpu/nvgpu/nvgpu.ko

However I wonder how to update the loadable kernel modules to above target folder (JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/rootfs/usr/lib/modules/5.10.104-tegra/) :

Should I generate the kernel_supplements.tbz2 from the custom kernel which is currently cross-compiled and replace it in target folder /path_to/SDK_downloads/JetPack_5.0.2_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/kernel/kernel_supplements.tbz2 ? The step of “archiving the installed kernel modules” in the link of instructions seems to be done within running target system :

$ cd <modules_install_path>
$ tar --owner root --group root -cjf kernel_supplements.tbz2 lib/modules

How to do that in host system with cross-compilation?

And should I execute the apply_binaries.sh script with up-to-date files from custom kernel before the flashing ? The NVMe flashing method I am going to follow is found here : JetPack-5.0 Installation to M.2 SSD for DSBOX-NX2

Thanks in advance and best regards,
Khang

[linuxdev]

This has things in it which you are not asking about, but would be useful to understand if you are manually adding modules or kernels:
https://forums.developer.nvidia.com/t/problem-smb-jetson-nano/193640/11

Perhaps one of the most important points is that each kernel is responsible for the output of the command “uname -r”. That command determines where the base of the modules are loaded from. Basically:
/lib/modules/$(uname -r)/kernel

Within that, let’s say that the kernel source has a driver “$TOP/drivers/imaginary/foo.ko”. That means you’d copy the file to:
/lib/modules/$(uname -r)/kernel/drivers/imaginary/foo.ko

If you did not set the CONFIG_LOCALVERSION correctly, then you’ll have to reinstall all modules to a new “uname -r” directory tree.

If you only added new modules to the configuration, then you can normally reuse the same “uname -r” (CONFIG_LOCALVERSION). If you’ve changed an integrated feature (not a module), then it is possible you must rebuild and install all modules (compatibility of modules is not guaranteed if you did more than add or remove modules).

Note that depending on circumstances sometimes boot will be from a kernel partition, but in many other cases it will use the location named in “/boot/extlinux/extlinux.conf” for the kernel Image file. It isn’t always necessary to flash. Additionally, if hardware has not changed for non-plug-n-play content, then you also wouldn’t need to change the device tree.