I find a strange phenomenon about kernel version between "cross-compiling kernel sources of TX1" and "native-compiling kernel sources on my TX1"

I find a strange phenomenon about kernel version between “cross-compiling kernel sources” and “native-compiling kernel sources”
for cross-compiling kernel sources in my PC ubuntu 14.04;
sync l4t-r24.2.1 , git kernel sources.
rebuild this kernel sources by file:///C:/Users/shangwang/Downloads/l4t-documentation-24-2-1/l4t-documentation-24-2-1/nvl4t_docs/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide/l4t_getting_started.html#wwpID0E0OE0HA
flash my new kernel Image ang zImage and so on !
on my TX1 ,
“uname -r” is always “3.10.96-tegra+”

but for netive-compiling kernel source in my TX1 ubuntu16.04 and kernel version “3.10.96-tegra”
rebuild this kernel sources on my TX1 by http://www.jetsonhacks.com/2016/09/28/build-tx1-kernel-and-modules-nvidia-jetson-tx1/
on my TX1,
“uname -r” is always “3.10.96-tegra”

why do the difference between the two approuches occure ?

when I make use of cross-compiling kernel sources, how can i get rid of “+” ?

because on my TX1 “uname -r” is only “3.10.96-tegra” without “+”, i can make my drive and its library of "riffa2.2.2"http://riffa.ucsd.edu/download without any error. it should be noted that I make “riffa” natively on my TX1! and I need to rebuild kernel for other things!

Hi ???,

I am looking into this. Thanks.

Hi ???,

From my side, after build the Image, I don’t see any “+”. Do you follow the document?

Also, there is one line that point out the steps for external kernel modules are for BSP from jetpack.

Building External Kernel Modules
The procedures in this section describe how to build an out-of-tree kernel module against kernel headers included in the BSP.

Looks like the “source_sync” version adds the “+”, while the download page version of kernel source does not. It isn’t CONFIG_LOCALVERSION or EXTRAVERSION. The “make modules_install” step appends the “+” only in the source_sync version (I only use the download version since I can’t use JetPack, so I’ve not noticed this before). See this:

For me this “automatically append” option was not checked, and checking it adds a git tag, rather than a “+”. I’m sure it is related, but this won’t actually prevent the “+”. I tested using the same .config file under bout source_sync and download page kernel versions (it’s guaranteed an exact match), so it isn’t anything in the .config file controlling this. The issue also does not look like a top level Makefile difference, diff says they are exact matches. Seems one of the files which become part of the environment probably controls this.


Does it really cause error when build external kernel modules? Have you tried 4.4.38?

thankyou linuxdev and WayneWWW!
YES ! you are right!
when I download L4T sources from https://developer.nvidia.com/embedded/downloads , not form “sync l4t-r24.2.1 , git kernel sources.”

rebuild the kernel from cross-compiling in my PC , reflash TX1 , “uname -r” show “3.10.96-tegra”.

when “uname -r” is “3.10.96-tegra”, I make “riffa” successfully.

Hi ???,

Could you share step by step how you build a image with “-tegra” suffix?

I can confirm that starting with make mrproper, then using the exactly matching “.config” (from “/proc/config.gz”) in both soure_sync and doc page download kernel source, and exactly matching top level Makefile for both source_sync version and doc page downloaded version, with empty EXTRAVERSION and CONFIG_LOCALVERSION as “-tegra”, that only the source_sync version appends the “+”. I never did figure out where the “+” is added. I normally only use the doc page download for kernel source, so I’ve not noticed this before (I don’t know which version of source_sync introduced the “+”).

On my device, if I use “make menuconfig” and add “-tegra” suffix myself, the compilation always fails and need to make mrproper again, so I would like to ask @??? how it works.

From my point of view, I would like to ask if the “-tegra” and “+” issue affects the module build, or just affect when using “uname -r”. I don’t see any error on my side when make modules_prepare without “-tegra” .

on my PC, starting with make mrproper, “make menuconfig” and add “-tegra” suffix myself, it isn’t problem!
“-tegra” and “+” don’t affects the module build, yes! just affect when using “uname -r”.
meanwhile, when I make external modules “RIFFA” natively on my TX1, if “uname -r” show “+”, it show error!

when make modules_prepare without “-tegra” , it don’t have any error.

putting it another way, only when “uname -r” show “…-tegra” without “+” , I can make externel module “RIFFA” natively on my TX1 successfully!

as linuxdev said, “-tegra” and “+” suffix is connected with kernel sources from “where”!
source_sync version or doc page downloaded version,
when I modify the baud rate both /kernel_sources/drivers/tty/tty_ioctl.c and /kernel_sources/include/uapi/asm-generic/termbits.h.

“uname -r” show “…-tegra+” with “+” , this modification success!

but “uname -r” show “…-tegra” without “+”, this modification fail!

so I guess that “+” is connection with “driver”! but I don’t kown why?

I have not tested external module builds with this. However, if “uname -r” changes (and is presumably bound to the Image file), then the location of where modules are searched for would in theory also change. If the Image file is installed and “uname -r” changes, then I would expect the module search location to also change. Whether module versioning breaks when a “+” uname module is added to a “-tegra” uname module I don’t know…since I don’t know the source of the “+” in the source_sync version I can’t answer (this may also depend on options for module version enforcing…some options may be more forgiving than others).

I found the source of the extra + appended to the local version