Advanced users • Re: Moving Linux Kernel to 6.6

So yeah, the intermediate conclusion is that the GH kernel is a completely different kernel, that we just publicly don't know how it relates to he officially built one.

I've already said the repo is the same kernel but the development tree. It will have numerous changes that haven't made it into the stable repo kernel. Unsurprisingly, a month worth of changes is a large number of lines.

I know that the repo is the development tree, and that the tip of the branch will be far ahead of the official kernel build. This is all fine and expected (and was seemingly[1] accounted for in the diffs I mentioned above)
What is not expected is following official kernel building docs, checking out specific commits that are said to be corresponding to the released official kernel builds, and then getting incompatible binaries.
It was absolutely not obvious that there are extra steps and extra patches applied to the kernel. And no matter how I asked about the exact steps needed to reproduce the official stable release builds, I couldn't get an answer.

Anyway, ultimately, I figured it out.

The official kernel contains at least two sets of patches: one from debian, and one baked from a release-specific commit from the raspberrypi/linux repo. The RPi repo itself does not contain debian patches. They are applied separately. This debian set of patches is not that big, but also not trivial.

A simple way to get the debian patches is to use the `apt source <kernel-image-pkg>` command to download and prepare the sources. This command will leave its artifacts in the current directory. It will:

1. Download `linux_6.6.20.orig.tar.xz` which is exactly the vanilla 6.6.20 kernel from kernel.org, no changes.
2. Download `linux_6.6.20-1+rpt1.debian.tar.xz` which contains both sets of patches: debian and raspberry-pi specific, (and also scripts, and other misc stuff).
3. Extract the vanilla kernel into `linux-6.6.20` dir, and apply [1]debian patches only. It will not apply raspberry pi-specific patches.

To make a release-compatible kernel sources, RPi-specific patches need to be applied:The resulting kernel sources do seem to exactly correspond to commit 6f16847710cc0502450788b9f12f0a14d3429668 in the repo plus the debian patches.
This is the same commit hash that can be found in:

• raspberrypi/firmware repo extra/git_hash file
• `debian/changelog` file: `* Linux commit: 6f16847710cc0502450788b9f12f0a14d3429668`

From here it wasn't too hard to figure out what's the offending debian patch is, the one that makes modules incompatible.
It's this one, which enables per-module BTF info unconditionally:Applying just this patch to the raspberrpypi/linux repo makes `module_layout` symbol CRC congruent. I guess enabling CONFIG_DEBUG_INFO_BTF_MODULES in .config would work too.

I haven't looked at other symbols CRCs, at this point I just hope that there are no more layers to this whole situation.

Statistics: Posted by provod — Mon Apr 08, 2024 10:55 pm

---