Cross-compiling nvidia_kernel_display_driver_source.tbz2 for Orin devkit (r35.1)

My google-fu is failing me and am looking to the support folks here for help. Are there any guides available for cross-compiling nvidia_kernel_display_driver_source.tbz2 for the Orin devkit? I’ve recompiled my kernel & modules, and now my display is no longer functioning. It appears to be because I don’t have nvidia.ko in my modules list. Trying to do a quick & dirty copy of the original nvidia.ko is a fail (“modprobe: ERROR: could not insert ‘nvidia’: Exec format error”) likely due to a different toolset for compilation vs what I’m using. I’m using “aarch64-buildroot-linux-gnu-gcc.br_real (Buildroot 2020.08) 9.3.0”.

I grabbed nvidia_kernel_display_driver_source.tbz2 from public_sources.tbz2 and pointed TARGET_ARCH/CC/AR/etc to aarch64 & my cross-compilation tools. It looks like the build fails when it enters the “kernel-open” path. The Makefile in that path appears to reference my build machine’s kernel version, and not the one running on the Orin.

I could troubleshoot the Makefile in kernel-open, but figured I’d check here first in the event this is a known issue.

I don’t know about building the display driver, but “Exec format error” says this is the wrong architecture. The tool might exist, but either (A) the tool is not arm64/aarch64, or (B) it didn’t actually use the tool. During the kernel build did you actually specify “ARCH=arm64”? If you find the module in question, and if for example the file is “nvidia.ko”, then what do you see (from either PC or Jetson) for “file nvidia.ko” when at the file location?

@linuxdev I appreciate the response. I’m aware that the error message typically signifies a bad architecture build configuration, but that’s not the case here (my custom build works otherwise and I was simply referencing the original nvidia.ko file). I have not worked my way through rebuilding the driver from scratch, but I did notice that there is a mismatch with the ‘vermagic’ of the nvidia.ko and my modules / kernel build. I did not use for my custom build, so my version ends up as ‘5.10.104’ and not ‘5.10.104-tegra’. I believe this is the culprit.

I decided to rebuild things using Note once again that this does not include the /lib/modules/5.10.104-tegra/extra contents found in the out-of-the-box (OOB) install of r35.1. I deployed my rebuilt custom kernel and modules to the target and copied in the OOB extra folder over to my newly updated modules folder on the Orin. I updated modules.dep to reflect the contents of extra and ran depmod, and then rebooted. After boot-up, I was able to get the DisplayPort output working with my monitor to display the Ubuntu login screen. This was not working with my custom build and why I was trying to rebuild the driver in the first place. So, with a small bit of kludging, I’ve got things working to meet my needs.

I still think it would be good if someone from NVIDIA can point to build instructions for the Orin devkit for nvidia_kernel_display_driver_source.tbz2. Setting the cross-compile environment variables as mentioned in the that’s contained therein does not seem to be sufficient, unless I’m doing something else wrong.

You are correct that the “5.10.104” versus “5.10.104-tegra” can cause issues. Normally you’d start with a configuration which is an exact match to the current running system, and set “CONFIG_LOCALVERSION=-tegra” in order to complete the exact match. Then you’d configure to add whatever new module you are interested in (or perhaps add an integrated feature). After that I would expect the “nvidia.ko” module to be able to function with the new kernel, but if “uname -r” changes, then even with a copy of “nvidia.ko” it might fail. Still, this would not typically be an exec format error. It is not unusual that a difference in instructions between native and cross compiles get mixed up and cause problems though. Even specifying “ARCH=arm64” when using native compile can cause exec format errors despite being arm64, but lack of specifying “ARCH=arm64” during cross compile would also cause failure.

@linuxdev Thanks for the follow-up! I appreciate all your input. I’d have to say 9 times out of 10 when I’m searching for help on this site, I ended seeing something from you that clarifies things for me. You are a rock star. :)

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