TX1 fails to create .ko file

Dear All,

I am using Tegra TK1 and Tegra TX1… While moving from TK1 to TX1 i faced this issue…

I have a PCAN package which compiles .c files using GCC and created one .ko file which i insert using insmod command…

This process worked well with Tegra TK1 and it created .ko file successfully.

But when i am trying to follow the same procedure with Tegra TX1 i am not able to compile .c file using default GCC available on TX1 and .ko file is not getting generated…

What could be issue here with TX1 compiler and A57(TX1) vs A15 on Tegra TK1…forums around here says on TX1 kernel is 64 bit and user space is 32 bit .so how do i create .ko file on TX1.

Any input is highly appreciated.

Because the JTX1 user space is 32-bit, the kernel is 64-bit, this is best done cross-compiling (there will probably be a purely 64-bit release in a few more months). If your host is Ubuntu I think you can just install cross-compilers via the package manager (I use Fedora, not sure what the Ubuntu packages are). I use the Linaro compilers here:
https://releases.linaro.org/components/toolchain/binaries/

I suggest from that link “Latest-5.2”. Packages:

gcc-linaro-5.2-2015.11-1-x86_64_aarch64-linux-gnu.tar.xz
gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf.tar.xz

When you unpack the driver package you get some documents with it describing commands. A short excerpt (example only, will need to edit for your environment):

export CROSS_COMPILE=/your/path/to/gcc-linaro-5.2-2015.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export CROSS32CC=/your/path/to/gcc-linaro-5.2-2015.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
export TEGRA_KERNEL_OUT=/home/your/path/to/output/kernel/stuff/build
export ARCH=arm64

A quick note on “TEGRA_KERNEL_OUT”…the compile output location can be used on most all kernel compile commands, including make mrproper, make menuconfig, make tegra21_defconfig, make modules, so on. Don’t forget to use this on all of the commands. Documentation also mentions a module output directory similar to TEGRA_KERNEL_OUT.

Thanks for your response…

I am trying to cross compile it now on ubuntu 64 bit 12.04 host … I installed aarch64 gcc and g++ from synaptic package manager.

I have two following queries :

  1. Do i need to cross compile linux kernel also for TX1, to generate ko file on ubuntu host ?

  2. While building PCAN package i faced -lpopt library is missing so will i have to cross compile this libpopt for aarch64 ?or i can directly use libpopt.so compiled for x86_64 host ?

From your above statement, user space is 32 bit does it mean my all user space applications compiled by GCC would be 32 bits ?
Then will I not be able to take advantage of A57 being 64 bit processor as compare to 32 bit processor ?

The .ko files are the modules…they are part of the kernel like any other part, except they can be loaded and unloaded while running. The make modules part creates those. If you enable the right repository (I don’t know which it is), then probably the popt lib will be installable via package manager. If for some reason you must compile the lib itself, then you could do this directly on the JTX1 using the 32-bit compiler.

Everything done in kernel space takes advantage of 64-bit. Applications in user space will all be 32-bit until the future update comes out which will make everything 64-bit.

Yes Thanks for your response. I got it.

I appreciate your support…

One question is regarding what is the difference between gcc-linaro-5.2-2015.11-1-x86_64_aarch64-linux-gnu and gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf package ??

I can see aarch64-linux-gnu-g++ inside gcc-linaro-5.2-2015.11-1-x86_64_aarch64-linux-gnu and arm-linux-gnueabihf-g++ inside gcc-linaro-5.2-2015.11-1-x86_64_arm-linux-gnueabihf.

Then which version of g++ should i use to cross compile??

similarly gcc is also available in both packages which one should be used ?

and which headers should i use from both the packages as i am getting fatal error: stdio.h: No such file or directory error…

The aarch64 is 64-bit, the gnueabihf is 32-bit (hard float calling convention). For cross-compile of user space apps, use the 32-bit gnueabihf, regardless of whether it is gcc or g++.

As for the header errors, you will need to set up a complete cross-compile environment to do this. The kernel is independent of all kinds of files needed in user space…the kernel is the start of everything, it does not require any user space support, everything else does (the kernel is the simplest cross-compile you will find). There are other tool chain packages which can be downloaded to provide all of that infrastructure, I typically just use a clone to guarantee everything matches (loopback mounted and special effort adding symbolic links in the right place). If you compile directly on the Jetson, you can skip all of that and it becomes a non-issue (recommended).

For people who must cross-compile user space apps, note in the Linaro releases a “runtime-linaro-…” and a “sysroot-linaro-…”. That is what those files are for. Installing these properly on an x86_64 host has a significant learning curve. I would recommend compiling directly on Jetson.

To clone a JTX1 see this:
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149

@KapilMehta, I had a similar problem with my linaro toolchain. The tools don’t seem to know where its own header files are. There’s a missing folder in the path where it thinks they should be. Do an
aarch64-linux-gnueabihf-g++ -print-sysroot

and you’ll see what I mean. The kernel build seems to be accomodating this by using a ‘-isystem’ option in its build. I ended up adding symlinks in the /aarch64-linux-gnu/libc folder to point to the etc, lib, sbin, usr, and var folders that are one more level down.