[Bookworm] Add linux-image-rpi-v8 to armhf repo

[MichaIng]

Currently, the 32-bit/armhf package list of archive.raspberrypi.org lacks the linux-image-rpi-v8 and hence the 6-bit kernel packages. This can be an issue for 32-bit userland/OS RPi 4 systems which have the 64-bit kernel enabled by default since a while, and for any other systems which manually switched to the 64-bit kernel.

The official RPi OS Bookworm 32-bit image ships with arm64 as foreign architecture, which of course works, but produces an unnecessary overhead, especially when using Debian instead of Raspbian, with all package lists for arm64 downloaded, cached etc, while most of the packages cannot be installed and might even cause conflicts.

For flexibility and since it just does not hurt, it would be great if the 64-bit kernel (and headers) packages could be added to the 32-bit/armhf repository as well.

[MichaIng]

Ah, and the same generally applies for linux-image-rpi-2712 as well. What I am wondering is that this package is not installed on the official 32-bit RPi OS, while it states to support all RPi models. Is this kernel not required for the Raspberry Pi 5?

[XECDesign]

I don't know whether Debian's kernel packaging supports that and it's not something I can investigate any time soon, so this is likely a wontfix. Unless, you know where to look and can point me to it.

Ah, and the same generally applies for linux-image-rpi-2712 as well. What I am wondering is that this package is not installed on the official 32-bit RPi OS, while it states to support all RPi models. Is this kernel not required for the Raspberry Pi 5?

That kernel has 16k pages, so it's not able to run 32-bit applications at all. It's not required for the pi5, since the v8 kernel works.

[MichaIng]

Ah I see, so compared to the classic raspberrypi-kernel/raspberrypi-bootloader you switched the packaging tools? Hmm, so the package architecture is then defined automatically by the standard Debian Linux build scripts, I guess, based on the actual kernel architecture. I will have a look into this when I find time.

That kernel has 16k pages, so it's not able to run 32-bit applications at all. It's not required for the pi5, since the v8 kernel works.

So v8 can run 32-bit and 64-bit applications and supports all 64-bit capable RPi models (including RPi 5), while 2712 supports RPi 5 and 64-bit userland only? Is the letter expected to perform better on RPi 5?

[popcornmix]

So v8 can run 32-bit and 64-bit applications and supports all 64-bit capable RPi models (including RPi 5), while 2712 supports RPi 5 and 64-bit userland only? Is the letter expected to perform better on RPi 5?

Correct. The 16K pagesize has some performance benefits (e.g. 7% improvement with jetstream benchmark). But 16K pagesize is only supported by the newer arm core on Pi5.

[MichaIng]

Thanks for clarification!

I found a way to create an armhf version of the linux-image-rpi-v8 package, in case the standard embedded Debian build scripts are used: https://github.com/raspberrypi/linux/blob/rpi-6.1.y/Documentation/kbuild/kbuild.rst#kbuild_debarch

KBUILD_DEBARCH

For the deb-pkg target, allows overriding the normal heuristics deployed by deb-pkg. Normally deb-pkg attempts to guess the right architecture based on the UTS_MACHINE variable, and on some architectures also the kernel config. The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian architecture.

So doing one additional build with this environment variable set to armhf should create a package with Architecture: armhf control, and every APT repo tool should add it to the binary-armhf/Packages list.

[MichaIng]

Another related issue: On 32-bit RPi OS (Raspbian), headers for the 64-bit kernel cannot be installed, because they depend on gcc:arm64, while Raspbian has no arm64 components, of course.

I am actually wondering how this every worked before. Is cross-compiling of 64-bit kernel modules possible with a 32-bit compiler?

EDIT: I just got pointed to: https://github.com/raspberrypi/linux/issues/5408#issuecomment-1589045018 So indeed it is not possible to compile 64-bit kernel modules with 32-bit compiler and it is not possible to install both native toolchains neither, at least not both compilers. The only way to solve this nicely IMO is to generate a separate armhf variant of the 64-bit headers as well, which depend on the cross-compiler toolchain instead of the native one. But how to adjust the dependencies debhelper adds via ${Depends:misc} is the same question as here: #358 And not sure whether its worth the hassle. This 64-bit kernel on 32-bit userland has a lot of similar issues when trying to compile software, so I guess it is fine to have arm_64bit=0 as solution in any such case, knowing that this has some other negative implications regarding CMA size or what the reason for the switched default on RPi 4 was.

[XECDesign]

Debian's kernel packaging doesn't allow you to cross-compile modules like that. It works going from amd64 to i386 architectures, but if you run stock Debian armhf with an arm64 kernel, you run into all the same problems.

[MichaIng]

And hacking this inside is probably too much hassle/not worth it. And at least, since the same was already a problem with the old packaging, it is not a regression. There is anyway not much point to run the 32-bit OS with a 64-bit capable RPi, now that software support is mostly there (and even much better for 3rd party software).

I wonder why the 64-bit RPi OS is still listed as second choice on the website. To me it would make sense to promote it as first/recommended RPi OS version for all RPi models which support it, and the 32-bit variant as inferior fallback, for BCM2708/BCM2709 models only. But this is a different topic.

However, doing a KBUILD_DEBARCH=armhf build of the 64-bit kernel as separate package for the armhf repo would still be great 🙂. So arm64 does not need to be added as foreign arch, with the possible problems/conflicts and overhead implied.

[XECDesign]

Closing because as you say, it's not worth the hassle. Maybe one day if I run out of other things to do, I can revisit it.

[MichaIng]

"Not worth the hassle" for me was the attempt to get 64-bit headers into the 32-bit repo. Generating however a 64-bit kernel package with armhf package arch seems to be, as stated, extremely simple, just passing KBUILD_DEBARCH=armhf env var. Basically my very last sentence above 😉.

[XECDesign]

I think I've mentioned somewhere already that the .deb build scripts that come from the upstream kernel source tree are not a part of Debian's packaging. KBUILD_DEBARCH won't have any impact.