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?
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!).
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)
@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.