Jetson K1 Kernel Compile: Changed EXTRAVERSION Anyone?

I have kernel 3.10.24-g6a2d13a on my jetson, unchanged since the unit arrived. I checked to see if I could build modules (and only modules) to add required functionality…no go on that, I must actually flash a new kernel. Some module additions trigger non-module dependencies from other parts of the kernel source.

So on kernel compiles, everyone would start with the same kernel source, and the config from the current running kernel (e.g., via /proc/config.gz. The thing to be careful about though is that the running kernel will use the “uname -r” version to determine the module directory. Unless EXTRAVERSION is set to “-g6a2d13a” (such as in kernel top level Makefile), then the kernel would be looking at a different module directory. See /lib/modules/uname -r, where “uname -r” will change if EXTRAVERSION changes.

The catch is that within the original /lib/modules/3.10.24-g6a2d13a there is a subdirectory “extra”, and that subdirectory is populated by kernel modules provided indirectly by the script…this unpacks (in L4T see kernel/kernel_supplements.tbz2) kernel modules into the “extra” subdirectory. By recompiling the whole kernel and adding features which are non-module, I fear some of these “extra” kernel modules may reference a kernel address which is no longer valid. Kernel crash gourmet food.

Using an unchanged “EXTRAVERSION” and the original kernel source would use the same module directory…but is it valid to all modules after that? Using an updated EXTRAVERSION, the custom modules provided from kernel_supplements.tbz2 would have to be copied over…but is that an accident waiting to happen?

Can anyone who has flashed a new kernel comment on whether it was successful or not? Can you mention if your configuration during kernel compile added or changed the non-module options in any way?

Question for nVidia: Is the source code available for the kernel modules in the kernel_supplements.tbz2 file? Life would be drastically simpler for developing if I could simply rebuild these when I change non-module features on the kernel.

The ABI shouldn’t change at all, unless you remove some option in the kernel that they need. You should be able to just copy the “extra” folder over and run ‘depmod -a’ on your new kernel.

What I’m wondering about was triggered by questions involving the bridge.ko and ebtables modules (I need to run a network bridge modified for some simulation). There was a failure with this, but I do not have a JTAG debugger yet and am not certain of the reason. The Oops indicated a page fault in a non-NULL location. I posed this question elsewhere, and two possibilities (other than bad module code) were pointed out.

First, that it is possible that somewhere something is using a hard address to a static location which is not an exported symbol. Those addresses may change, and code compiled previously to use that old address will have no way to know of the change.

Second, that there are kernel structures which may change in size and/or layout, and that something may be expecting the same/older size and/or layout.

If I had a JTAG debugger I could directly find the answer…but since the page fault was to a non-NULL address, I won’t be able to determine whether it was a module failure or one of the above issues causing the problem.

I would have increased confidence that it wasn’t an ABI issue if I had a few people who added features to this kernel and reported success on kernel-only flash. Or if the u-boot boot loader could optionally boot to another kernel or memory card temporarily so I wouldn’t mind trying more experiments.

I’ve sent my reply to