This patch series adds support for the Raspberry Pi. It allows to use ‘sudo -E guix system init … /mnt’ with the root partition mounted at /mnt and the boot partition mounted at /mnt/boot/efi, as you would expect it for a PC with UEFI. Installing for netboot is possible as well.
It is currently not possible to build an image with this patch series, because of the intercepting handling for efi system image creation.
Some of these patches are generic and not related to the Raspberry Pi. I hope they will be a useful contribution for everyone.
Here is a quick overview of the single patches:
01: Disable the tests on aarch64 for qemu-minimal, because it is non-deterministic but needed to build grub.
02: Rework the grub-efi-netboot-bootloader and add a grub-efi-netboot-removable-bootloader which then are pre-installed. This allows a simplification of the efi-bootloader-chain, as these pre-installed bootloaders just need to be copied and can therefore easily be collected in a bootloader-profile.
03: A new build-side module to modify a defconfig. It is used to customize U-Boot and Linux packages.
04: Customized and pre-installed U-Boot packages for the Raspberry Pi.
05: Fixed the EXTRAVERSION variable used to build Linux, so that the extra-version argument will be visible with uname.
06: New function to modify a Linux package by using another defconfig and/or adding or removing configurations.
07: Raspberry Pi specific defconfig objects.
08: Some helpers to construct config.txt files for the Raspberry Pi firmware.
09: A function to create a package with device-tree files from a Linux package for the Raspberry Pi.
10: A bootloader for the Raspberry Pi. Additionally two examples of operating-system definitions to boot from local storage or over network, the latter is making necessary configuration changes to Linux.
The firmware topic is excluded. In the same way that guix assumes that some UEFI firmware is already present on a PC, this patch series assumes that a firmware to start U-Boot is already present.
The grub bootloaders are usable on PCs as well. In contrast to the normal grub-efi, all grub files are copied to the EFI system partition, instead of the root partition. This is a side effect of the netboot capability. Maybe this is helpful for some spacial cases. I realized for example that the normal grub-efi locates the partition containing the grub.cfg by a device name like (hd0,gpt1), this may be problematic when adding disks to a system. The new grub bootloaders determine the partition by UUID.
The new possibility to customize Linux with (modify-linux) will be useful for anyone in need to do small configuration changes. There is also the possibility to pass an own defconfig file to this function. It can either be the name of a defconfig file from the Linux sources, or it can be a file-like object, like produced by (local-file) or possibly downloaded with the new (make-defconfig) function.
> Since bug 43534 is closed, does that mean I can drop patch 01-gnu-qemu-disable-tests-on.patch ?
On the other side I have a bad experience with qemu substitutes for aarch64 and building qemu on a Raspberry takes a night and then still fails during the test. I hope the substitute situation improves, otherwise this patch should still be considered.
> @Stefan: On the other hand, I'm not sure of the general utility of make-defconfig.
There is currently no simple way change the Linux configuration. Also by modifying the final .config as of today (which kind of contains all CONFIG_…-variables), as far as I know dependencies will not be resolved and conflicting configurations can easily happen.
A defconfig however gets striped down to a minimum of required CONFIG_…-variables and all “missing” ones get either default values or get determined through dependecies. So adding /removing/changing some few configurations to a defconfig is less error-prone. Further defconfig files are easier to maintain in git. There is a reason that only defconfig files are maintained in the Linux sources.
Please note that the patch allows to select a defconfig file from the Linux sources (if the parameter is a string), and also to provide an own defconfig file (if it is a file-like object).
Toggle quote (2 lines)
> Sounds like a too weird special case to have general utility.
Well, there is the need already in Guix to have e.g. the predefined linux-libre-arm64-generic kernel, wich just uses a certain defconfig file from the Linux sources. But this possibility is not exported.
There are many defconfig files for all sorts of boards, especially for arm32. Why shouldn’t we allow to use any of these? Why should users be restrict to “selected” configurations? Why should Guix’ kernel configuration be preferred over the plain x86_64_defconfig?
And take a look at the last patch: In order to make that kernel boot on a Raspberry from an NFS root, some few configurations are missing, which can easily be added with the “modify-linux” function. By the way, maybe “customize-linux” would be a better name.
And there is another patch from me to make the NFS root test pass. As the Linux kernel build by Guix is not able to boot over NFS root in qemu, I used the same function there to add the missing configurations.
Oh, and finally, I need the same underlying kconfig.scm and a similar defconfig modification for U-Boot as well, which allowed me to simplify the existing U-Boot packages.