Hi! 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.
Hi! There were errors in the patches 05 and 06 in the EXTRAVERSION handling and in the modify-linux function. Here an updated patch series. They apply to commit f661e6883ec345258634940ce5d52957e1bb90c3.
Hi Stefan, Thanks! Pushed 05-gnu-linux-correct-name-of.patch to guix master as commit b04cba9ee533945f90ffd72637f064c60188f945. (I've also started testing the other patches of this patchset, but it will take a while)
Toggle diff (36 lines)diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scmindex 84ea849108..51e692a8c3 100644--- a/gnu/packages/linux.scm+++ b/gnu/packages/linux.scm@@ -749,9 +749,9 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration." (define* (make-linux-libre version hash-string supported-systems #:key+ (extra-version #f) ;; A function that takes an arch and a variant. ;; See kernel-config for an example.- (extra-version #f) (configuration-file #f) (defconfig "defconfig") (extra-options %default-extra-linux-options)@@ -770,9 +770,9 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration." (define* (make-linux-libre* version source supported-systems #:key+ (extra-version #f) ;; A function that takes an arch and a variant. ;; See kernel-config for an example.- (extra-version #f) (configuration-file #f) (defconfig "defconfig") (extra-options %default-extra-linux-options))@@ -838,7 +838,8 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration." (format #t "`CROSS_COMPILE' set to `~a'~%" (getenv "CROSS_COMPILE"))))- (setenv "EXTRA_VERSION" ,extra-version)+ (setenv "EXTRAVERSION" ,(and extra-version+ (string-append "-" extra-version))) (let ((build (assoc-ref %standard-phases 'build)) (config (assoc-ref (or native-inputs inputs) "kconfig")))
Hi Stefan, In 04-gnu-bootloader-add-u-boot.patch, I think that having #:name is too magical(it still only replaces part of the package name, and then still only aftersubstitution). But if made non-magical, then it has too little benefit. Likewise for #:description. If it's alright with you, can we just drop #:name xxx and #:description xxxaltogether and instead do: (define-public u-boot-rpi-3-efi (package (inherit (make-preinstalled-u-boot-package "rpi_3_32b" "arm-linux-gnueabihf" #:name "rpi-3-efi" #:configs %u-boot-rpi-efi-configs #:description %u-boot-rpi-efi-description-32-bit)) (name "u-boot-rpi-3-efi") (description %u-boot-rpi-efi-description-32-bit))) And similar for all the other u-boot definitions, and forthe usage of make-u-boot-package inside make-preinstalled-u-boot-package ? Or are there upsides to doing it like you did it? I'm aware that the same can be said for "board" ... which is used already.However, that parameter is also used for something else, so it needs to be there. NAME isn't used for anything else but for doing what a regular package inheritcould do anyway. Is there a downside when using package inherit?
Hi Mark,Hi Leo, could you look at 06-gnu-linux-new-function-to.patch of this patchset? It provides the user a means of (slightly) editing kernel configs using ahigh-level interface, called "modify-linux". What do you think? @Stefan: On the other hand, I'm not sure of the general utility of make-defconfig.I've never needed something like it in decades. Is it worth exporting as publicfrom (gnu packages linux) ? Sounds like a too weird special case to have generalutility.
Toggle quote (2 lines)> Since bug 43534 is closed, does that mean I can drop patch 01-gnu-qemu-disable-tests-on.patch ?
Yes. 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.
Toggle quote (2 lines)> @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.