Add Linux Module to TX2i

Hi,

I am trying to add a Linux module, specifically SLIP to the TX2i’s Ubuntu install, but I cannot get it to work properly. How would I do this during the initial build process since it seems like kernel configuration is out of our control?

Troubleshooting Steps Taken:
I first tried to see I could just add the module after the kernel having already being built using the source code for the TX2i’s OS…
I initially downloaded the Nvidia Tegra source (GitHub - OE4T/linux-tegra-4.9: Linux kernel source for NVIDIA Tegra (Jetson TX1, TX2, AGX Xavier, Xavier NX, Nano) in single-repo form, derived from the L4T BSP) to the TX2i, selected the SLIP module and compiled the modules. I tried to insmod the resulting slip.ko and it gave me the error:
insmod: ERROR: could not insert module slip.ko: Invalid module format
I then tried copying all of the headers currently installed on the TX2i into my build directory and tried again, and got the same error.
I am currently running the same Linux kernel as the Tegra download as reported by uname.
The only difference I see beeteween currently installed modules and the ones I produces is that:
#1 My compiler installed on the TX2i is 7.5.0 and the one used to create the image was 7.3.1
#2 When I type modinfo slip.ko the vermagic value is 4.9.253-g76839fee86ee-dirty SMP aarch64
And when I type modinfo on a module which was already installed I get vermagic: 4.9.253-tegra SMP preempt mod_unload modversions aarch64

I assume at this point I just need to create a new image with SLIP enabled from the start…

EDIT: The error says you did not compile the module with the correct architecture. Cross compile may have incorrectly compiled it for the host PC, or native compile may have accidentally said this is not a native compile.

Repeating here from a private message reply so everyone can see…

Sometimes there are so many replies I might lose one, but I don’t ignore people! :)

The goal is to get the kernel module file into the correct directory of the running Jetson, or else to the equivalent location of the flash software such that the file ends up in the correct place, but one would rarely flash the Jetson to get a file to it. Doing so is more for production, so assuming you have tested and want to make this part of the flash software, I’ll continue, but want to start by defining where that location is (it’s hard to go back and read everything already written, so sorry if you have seen all of this before).

Each kernel has a base version. Lots of releases now use kernel 4.9.230 (or close to that), while some of the newer releases now use the 5.x series. Within that there is the parameter used during compile, “CONFIG_LOCALVERSION”. The response to the command “uname -r” depends on those two things. If the CONFIG_LOCALVERSION is the default, then this was the compile parameter:
CONFIG_LOCALVERSION="-tegra"
…which results in “uname -r” responding as “4.9.230-tegra”. This is key to how the kernel finds its modules.

The kernel always searches for its modules at:
/lib/modules/$(uname -r)/kernel

Any copy of a module file to the correct subdirectory within “/lib/modules/$(uname -r)/kernel” will result in the kernel being able to find and use its module. The subdirectories of the module directory mirror where the module is built in the actual kernel source. As an example, I searched for where “CONFIG_SLIP” is located (which normally you don’t even need to think about), and as a subdirectory of kernel source, I see it configured in this directory (which is where it would end up when built):
drivers/net/slip/
…thus, if there is a new module “slip.ko” (it might actually be named a bit different), then on the running system where “uname -r” responds as “4.9.230-tegra”, then this would end up at:
/lib/modules/4.9.230-tegra/kernel/drivers/net/slip/slip.ko

One could merely copy the file to that location on the running Jetson (and perhaps reboot or run a command to refresh the module list) and it would work. Copy to the same subdirectory of the host PC’s “rootfs/lib/modules/4.9.230-tegra/kernel/drivers/net/slip/slip.ko” location would result in the file being in place after flash. Since the system is not actually running during flash it will boot for the first time and this will refresh the module listing, so there isn’t likely any reason to update the metadata files about modules present.

Keep in mind that this is constant, but if you were to replace the actual kernel Image file at “rootfs/boot/Image”, then things would not work correctly. This is because flash places what it thinks is the right Image file there each flash based on flash parameters (also in the partition…either Image location might be used depending on circumstances). Modules are left alone though.

If you have issues start by running the command “uname -r” to be sure you have the correct kernel running and module search location. If the location is wrong, then the module cannot be used.

If you still have troubles, then provide the error message when you try to update metadata via:
sudo depmod -a

I do hope to reply in the actual forum thread though so other people can use this. In a private message nobody else will see it. I do always read replies, but it might take me time to get to it, e.g., yesterday my credit card was stolen online and my account close to emptied (not that there was much there anyway), and one of my brothers died the week before so I have spent time helping my parents with that.

2 Likes

First of all, thank you for the detailed response!

I have compiled the module on the TX2i itself and verified that the files are the correct architecture. If native copmile said that this is not a native compile, this could be an issue causing the strange kernel name (4.9.253-g76839fee86ee-dirty)? I could be compiling for my own device and the device may believe that this compile is for another device and not the current TX2i OS? Is patching the binary with the correct kernel version an option?

Also, sorry for your loss.

I am going to guess that your compile specified “ARCH=arm64”. Although this is the correct architecture, you should not specify this if this is what you did. Even though this is the correct architecture it won’t work the way you think it does when you start adding in cross compile information. Did you set “ARCH” for native compile?

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