Kernel Packages

[jetbalsa]

If this project wants to maintain them, I can do weekly packages for rpi2/3 kernels for people to update their Raspberries with

just need the scripts to build and package them

I suggest a flag to export the kernel packages out so I can sign then externally and put them in a custom repo.

[drtyhlpr]

Hi JRWR thanks for your support the offer sounds great! Are you talking about deb-pkg/.deb kernel package or are there any other possible ways to do that?

459below and me tried that and failed. maybe you have some ideas, maybe stuff has changed since that:
#98

ps. I would love to have rpi23 deb-pkg/.deb kernels!

[jetbalsa]

Hrm, I could compile the kernels on hardware, dedicate a scaleway instance to it, since they use the same arch

[drtyhlpr]

Hi my point was that we tried to use make-kpkg - that should exactly do the "need the script to build and package them". it was tried but (back then) not possible. no matter if a cross_compiler was used or if the package was build inside qemu/bootstrap environment. (#98).

I am not very used to create debian packages and I am not very used to make-kpkg. From my basic understanding it just creates a .deb file that includes kernel-source, kernel-image and kernel-headers.

I would not like to maintain, or better be responsible for maintaining binary images (of generated rpi23-$release.img and kernels). But I would love to just a link/ref to the generated kernel packages like the "Weekly image builds" at the end of the README page. I don't know if I find time to include a "EXPORT_KERNEL_PKG" parameter in the script that works like "make-kpkg".

[quozl]

Linux kernel source has within already scripts for building kernel as a binary package set;

make clean
cp foo.config .config
sed -i 's/CONFIG_DEBUG_INFO=y/CONFIG_DEBUG_INFO=n/g' .config
make bindeb-pkg LOCALVERSION=-q0

so there's no great need for make-kpkg in the Debian kernel-package if you have a reason to avoid it. Disabling CONFIG_DEBUG_INFO as above saves much time. Extending this to cross-compiling requires CROSS_COMPILE to be set to the appropriate prefix. Can be further sped up with ccache.

However, it may be more long-term helpful to work with Debian project to have kernels built; the Fedora project does so, after they overcame some licensing issues. If I recall correctly.

[drtyhlpr]

@quozl cool - never heard or this bindeb-pkg target, thanks for the infos. I ll give it a try as soon as i find time.

[jetbalsa]

Any news on this? I have started back up my builds for the images again, updated to buster this time for my weekly builds

[459below]

So I just skimmed the whole topic here but I want to point out that I've been building kernel deb-packages for a system setup by rpi23-gen-image this whole time without any problems. The script I used for that is here
Please note that the cd linux refers to the folder in which the raspberry linux sources are extracted.
I think something like this would be appropriate to copy the kernel over to the boot partition every time dpkg -i is invoked on the new kernel package:

[459below@manus kernel]$ cat /etc/initramfs/post-update.d/zz-update-rpi-kernel 
#!/bin/sh
cp /vmlinuz /initrd.img /boot/firmware/

and obviously config.txt would need kernel=vmlinuz and maybe the respective initramfs line if one needs ramfs for encryption or so. Though leaving the old kernel and _sed_ing the config.txt would be more appropriate, obviously. I think the rpi3-firmware package in the Debian repo has something like this.

The other thing is the official Debian support is in the making https://salsa.debian.org/raspi-team/image-specs though my rpi3 runs rpi23-gen with a kernel made by the gist mentioned earlier my rpi2 runs this official debian preview with the official 5.2.0-2-armmp kernel from the official Debian repo. A lot of official. However, when I tried to get a proper shutdown/power-on GPIO button through the gpio-shutdown.dtbo I noticed that the Debian kernel doesn't seem to have the expected GPIO support. I just learned about this Debian GPIO project, which seems to make "basic" GPIO on the rpi possible, though I suspect it won't be like just setting dtoverlay=awesome-overlay in the config.txt, though.

So I like the idea of having a proper officially supported Debian on the pi with kernel updates and all, but at least GPU and GPIO don't seem to be working as well yet.

/edit
Oh yeah. tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin is from here
/edit2
on the Debian kernel cat /sys/kernel/debug/gpio neatly lists all the GPIOs and can be exported like expected. So maybe just the DT stuff is a little different at the moment.

[459below]

OK, so on the image by gwolf I'm still able to swap the kernel with the one I'm running on the rpi23 image, as expected. The thing is that the rpi is so very picky about the DT and fixup stuff. So the Debian kernel is version 5, to which I've not yet upgraded to. Like always: the wifi doesn't want to just work OOTB after the upgrade.

Since I now need a kernel module, hence I'm going to setup a docker build image to produce crosscompiled .deb.

[459below]

https://hub.docker.com/r/459below/rpi

So I've already build .deb packages with this.

[drtyhlpr]

sounds good!