Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Sat Jun 03, 2017 2:17 pm Post subject: Weekly autobuild of the RPi3 64-bit bcmrpi3_defconfig kernel |
|
|
Hello,
I have set up a weekly autobuild of the default branch of the official Raspberry Pi Linux source tree, for the 64-bit Raspberry Pi 3 Model B, available on GitHub here.
Builds are performed with the standard bcmrpi3_defconfig, with the only change being that the first 12 hex digits of the tip commit SHA1 hash are appended to CONFIG_LOCALVERSION (with a separating hyphen) before building. A new binary kernel tarball is automatically created and uploaded as a release asset to the GitHub project each week (unless the tip of the default branch is unchanged from the prior week, or an error occurs during the build process).
For example, on 1 June 2017, the default branch was rpi-4.9.y and the latest commit was e5bd734340e6871e4e9ef5ff66e61197eb8ece30 (the short form of which is e5bd734340e6). The created release was 4.9.30.20170601, within which the kernel tarball was bcmrpi3-kernel-4.9.30.20170601.tar.xz, and the corresponding kernel release name was 4.9.30-v8-e5bd734340e6+.
Each kernel release tarball provides the following files:
- /boot/kernel8.img (this is the bootable 64-bit kernel);
- /boot/bcm-2710-rpi-3-b.dtb and /boot/bcm-2837-rpi-3-b.dtb (the device tree blobs);
- /lib/modules/<kernel release name>/... (the module set for the kernel);
- /lib/firmware/... (the kernel-built firmware).
A list of all release tarballs may be viewed here (there are currently only two, but new releases should appear automatically each Monday morning from now on).
Installation
To deploy (assuming that your RPi3's micro SD-card's first partition is mounted as /boot, and you are already running a 64-bit RPi3 image, such as my gentoo-on-rpi3-64bit) simply download the desired version tarball, untar into the root directory, and reboot. For example:
Code: | pi64 ~ # cp /boot/kernel8.img{,.old}
pi64 ~ # wget -c https://github.com/sakaki-/bcmrpi3-kernel/releases/download/4.9.30.20170601/bcmrpi3-kernel-4.9.30.20170601.tar.xz
pi64 ~ # tar -xJf bcmrpi3-kernel-4.9.30.20170601.tar.xz -C /
pi64 ~ # sync && reboot |
Alternatively, if you have my rpi3 overlay installed (it is pre-installed on the gentoo-on-rpi3-64bit image), you can simply emerge the sys-kernel/bcmrpi3-kernel-bin package (a new ebuild is automatically created to mirror each release here). For example, to install the latest available version (and start using it):
Code: | pi64 ~ # emaint sync --repo rpi3
pi64 ~ # emerge -av bcmrpi3-kernel-bin
pi64 ~ # reboot |
Or, to install a particular version (e.g.):
Code: | pi64 ~ # emaint sync --repo rpi3
pi64 ~ # emerge -av =bcmrpi3-kernel-bin-4.9.30.20170601
pi64 ~ # reboot |
Disclaimer: These prebuilt kernels and ebuilds are provided as a convenience only. Use at your own risk! Given that the releases in this project are created automatically, there is no guarantee that any given kernel will boot correctly. A 64-bit kernel is necessary, but not sufficient, to boot the RPi3 in 64-bit mode; you also need the supporting firmware, configuration files, and userland software (see for example my gentoo-on-rpi3-64bit project, or Neddy's Seagoon's Raspberry Pi 3 64 bit Install page on the Gentoo wiki, for more information).
I can't promise to keep this autobuild running forever, but I'm using it as part of my next (currently WIP) gentoo-on-rpi3-64bit release (for which I want to have all installed packages backed by a weekly autobuild binhost, including the kernel), so it should be around for a while.
PS the default branch is used because (per Eric Anholt) that is first to receive attention for VC4 backports etc (some functionality is currently broken in rpi-4.11.y, for example).
PPS The bcmrpi3-kernel-bin packages currently leave behind the /lib/modules/<kernel release> directories and contents when uninstalled as part of an upgrade, probably because the module files are marked as being in-use until the system is rebooted into the new kernel, so that portage doesn't remove them. Not sure; I need to look into how Arch etc. do their /lib/modules cleanup after a binary kernel package (un-)install. If anyone has any experience with "-bin" kernel ebuilds, I'd be interested to hear how you handled this (my approach is pretty basic right now; here's an example ebuild). _________________ Regards,
sakaki |
|