Building kernel - correct naming?

Hi,

when I build the kernel according to the hints given in this forum, I am successful. This was necessary to add SCTP, what is left out from the originally supplied kernel.

However the newly built kernel identifies itself with “uname -a” as

Linux Nano 4.9.140 #1 SMP PREEMPT Sun May 12 18:18:35 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux

Officially it should read “4.9.140-tegra”.

What steps are necessary to give the whole thing the right name?

With best regards

Ralph.

In the “.config” file of the kernel source look for “CONFIG_LOCALVERSION”. It should be:

CONFIG_LOCALVERSION="-tegra"

Thanks! I hoped for something easy like this - I will give it a try :)

Ralph.

Hi Ralph,

Were you able to get SCTP sockets to work with the TX2? I’m also trying to use the TX2 with srsLTE. I saw your post from March about the build issues (editing the CMakelists, etc) and that worked, but I still saw the SCTP warnings during cmake:

– Checking for module ‘sctp’
– No package ‘sctp’ found
– SCTP LIBRARIES: /usr/lib/aarch64-linux-gnu/libsctp.so
– SCTP INCLUDE DIRS: /usr/include
– No post-build-ENB command defined
– Building with srsEPC
– Found LibConfig++: /usr/lib/aarch64-linux-gnu/libconfig++.so
– static LibConfig++ path: /usr/lib/aarch64-linux-gnu/libconfig++.a
– Found LibConfig: /usr/lib/aarch64-linux-gnu/libconfig.so
– static LibConfig path: /usr/lib/aarch64-linux-gnu/libconfig.a
– Checking for module ‘sctp’
– No package ‘sctp’ found
– SCTP LIBRARIES: /usr/lib/aarch64-linux-gnu/libsctp.so
– SCTP INCLUDE DIRS: /usr/include

Now that everything built with the other fft library workarounds, I see that srsepc cannot create an SCTP socket (kinda important for the MME!).

What kernel mods did you end up making?

Thanks.

I do have -tegra. But i still have “No package ‘sctp’ found”.
When i run srsepc. It crashed. Can anybody help with this? thank you so much!

my processor info:
nvidia@nvidia-desktop:/sys/devices/system/cpu$ grep -E ‘^model name|^cpu.MHz’ /proc/cpuinfo
model name : ARMv8 Processor rev 3 (v8l)
model name : ARMv8 Processor rev 3 (v8l)
model name : ARMv8 Processor rev 3 (v8l)
model name : ARMv8 Processor rev 3 (v8l)

nvidia@nvidia-desktop:/sys/devices/system/cpu$ cat ./cpu*/cpufreq/scaling_governor
schedutil
schedutil
schedutil
schedutil
schedutil
schedutil

When i run srsepc. It crashed. i have such output.
nvidia@nvidia-desktop:~/srsLTE-release_19_12/srsepc$ sudo srsepc epc.conf

Built in Release mode using 19.12.0.

— Software Radio Systems EPC —

Reading configuration file epc.conf…
HSS Initialized.
Could not create SCTP socket
MME S11 Initialized
MME GTP-C Initialized
MME Initialized. MCC: 0xf001, MNC: 0xff01
SPGW GTP-U Initialized.
SPGW S11 Initialized.
SP-GW Initialized.
*** buffer overflow detected ***: srsepc terminated
srsLTE crashed… backtrace saved in ‘./srsLTE.backtrace.crash’…
— exiting —

Hi jane,

Please open a new topic for your issue. Thanks

hi @pp2019 I have the same problems. No package ‘sctp’ found. when I run srsepc, it says could not create sctp. Did you solve this problem?

@linuxdev @dk5ras
My understanding is that only the Nvidia kernel with it’s default configuration (and it’s modules) should have that localversion. If you’re building your own kernel and modules with a custom config it should be something unique of your choice. Otherwise I would think there are some situations where conflicts can happen. (eg. a kernel with one config and a some modules with another, or perhaps the package manager (search for localvesrion) deciding your kernel/modules are Nvidia’s and need replacing). I do not know how Nvidia’s kernel packages handle this, but it’s probably safer to just use a custom string.

If you change the configuration from the default, it is advisable to append your own version information, which you can configure by setting CONFIG_LOCALVERSION

Technically you are correct. However, if you are only adding features, and not removing features, then you’d end up building all of the same modules you already have. If something changes in the chain of dependencies, then the config name should change, but I cheat a bit when only a module is being added since it results in the other modules being the same thing anyway. I treat it something like an old fashioned Makefile…if a module is already built, and the source code is the same, and everything produced by or consumed by the change leaves the original working with no change, then there is no need to build it again. Instructions are simplified by simply adding a kernel module instead of all modules.