Hi
I just received Jetson Tx1 with jetpack3.0 (kernel 3.10).
I would like to compile the kernel .
I verified the doc shared by Nvidia . Its giving error .
Is there any way to compile “L4T 27.1 Sources” for jetson TX1 ???
Can anybody help me ?
Thanks & Regards
Raghu Ramaraj
More detail is needed on the kernel build. I assume you are cross compiling on an ordinary PC host. What are your 32-bit and 64-bit tool chains? Are they the ones provided in the L4T documentation? Was your kernel config from your running system’s “/proc/config.gz”? Can you give more information on the error?
Also, I don’t believe that L4T 27.1 is the correct match for the Jetson TX1. The current release is L4T 24.2.1 as I recall.
I am using 64 bit Ubuntu & 64 compiler .
I gave the following commands to build
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- clean
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- mrproper
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- tegra21_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage
& error logs…
jetpack3/Linux_mydownload/sources/kernel/arch/arm64/include/asm/unistd32.h:240:0: note: this is the location of the previous definition
#define __NR_fstat 108
^
CC arch/arm64/kernel/signal32.o
CC arch/arm64/kernel/sys_compat.o
LDS arch/arm64/kernel/vdso32/vdso32.lds
VDSO32C arch/arm64/kernel/vdso32/vgettimeofday.o
/bin/sh: 1: -Wp,-MD,arch/arm64/kernel/vdso32/.vgettimeofday.o.d: not found
/home/philips/jetpack3/Linux_mydownload/sources/kernel/arch/arm64/kernel/vdso32/Makefile:38: recipe for target ‘arch/arm64/kernel/vdso32/vgettimeofday.o’ failed
make[2]: *** [arch/arm64/kernel/vdso32/vgettimeofday.o] Error 127
scripts/Makefile.build:455: recipe for target ‘arch/arm64/kernel/vdso32’ failed
make[1]: *** [arch/arm64/kernel/vdso32] Error 2
Makefile:808: recipe for target ‘arch/arm64/kernel’ failed
make: *** [arch/arm64/kernel] Error 2
This is error logs are related to L4T 24.2.1 source only …
Information: The 27.1 kernel does not currently run on a JTX1. NVIDIA did state that at some future release a version 4.x kernel would be made available on the JTX1 (no mention of release date was given).
For information on R24 builds see:
[url]https://devtalk.nvidia.com/default/topic/936880/jetson-tx1/jetson-tx1-24-1-release-need-help-with-complier-directions-can-not-complie/post/4885136/#4885136[/url]
gettimeofday must be compiled as 32 bit, which means that your compiler chain is not correctly set.
you mean to say , we need 32 bit as well as 64 bit compiler to build L4T 24.2.1 source ?
Is it available @https://developer.nvidia.com/?
Now i can able to build using both 64/32 bit compiler . Can you guide me to flash/update with new kernel,module images ?
Since U-Boot is the boot loader you never need to flash to update kernel or modules. More on that further below.
One thing I would caution to double check on before putting too much effort into any kernel install is if you had correctly set the CONFIG_LOCALVERSION. To match the default kernels this tends to need to be set to “-tegra”. On your running install if you use the command “uname -r” this shows a version…the suffix of that is the CONFIG_LOCALVERSION. When a kernel searches for its modules it uses the “uname -r” to name a subdirectory of “/lib/modules/”…if not set correctly, then the modules won’t be found…or perhaps modules will be rejected if found and not compiled with the right CONFIG_LOCALVERSION.
If you started with a kernel config from “/proc/config.gz”, then you know your kernel you’ve just built is an exact match to the kernel which is running (provided you set CONFIG_LOCALVERSION)…thus you know any modules you’ve built are compatible with the running kernel. So assuming you’re new build only adds modules and does not change the base kernel the only thing you need to do is copy modules to the right part of “/lib/modules/uname -r”. You’ll probably be able to figure out which subdirectory of that to place the modules in, but ask if you need.
So far as kernel install goes, look at file “/boot/extlinux/extlinux.conf”. There is a key/value pair “LINUX”, and the value names where the kernel is to be located…copy of a file here to that name installs the new base kernel. Don’t update the Image unless you’ve changed a base feature of the kernel (changs to something compiled directly in to the kernel and not as a module would need a new “uname -r”…a new CONFIG_LOCALVERSION…and then you have many more steps). For safety’s sake, if you have a serial console, then you can just add an alternate entry to extlinux.conf and keep the original boot entry. I also recommend never destroying the original Image or its support files…you can use extlinux.conf to use alternate names, e.g., you could copy the new Image to “/boot/Image-custom”.
So the question is if you’ve only added new modules, or if you had to change a feature of the kernel which is built in to it? Assuming it was just modules, then you just copy the module as noted above and perhaps run “sudo depmod -a” and you’re done. No flash.
Hi ,
i would like to add only one module with kernel . For that ,i need to build the entire kernel …right .
Guide me to get the working kernel with new module . what is the procedure to update the kernel/dependencies?
Although I recommend reading this, you don’t need as many steps for just a module:
https://devtalk.nvidia.com/default/topic/936880/jetson-tx1/jetson-tx1-24-1-release-need-help-with-complier-directions-can-not-complie/post/4885136/#4885136
For just a module addition, first make sure you’ve made any bug edits listed in that URL, and that CONFIG_LOCALVERSION is set. Make sure your kernel config is an exact match of the running kernel.
I recommend building it all for error checking, but you could do this for just a module:
make modules_prepare
make -j4 modules
…the “-j4” is just for speeding compile up when you have 4 CPU cores.
Then you can copy the resulting module to where it is needed in a subdirectory of “/lib/modules/uname -r/”. You could then use “sudo depmod -A”.
Just as a general way of thinking, consider the integrated features of a kernel to be the “shape” of anything talking to it. If that “shape” has the right place for a module to talk to it (e.g., it wouldn’t be much use to build an ethernet driver for a USB ethernet device if USB does not exist), then the main kernel never needs to be touched to work with modules. If an integrated feature of the kernel changes, then the “shape” may change…even if required functionality for your module feature still exists, there is a possibility of depending on it being at some offset (which might change)…so you could test a module from one integrated feature set to a new/changed integrated feature set, and it might work, but you are advised that changing an integrated feature makes it likely you will benefit from replacing the whole kernel and module tree instead of just that module. This is when you’d change CONFIG_LOCALVERSION…when the base kernel changes integrated feature set.