If you cross compiled you may have created something for the desktop PC architecture, and not for the Jetson’s 64-bit ARM architecture. On your host PC, if you find the Image file you used, what do you see from: file Image
(it is the ARM designation we are looking for, usually listed as “Aarch64”; any mention of x86/amd64/x86_64 implies failure is guaranteed)
Thanks for your advice. I think that it may be due to the fact that the cross-compile framework does not export LOCALVERSION or the CONFIG_LOCALVERSION in the kernel defconfig is not set to “-tegra” while all the previous kernel modules (as well as the newly compiled nvgpu.ko) are found in /lib/modules/5.10.104-tegra.
If CONFIG_LOCALVERSION is wrong, then 100% of all modules must be put in to the new module location. If your new kernel only changes modules, then you would want to keep the original -tegraCONFIG_LOCALVERSION. If your new kernel changes integrated features, then you want a new CONFIG_LOCALVERSION (this does not mean empty, but it does mean something other than -tegra). I’m not sure this would result in an exec format error, but it might.
With your new kernel running, what do see from “uname -r”? Modules would need to be located at: /lib/modules/$(uname -r)/kernel/
You failed to set CONFIG_LOCALVERSION. This serves as the suffix to the command “uname -r”. If your kernel release is 5.10.104, and you have no CONFIG_LOCALVERSION, then “uname -r” is “5.10.104”. If CONFIG_LOCALVERSION is “-tegra”, then “uname -r” becomes “5.10.104-tegra”. The first issue is that none of your drivers that are modules can be found.
The second issue is that sometimes versions, and the specification of versions, matter. If you simply moved (or used a symbolic link) the -tegra content to a 5.10.104/ directory, then some or all of the modules would still fail to load.
The question becomes “what to do for CONFIG_LOCALVERSION”? If you are building a full kernel, and if the integrated features (meaning “=y”) do not change, but the modular features (meaning “=m”) change, then you would want the same “uname -r”. You’d avoid copying the kernel Image (the integrated features file), and copy only modules to the existing “/lib/modules/5.10.104-tegra/kernel/” location (the proper subdirectory thereof).
If you intend to compile with different integrated features (a change to “=y” content), then you would want a new “uname -r”, which means you set a CONFIG_LOCALVERSION, but you use an alternate name. An example would be “-test” or “-new”. Often I name the CONFIG_LOCALVERSION after something the new feature provides. For example, if I add some iSCSI feature, maybe I would name it “CONFIG_LOCALVERSION=-iscsi”. This does not mean you wouldn’t start with a config that matches the original kernel, but it does imply something “=y” changed. In this case then you would install the kernel Image file itself and all modules to the new location of “/lib/modules/5.10.104-test/kernel/”.