How to cross compile kernel module for real-time kernel on xavier

I use this command to recompile the kernel on xavier.

 ./scripts/rt-patch.sh apply-patches

the kernel version is :

Linux nvidia-desktop 4.9.140-rt93-tegra #1 SMP PREEMPT RT Wed Jan 12 12:06:21 CST 2022 aarch64 aarch64 aarch64 GNU/Linux

but when I cross compile my kernel module the modinfo is:

vermagic:       4.9.140-tegra SMP preempt mod_unload modversions aarch64

the module version is different from real-time kernel while the module work well for the non-RT kernel.

I find some original modules in RT-kernel, the modinfo is:

vermagic:       4.9.140-rt93-tegra SMP preempt mod_unload modversions aarch64

So how to cross compile kernel module for RT kernel on xavier?

Do I need to get the real-time kernel headers?

Have check below document to build the kernel module again.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/kernel_custom.html#wwpID0E0WD0HA

Hi ShaneCCC:

I followed this doc, and the our own kernel module work well for 4.9.140-tegra.

when the kernel module is rebuild on 4.9.140-rt93-tegra, the module vermagic still is 4.9.140-tegra.

when I build RT-kernel, there are two folder in rootfs/lib/module

so I want to know how to cross-compile the kernel module when the RT-kernel.
I want to konw if there special RT-kernel headers for RT-kernel.

Hi,

Sorry that I don’t quite understand what is the problem here. So your kernel modules are failed to get loaded with modprobe and insmod?

yes, it can’t be loaded, because the kernel module version is different from the RT-kernel version.
when modprobe:

disagrees about version of symbol module_layout

Sounds weird, what is your “uname -r”?

Also, just let you know, cross compile is the default method we suggest customer to do. And the method is shared by ShaneCCC in previous comment.

uname -r

4.9.140-rt93-tegra

our own module: modinfo:

vermagic:       4.9.140-tegra SMP preempt mod_unload modversions aarch64

I konw the cross compile method, our own module have worded for a while. but my leader want to change the kernel to RT-kernel

Hi,

This sounds like a bug. But we don’t debug for old kernel, is it possible to check this with jetpack 4.6?

Jetpack 4.4 is the released version. We use it on our own board. It takes too much time to change version. Maybe I will test on the xavier board.

Not an answer, but I suspect your configuration was not propagated, so some details for clarity…

When a kernel is built it has a base version, e.g., 4.9.140. There is a parameter in the “.config” file, “CONFIG_LOCALVERSION”. This is appended to the base version and creates the “uname -r” content. Examples:

  • If CONFIG_LOCALVERSION="-tegra", then uname -r is “4.9.140-tegra”.
  • If CONFIG_LOCALVERSION="-rt93-tegra", then uname -r is “4.9.140-rt93-tegra”.

However, keep in mind that different components may not see the propagation of the “.config” file unless proper steps have been taken. Whenever you build the main kernel (even if you don’t use it) all components will have the full “.config” propagated throughout the build. On the other hand, if you don’t build the “Image” (full kernel), then things which have changed in the “.config” might not be updated. Thus, if you’ve started with a clean build, and wish to build a module without building the kernel Image, one way to get the “uname -r” updated to the module is:
make modules_prepare
(keep in mind that if you’ve used other options, e.g., an alternate output location, then you have to use that as well, e.g., "`make O=$TEGRA_KERNEL_OUT modules_prepare)

To completely clean kernel source you’d use “make mrproper” (if you used an alternate location for output, then bothmake mrproperandmake O=$TEGRA_KERNEL_OUT mrproper” would be a good idea)

Do beware that if you run mrproper, then your .config file will also be erased. So if this is what you want to build, then be sure to save a copy in a safe location so you can then just copy it back to your output directory. Then run the modules_prepare.

finally, I know the answer. the kernel headers version need to change to rt93.

image

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.