JETPACK IMAGE Apply dtb, driver

[rlatae123]

Hello.

We are downloading the official image(sdk manager) and trying to apply our custom dtb and driver(.ko).

our dtb will be changed using extlinux.conf and apply using insmod driver file

When proceeding as above, DTB worked normally, but the application of the driver file failed.

apply driver command insmod

insmod: ERROR: could not insert module my_module.ko: Invalid module format
dmesg error : disagrees about version of symbol module_layout

I’m customizing the kernel r35.1, JetPack 5.0.2.

$ uname -r
5.10.104-tegra

$ modinfo my_module.ko
vermagic: 5.10.104-tegra SMP preempt mod_unload aarch64

The only difference between the existing official image driver file and the user custom driver file is the signature item. ex) sig_id, signature . . .

Could this have something to do with it?

[rlatae123]

@WayneWWW

After downloading the official image and flashing it, I checked the module information of nv_ar0234.ko.

And After downloading the custom kernel through source_sync.sh and building it, I checked the nv_ar0234.ko(no modify) module information.

use modprobe --dump-modversions

official image nv_ar0234.ko
module_layout = 0xd31aec96

custom image nv_ar0234.ko
module_layout = 0x30527249

It seems that insmod doesn’t work because of this. Can you tell me why module_layout is different?

[WayneWWW]

This module needs to build based on the same kernel image.

[rlatae123]

what means “same kernel image”

host PC or L4T?

[WayneWWW]

You need to (at least) align the kernel version and also use same host/device to build the kernel and ko files.

For example, you cannot just use a random ko files from Internet and expect it would work for your kernel.

[rlatae123]

I tested Official Jetpack image version 5.1 - l4t 35.1(5.10-104)
command flash : sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1

And I use command “./sourse_sync.sh -k 35.1” in Official Jetpack image and build kernel
commang build :
make clean & make mrproper
mkdir -p $KERNEL_OUT
make ARCH=arm64 O=$KERNEL_OUT tegra_defconfig
make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=${CROSS_COMPILE} -j12
sudo make modules_install ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=${CROSS_COMPILE} INSTALL_MOD_PATH=$KERNEL_MODULES_OUT INSTALL_MOD_STRIP=1

Are you saying that the official image kernel version and the kernel version downloaded through source_sync are different?

Or is it because the official image build environment and the build environment I’m using are different?

[WayneWWW]

Are you sure the kernel image loaded by the board and kernel modules loaded by the board are really the ones you built out?

[rlatae123]

Actually I’m not sure if it’s accurate

Is there any way to check?

I just want to put our camera driver on the official image without building it.

[rlatae123]

I just tested it on 4.6.1 using the same build method and insmod works fine.

I want to apply the same way to 5.0.2

[rlatae123]

I have question Wayne.

Is it normal to see something like this when building a kernel?

So far, we have proceeded with the default value, but when we changed the GCC_PLUGIN setting to N, the module_layout value became the same as the official image. and work insmod well

[rlatae123]

@WayneWWW

I saw the following in the guide document, and if you proceed as follows, you can upload our kernel to the official image and use it?

[WayneWWW]

The method to replace kernel is put it into Linux_for_Tegra/kernel/Image and do full flash.

The method to update ko files is install it to the rootfs/lib/modules.

When you change the kernel image, you need to update the modules built from the same kernel too. That is the principle here.

Make sure you’ve done this.

[rlatae123]

Thanks for the answer, I will definitely do it

I have one more question before proceeding.

We have camera_common.c, sensor_common.c, vi5

corrected c. If I proceed as I posted before, will the content of the modified file be applied?