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.