armbian-kernel: enable BTF (and CO-RE) for all kernels

[rpardini]

armbian-kernel: enable BTF (and CO-RE) for all kernels

• armbian-kernel: disable module signatures, harder
• armbian-kernel: enable BTF (and CO-RE) for all kernels
• armbian-kernel: enforce arm64 kernels use 48-bit PA/VA

[amazingfate]

cafdca0 is causing bcmdhd dkms module load panic on opi5max.
Reported by #7555 (comment)

[rpardini]

cafdca0 is causing bcmdhd dkms module load panic on opi5max.
Reported by #7555 (comment)

I missed the link there, how is BTF to blame? I'm not saying it ain't, just asking to understand.

[amazingfate]

cafdca0 is causing bcmdhd dkms module load panic on opi5max.
Reported by #7555 (comment)

I missed the link there, how is BTF to blame? I'm not saying it ain't, just asking to understand.

Here is the log when modprobe bcmdhd_sdio on rk vendor 6.1 kernel: http://paste.armbian.com/dewecaqowa.yaml
After loading the module, command lsmod will hang forever, and the system can't do normal boot/reboot.
I also tried 6.13 mainline kernel, which doesn't have this issue

[Tonymac32]

RK vendor kernel 🤣🤣🤣. Of course it's the one, somewhere in the 3M line diff from a real 6.1 it still thinks it's kernel 2.6 or whatever concerning BTF. 🥲😭

[rpardini]

What is funny is that rk vendor kernel works with the BTF stuff (say Cilium, Tetragon, bpftrace, etc, all work when BTF is enabled). Probably there's a 1-line change somewhere that affects the loading of modules -- we'll find it eventually.

I wonder if the Amlogic 5.15 kernel (used in meson s4t7 family, VIM4 etc) is also affected.

[amazingfate]

I also tried v4l2loopback-dkms with BTF enabled rk vendor kernel, and it can't get loaded.

[amazingfate]

After backporting this commit torvalds/linux@d4e48e3 to 6.1 vendor kernel, dkms module can get loaded with DEBUG_INFO_BTF enabled.
I guess all kernel before v6.11 have this issue.

[amazingfate]

The dkms issue is also confirmed existing with phytium-embedded current 6.6.

[amazingfate]

kernel family	kernel version	v4l2loopback dkms test result
bcm2711-current	6.6.71	load fine
phytium-embedded-current	6.6.12	kernel panic
rk35xx-vendor	6.1.84	kernel panic

I find that after adding this commit: torvalds/linux@f34d086 to rk35xx-vendor, the dkms module loads fine. This commit is introduced to mainline since v6.12, and backported to linux-stable since v6.1.113/v6.6.54.

We introduced BTF to get rid of the make clean issue since v6.12, what about enabling it only for kernels after v6.12? We have many vendor kernels which are not up-to-date with linux-stable and tt's hard to tell if one kenel has the fix.

[amazingfate]

Another choice is to add the fix to the outdated vendor kernels. After a quick look to images from https://github.com/armbian/os/releases and https://github.com/armbian/community/releases, there are four 6.1/6.6 kernels are outdated:

kernel family	kernel version	afftected boards	mainline or vendor kernel
rk35xx-vendor	6.1.84	all rk3528, rk356x, rk3588 boards	vendor
phytium-embedded-current	6.6.12	phytium pi	vendor
sun8i-legacy	6.1.104	all sun8i family boards	mainline
meson-current	6.6.43	onecloud, odroidc1	mainline

The two mainline kernel sunxi-legacy and meson-current can get kernel version easily bumpped by changing KERNELBRANCH from tag to branch of linux-stable. And fixing the other two vendor kernel is not that hard.
The downside is that if we introduce a new vendor kernel, we may forget this fix. While as time goes by, kernel from vendor should have less possibility to be outdated.