Insmod - Invalid format

Hello all,

I’d like to build a custom module on the Nano board itself by following below steps :

sudo ln -s /usr/src/linux-headers-4.9.140-tegra-ubuntu18.04_aarch64/kernel-4.9 /lib/modules/4.9.140-g8368ac5/build

hello.c :

/*  
 *  hello-1.c - The simplest kernel module.
 */
#include <linux/module.h>       /* Needed by all modules */
#include <linux/kernel.h>       /* Needed for KERN_INFO */

int init_module(void)
{
        printk(KERN_INFO "Hello world 1.\n");

        /* 
         * A non 0 return means init_module failed; module can't be loaded. 
         */
        return 0;
}

void cleanup_module(void)
{
        printk(KERN_INFO "Goodbye world 1.\n");
}

Makefile :

obj-m   += hello.o
  
hello:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

The module gets compiled well :

-rw-rw-r-- 1 toto toto    445 Thg 3 13 14:46 hello.c
-rw-rw-r-- 1 toto toto 196064 Thg 3 13 15:13 hello.ko
-rw-rw-r-- 1 toto toto    336 Thg 3 13 15:13 .hello.ko.cmd
-rw-rw-r-- 1 toto toto    762 Thg 3 13 15:13 hello.mod.c
-rw-rw-r-- 1 toto toto 102032 Thg 3 13 15:13 hello.mod.o
-rw-rw-r-- 1 toto toto  29139 Thg 3 13 15:13 .hello.mod.o.cmd
-rw-rw-r-- 1 toto toto  96848 Thg 3 13 15:13 hello.o
-rw-rw-r-- 1 toto toto  29340 Thg 3 13 15:13 .hello.o.cmd
-rw-rw-r-- 1 toto toto    160 Thg 3 13 15:10 Makefile
-rw-rw-r-- 1 toto toto     64 Thg 3 13 15:13 modules.order
-rw-rw-r-- 1 toto toto      0 Thg 3 13 15:13 Module.symvers
drwxrwxr-x 2 toto toto   4096 Thg 3 13 15:13 .tmp_versions/

But I get following error when trying to insert it :

insmod: ERROR: could not insert module hello.ko: Invalid module format
$ file hello.ko 
hello.ko: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), BuildID[sha1]=44c6a16f51b7911c767f1ab9e5806a6ee03fd7f0, with debug_info, not stripped

I’d like to know if the above approach is possible since I found other approach to recompile and flash the whole kernel rather than individual module. For example, following thread said that similar approach on TX1 was no applicable :

https://devtalk.nvidia.com/default/topic/929186/jetson-tx1/jetson-tx1-kernel-compilation/

Thank you in advance,
Khang

On a native compile there would be no need to set CROSS_COMPILE, ARCH, or CROSS32CC. If one of those were set, then the inherited environment might have done something odd. Another reason this might happen is if the headers are mismatched, or perhaps you needed some config.

You might find this of interest since full source install followed by config would guarantee using the right source release version:
https://devtalk.nvidia.com/default/topic/1051980/jetson-tx2/how-to-upgrade-linux-headers-4-4-38-tegra-to-latest-kernel-and-headers/post/5339991/#5339991

In the case of downloading kernel source via source_sync.sh for R32.3.1 (JetPack4.3) you would use this (the other URL will mention source_sync.sh, the tag is currently “tegra-l4t-r32.3-1”):

./source_sync.sh -k tegra-l4t-r32.3-1