| Message ID | 1JV7YdNsB7LB0ij9pMN5ktIsdpU8g98Lpu0yOrl_r6wFvRjqRJ5XqOktugKlia2rSeyNVEwY0b8VJrFJr1TsWgOIo-JW6EmTpj6Bz4dNzxQ=@protonmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#48314,v3] Install guix system on Raspberry Pi | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
The issue about guile-fibers has already been reported by Mathieu in https://issues.guix.gnu.org/54793.
phodina via Guix-patches via schreef op do 14-04-2022 om 07:38 [+0000]: > + `(modify-phases ,phases > + (replace 'configure To get rid of the #< error, replace this by #~(modify-phases #$phases [...]) (and replace the , by #$ etc). Greetings, Maxime.
phodina via Guix-patches via schreef op do 14-04-2022 om 07:38 [+0000]: > I've also attempted to cross-compile the system (from x86_64) but > there is at least one package that can't be build - guile-fibers- > 1.1.0. I've attached the build log as well. This one should now be fixed by 1f82602153 gnu: guile-fibers@1.1: Support cross-compilation. Greetings, Maxime.
On 2022-04-14, phodina@protonmail.com wrote: > (u-boot-rpi-0-w, u-boot-rpi, u-boot-rpi-2, u-boot-rpi-3, u-boot-rpi-4, > u-boot-rpi-64, u-boot-rpi-0-w-efi, u-boot-rpi-efi, u-boot-rpi-2-efi, > u-boot-rpi-3-efi, u-boot-rpi-4-efi, u-boot-rpi-efi-64): New packages. Comments from November are still relevent: https://issues.guix.gnu.org/48314#12 (e.g. drop drop u-boot-rpi-0-w*, u-boot-rpi, u-boot-rpi-efi, maybe consider droping u-boot-rpi-2* and the 32-bit variants for rpi3 and rpi4, as armhf is not well maintained at the moment). Basically, ARMv6 is not supportable by guix, ARMv7 is poorly supported in the armhf architecture, and ARMv8 is capable of running aarch64 (a.k.a. arm64): https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications Only proposing aarch64 variants would pretty much leave you with rpi-arm64. The EFI variants and 32-bit variants supported on armhf could be easily added later once the other patches land. > +(define-public %u-boot-rpi-efi-configs > + '("CONFIG_OF_EMBED=" > + "CONFIG_OF_BOARD=y" > + "CONFIG_BOOTDELAY=0")) See comment: https://issues.guix.gnu.org/48314#15 e.g. Please do not set BOOTDELAY=0. It makes it nearly impossible to debug. For people who want to live on the edge, they could build custom variants and set it to 0. > +(define-public u-boot-rpi-64 > + (make-preinstalled-u-boot-package > + "rpi_arm64" > + "aarch64-linux-gnu" > + #:name "rpi-64" > + #:description %u-boot-rpi-description-64-bit)) Please keep package names consistent with defconfig name. (e.g. u-boot-rpi-arm64). It's confusing enough without extra newly invented names! :) > +(define-public u-boot-rpi-3-efi > + (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)) Ditto, or drop this variant; same for the 32-bit rpi-4 variants. > Subject: [PATCH v3 2/8] build: kconfig: Add new module to modify a defconfig > file. ... > (define-public u-boot-pinebook > - (let ((base (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu"))) > - (package > - (inherit base) > - (arguments > - (substitute-keyword-arguments (package-arguments base) > - ((#:phases phases) > - `(modify-phases ,phases > - (add-after 'unpack 'patch-pinebook-config > - ;; Fix regression with LCD video output introduced in 2020.01 > - ;; https://patchwork.ozlabs.org/patch/1225130/ > - (lambda _ > - (substitute* "configs/pinebook_defconfig" > - (("CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y") "CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y\nCONFIG_VIDEO_BPP32=y")) > - #t))))))))) > + (make-u-boot-sunxi64-package "pinebook" "aarch64-linux-gnu" > + ;; Fix regression with LCD video output introduced in 2020.01 > + ;; https://patchwork.ozlabs.org/patch/1225130/ > + #:configs '("CONFIG_VIDEO_BPP32=y"))) I like how this simplifies the package definitions where you need to adjust the defconfig! This particular workaround for u-boot-pinebook may no longer be needed, thanks for the reminder to check. > (define-public u-boot-novena > - (let ((base (make-u-boot-package "novena" "arm-linux-gnueabihf"))) > + (let ((base (make-u-boot-package "novena" "arm-linux-gnueabihf" > + ;; Patch configuration to disable loading u-boot.img from FAT > + ;; partition, allowing it to be installed at a device offset. > + #:configs '("CONFIG_SPL_FS_FAT=")))) Maybe this is different in upstream u-boot, but in the past setting it to an empty value could result in the default value, which is why: > - (substitute* "configs/novena_defconfig" > - (("CONFIG_SPL_FS_FAT=y") "# CONFIG_SPL_FS_FAT is not set")) > - #t))))))))) ... was used previously. > Subject: [PATCH v3 5/8] gnu: raspberry-pi: Add defconfig objects to build > customized Linux kernels. > > gnu/packages/raspberry-pi.scm (make-raspi-defconig): New function to make > downloaded defconfig objects from the Linux repository of the Raspberry Pi > Foundation. > (%bcm2709-defconfig, %bcm2710-defconfig, %bcm2711-defconfig, > %bcm2835-defconfig, %bcmrpi-defconfig, %bcm2711-defconfig-64, > %bcmrpi3-defconfig): New variables containing defconfig objects to build > Linux kernels customized for Raspberry Pi single board computers. Similar to my comments on u-boot variants, some of these are for models that are not supportable on guix (rpi, rpi-0), so probably best to leave out entirely, and the 32-bit variants for armhf are debatable at this point. live well, vagrant
On 2022-04-14, Vagrant Cascadian wrote: > On 2022-04-14, phodina@protonmail.com wrote: > (e.g. drop drop u-boot-rpi-0-w*, u-boot-rpi, u-boot-rpi-efi, maybe > consider droping u-boot-rpi-2* and the 32-bit variants for rpi3 and > rpi4, as armhf is not well maintained at the moment). > > Basically, ARMv6 is not supportable by guix, ARMv7 is poorly supported > in the armhf architecture, and ARMv8 is capable of running aarch64 > (a.k.a. arm64): > > https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications > > > Only proposing aarch64 variants would pretty much leave you with > rpi-arm64. Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and 2021.04 rpi-arm64 fails to boot on rpi3b+ ... but does work with the rpi_3 and rpi_3_b_plus defconfigs... so I guess that makes a case for having multiple variants, even if rpi_arm64 theoretically supports all the arm64 boards... hrm. That said, now that I've been able to test it; I feel confident at least adding a simple u-boot-rpi-3 and/or u-boot-rpi-3-b-plus package (without most of the proposed changes). Even though I haven't been able to test u-boot-rpi-arm64, might be worth adding just to get it out of the way. I could also test booting the rpi2 variants, though as mentioned earlier, I'm skeptical about adding more support until things improve for armhf on guix. live well, vagrant
Hi Vagrant! > Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and > 2021.04 rpi-arm64 fails to boot on rpi3b+ ... IWithin my patch series there is one patch to modify a defconfig file. I enhanced that patch meanwhile to check, that lines in the modified defconfig show up in the final .config file. Last weekend I found out that several settings differ. I also updated the raspberry specific defconfigs, but the mismatches still remain. My guess is, that the kernel has problems booting. Did GRUB show up? > I feel confident at least > adding a simple u-boot-rpi-3 and/or u-boot-rpi-3-b-plus package (without > most of the proposed changes) Please wait a bit longer, I addressed all your comments to U-Boot already. Bye Stefan
On 2022-04-28, Stefan wrote: >> Just tested this on an rpi3b+ and sometime between u-boot 2021.01 and >> 2021.04 rpi-arm64 fails to boot on rpi3b+ ... > > IWithin my patch series there is one patch to modify a defconfig > file. I enhanced that patch meanwhile to check, that lines in the > modified defconfig show up in the final .config file. Last weekend I > found out that several settings differ. I also updated the raspberry > specific defconfigs, but the mismatches still remain. Look forward to seeing an updated patch series! > My guess is, that the kernel has problems booting. Did GRUB show up? I didn't test with grub, just the syslinux-style menus, but it didn't even get as far as u-boot on the serial console with rpi_arm64_defconfig. With either rpi_3_defconfig or rpi_3_b_plus_defconfig, it worked just fine. I had to set gpu_freq=250 in config.txt, which is a bit of a known issue: https://github.com/raspberrypi/firmware/issues/553 >> I feel confident at least >> adding a simple u-boot-rpi-3 and/or u-boot-rpi-3-b-plus package (without >> most of the proposed changes) > > Please wait a bit longer, I addressed all your comments to U-Boot already. I really don't see the harm in it, and actually see considerable benefit to making a smaller diff for review as it is a huge patch series, but I'm not planning on actually using guix on any rpi hardware anytime soon, so... ok. live well, vagrant
Hi Stefan, do you need help with the patches? Also should we provide some patches to the upstream kernel in Guix? [1] [1] https://github.com/lategoodbye/rpi-zero/issues/43 ---- Petr
Hi! Sorry for tho long period of silence. > do you need help with the patches? Actually not with the patches, but with building and testing. I was affected by the lack of substitutes for aarch64. Building with only 1 GB RAM and swap space is a pain. For building Guix I figured out that building only sub-targets like make-core-go, make-packages-go, etc. helps. But this way I missed to do a “make all” and was wondering a lot and for long time about errors because silently a wrong /gnu/stor/…-guix-module-union/ got used. I have a set of patches to fix or disable tests, just because of too less RAM, too less computing-power and an NFS root file-system. Currently one test of glib is failing. So I can’t proof that my patches lead to a working system on current Guix. > Also should we provide some patches to the upstream kernel in Guix? [1] > > [1] https://github.com/lategoodbye/rpi-zero/issues/43 I’m far from a point to care for patches to the kernel. I’d be glad, if the linux-libre kernel is able to run a minimal Guix System. :-) Bye Stefan
Hi! A new patch series based on 7558417360d2ae011ec23197c75ef8e411558810. I tried to apply all review comments. Bye Stefan
Thanks Stefan for the updated patches! I've applied them and build the system. However, I'm unable to test the system as there is an error when invoking `guix system init` command: $ sudo -E ./pre-inst-env guix system init --target=aarch64-linux-gnu gnu/system/examples/raspberry-pi-64.tmpl /mnt /gnu/store/hhb5l2f5287xmfzz4jgvi15kb9bcqi33-system /gnu/store/fiq006ykhc0dkninzz5gxl2nh3vzc37p-grub.cfg initializing operating system under '/mnt'... copying to '/mnt'... populating '/mnt'... guix system: error: symlink: Operation not permitted: "/boot/efi/gnu/store" $ sudo fdisk /dev/mmcblk0 Welcome to fdisk (util-linux 2.37.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, and swapoff all swap partitions on this disk. Command (m for help): p Disk /dev/mmcblk0: 29.12 GiB, 31267487744 bytes, 61069312 sectors Disk model: 1081CS0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sda1 2048 526335 524288 256M 83 Linux /dev/sda2 526336 61069311 60542976 28.9G 83 Linux $ mount /dev/mmcblk0p2 on /mnt type ext4 (rw,relatime) /dev/mmcblk0p1 on /mnt/boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) I have these 2 remarks: 1) Why does it point to "/boot/efi/gnu/store" and not "/mnt"/boot/efi/gnu/store"? 2) Symlink from ext4 "Guix" partition will not work on another vfat "EFI" partition. Do you know how to fix this issue? ---- Petr
Hi Petr! > Do you know how to fix this issue? Yes. Like on other EFI systems, you have to mount /dev/mmdblk0p1 on /mnt/boot/efi. There is the usual bootloader installation fallback, to use the bootloader-target argument for installation on /, if it is not existing below /mnt. And this is happening in your case. I don’t understand why this common fallback got invented. I think it’s actually dangerous. It could destroy your booted system, if you simply forgot to mount the EFI system partition. I would prefer a clear error message. But well, the code is following existing standards. > 1) Why does it point to "/boot/efi/gnu/store" and not "/mnt"/boot/efi/gnu/store"? Because /mnt/boot/efi was not existing in your case and because of that fallback to ignore /mnt and use / instead. > 2) Symlink from ext4 "Guix" partition will not work on another vfat "EFI" partition. That’s true. This symlink will not be created for your use case. The symlink will be created for booting over network, when the /mnt/boot/efi is an NFS share which allows symlinks. The use-case decision is based on symlink support at the bootloader-target. Actually the installation on a microSD card is just a by-product of installation for netboot. :-) Even on a normal x86_64 EFI system you could install the grub-efi-netboot-(removable-)bootloader instead of the grub-efi-(removable-)bootloader. The difference is, that all GRUB files will reside on the EFI system partition instead of the root partition. This could be helpful for encryption problems. Bye Stefan
Hi Stefan! > > > Do you know how to fix this issue? > > > Yes. Like on other EFI systems, you have to mount /dev/mmdblk0p1 on /mnt/boot/efi. > > There is the usual bootloader installation fallback, to use the bootloader-target argument for installation on /, if it is not existing below /mnt. And this is happening in your case. > > I don’t understand why this common fallback got invented. I think it’s actually dangerous. It could destroy your booted system, if you simply forgot to mount the EFI system partition. I would prefer a clear error message. Thanks. I've mounted the boot partition to /mnt/boot instead of /mnt/boot/efi. I tend to agree with you as the default behaviour can damage the host system without a warning which is dangerous. So now I get some weird guix error during copying files: sudo -E ./pre-inst-env guix system init --target=aarch64-linux-gnu gnu/system/examples/raspberry-pi-64.tmpl /mnt -v 3 gnu/system/examples/raspberry-pi-64.tmpl:32:24: warning: the 'target' field is deprecated, please use 'targets' instead gnu/system/examples/raspberry-pi-64.tmpl:27:2: warning: List elements of the field 'swap-devices' should now use the <swap-space> record, as the old method is deprecated. See "(guix) operating-system Reference" for more details. /gnu/store/hhb5l2f5287xmfzz4jgvi15kb9bcqi33-system /gnu/store/fiq006ykhc0dkninzz5gxl2nh3vzc37p-grub.cfg initializing operating system under '/mnt'... copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message copying to '/mnt'... I've added the verbosity level 3 to print everything but I didn't get more info about what fails :-( ---- Petr
Hi Petr! > So now I get some weird guix error during copying files: > initializing operating system under '/mnt'... > copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message > copying to '/mnt'... The function make-grub-efi-netboot-installer in gnu/bootloader/grub.scm first uses copy-recursively to copy the collection of bootloader files to /mnt/boot/efi and creates afterwards the symlinks to /gnu/store and /boot/grub/grub.cfg or – as in your case – creates a /mnt/boot/efi/efi/boot/grub.cfg to point GRUB to the root partition to access /boot/grub/grub.cfg and /gnu/store. Yesterday your guix system init struggled to create these symlinks. That means it was already done with the copy-recursively call. I’m pretty sure that this copy-recursively is using readdir internally. The functionallity afterwards is surely not. Yesterday you also got the message ‘populating '/mnt'…’ before the symlink struggle. Therefore I assume that your current error has nothing to do with the bootloader installation. Maybe there are leftovers from yesterday in /mnt, which prevent guix to copy files sucessfully onto /dev/mmcblk0p2? Reformatting the ext4 filesystem might help. Bye Stefan
Hi Stefan, > > So now I get some weird guix error during copying files: > > > initializing operating system under '/mnt'... > > copying to '/mnt'... [#################### ]guix system: error: readdir: Bad message > > copying to '/mnt'... > > > The function make-grub-efi-netboot-installer in gnu/bootloader/grub.scm first uses copy-recursively to copy the collection of bootloader files to /mnt/boot/efi and creates afterwards the symlinks to /gnu/store and /boot/grub/grub.cfg or – as in your case – creates a /mnt/boot/efi/efi/boot/grub.cfg to point GRUB to the root partition to access /boot/grub/grub.cfg and /gnu/store. > > Yesterday your guix system init struggled to create these symlinks. That means it was already done with the copy-recursively call. > > I’m pretty sure that this copy-recursively is using readdir internally. The functionallity afterwards is surely not. > > Yesterday you also got the message ‘populating '/mnt'…’ before the symlink struggle. Therefore I assume that your current error has nothing to do with the bootloader installation. > > Maybe there are leftovers from yesterday in /mnt, which prevent guix to copy files sucessfully onto /dev/mmcblk0p2? > > Reformatting the ext4 filesystem might help. the issue seems to be connected to my guix instance on the host. I got another weird messages and what finally help was to clean the profile cache in my home dir. I then reformatted the SD card just to be sure. # parted /dev/mmcblk0 GNU Parted 3.5 Using /dev/mmcblk0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: NORELSYS 1081CS0 (scsi) Disk /dev/mmcblk0: 31.3GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 269MB 268MB primary fat32 lba 2 269MB 31.3GB 31.0GB primary ext4 And then I also copied the firmware files [1] neccessary to boot: $ ls /mnt/boot/efi bcm2708-rpi-b.dtb bcm2710-rpi-2-b.dtb bcm2711-rpi-4-b.dtb efi/ fixup_db.dat start4.elf bcm2708-rpi-b-plus.dtb bcm2710-rpi-3-b.dtb bcm2711-rpi-cm4.dtb fixup4cd.dat fixup_x.dat start4x.elf bcm2708-rpi-b-rev1.dtb bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-cm4s.dtb fixup4.dat LICENCE.broadcom start_cd.elf bcm2708-rpi-cm.dtb bcm2710-rpi-cm3.dtb bootcode.bin fixup4db.dat manifest start_db.elf bcm2708-rpi-zero.dtb bcm2710-rpi-zero-2.dtb bootloader.txt fixup4x.dat overlays/ start.elf bcm2708-rpi-zero-w.dtb bcm2710-rpi-zero-2-w.dtb config.txt fixup_cd.dat start4cd.elf start_x.elf bcm2709-rpi-2-b.dtb bcm2711-rpi-400.dtb dtb.txt fixup.dat start4db.elf u-boot.bin The board powers up and I see the RGB screen when the raspberrypi boots. Then it switches to black screen and I don't see any output on the HDMI. Also there is no IP address assigned on the Ethernet even though the port itself is active. I haven't run tcpdump or attached serial adapter yet so I don't know what's wrong and where the system hangs. I'm testing this on Raspberry Pi 4. [1] https://github.com/raspberrypi/firmware ---- Petr
Hi Petr! > the issue seems to be connected to my guix instance on the host. Glad to hear you figured it out. > Then it switches to black screen That should mean that the graphic-card is not set up properly. But additionally U-Boot, GRUB or the kernel could be hanging. :-/ > I'm testing this on Raspberry Pi 4. I prepared everything for a 3b monthes ago. Potentially this does not match the current firmware or kernel anymore or does not fit the 4. Take a look at grub-efi-bootloader-chain-raspi-64 in gnu/packages/raspberry-pi.scm. Read the notes there. Take a look at raspi-custom-txt and the others there as well. You probably have to use it to set some parameters. I use these with an older kernel: dtoverlay=disable-wifi dtoverlay=vc4-fkms-v3d,cma-64 enable_uart=1 My best guess is a missing dtoverlay=vc4-fkms-v3d. I just noticed that there is meanwhile a vc4-fkms-v3d-pi4. Try that first. There are also flavours without the f(ake). Attention with enable_uart, it is set in %raspi-u-boot-bootloader-txt to 1 already. There was once a U-Boot version working without enable_uart, but the recent one seems to require it again. If this does not help, then maybe the kernel needs to be customized. I never heard of somone else running the linux-libre kernel on a Raspberry Pi. :-) The kernel configuration in gnu/system/examples/raspberry-pi-64.tmpl has some comments regarding possible customizations. Bye Stefan
From 1b05398ed9e7adb1fa8822c5d22ebff66bf4f8d8 Mon Sep 17 00:00:00 2001 From: Petr Hodina <phodina@protonmail.com> Date: Wed, 13 Apr 2022 21:18:37 +0200 Subject: [PATCH v3 4/8] gnu: linux: New function to modify the configuration of a Linux kernel. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Stefan <stefan-guix@vodafonemail.de> * gnu/packages/linux.scm (system->linux-srcarch): New function to return the relevent folder name below arch/ in the Linux source code. (make-linux-libre*) ['set-environment]: Splitted this new phase out of and adding it before … ['configure]: … to allow a replacement and reuse from (modify-linux). (modify-linux): New function to make a customized Linux package inherited from another Linux package, which will be build with an own defconfig or configuration changes. (make-defconfig): Function to get a defconfig from an uri. diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm index a405837bb1..48c7797095 100644 --- a/gnu/packages/linux.scm +++ b/gnu/packages/linux.scm @@ -59,7 +59,8 @@ ;;; Copyright © 2021 Josselin Poiret <josselin.poiret@protonmail.ch> ;;; Copyright © 2021 Olivier Dion <olivier.dion@polymtl.ca> ;;; Copyright © 2021 Solene Rapenne <solene@perso.pw> -;;; Copyright © 2021 Petr Hodina <phodina@protonmail.com> +;;; Copyright © 2021, 2022 Petr Hodina <phodina@protonmail.com> +;;; Copyright © 2021 Stefan <stefan-guix@vodafonemail.de> ;;; Copyright © 2022 Artyom V. Poptsov <poptsov.artyom@gmail.com> ;;; @@ -179,6 +180,7 @@ (define-module (gnu packages linux) #:use-module (srfi srfi-2) #:use-module (srfi srfi-26) #:use-module (ice-9 match) + #:use-module (ice-9 optargs) #:use-module (ice-9 regex)) (define-public (system->linux-architecture arch) @@ -195,6 +197,21 @@ (define-public (system->linux-architecture arch) ((string-prefix? "riscv" arch) "riscv") (else arch)))) +(define-public (system->linux-srcarch arch) + "Return for a Guix system ARCH name the SRCARCH name, which is set in the +toplevel Makefile of Linux and denotes the architecture specific directory name +below arch/ in its source code. Some few architectures share a common folder. +It resembles the definition of SRCARCH based on ARCH in the Makefile and may +be used to place a defconfig file in the proper path." + (let ((linux-arch (system->linux-architecture arch))) + (match linux-arch + ("i386" "x86") + ("x86_64" "x86") + ("sparc32" "sparc") + ("sparc64" "sparc") + ("sh64" "sh") + (_ linux-arch)))) + (define-public (system->defconfig system) "Some systems (notably powerpc-linux) require a special target for kernel defconfig. Return the appropriate make target if applicable, otherwise return @@ -852,7 +869,7 @@ (define* (make-linux-libre* version gnu-revision source supported-systems (lambda _ (substitute* (find-files "." "^Makefile(\\.include)?$") (("/bin/pwd") "pwd")))) - (replace 'configure + (add-before 'configure 'set-environment (lambda* (#:key inputs target #:allow-other-keys) ;; Avoid introducing timestamps. (setenv "KCONFIG_NOTIMESTAMP" "1") @@ -877,8 +894,10 @@ (define* (make-linux-libre* version gnu-revision source supported-systems (setenv "EXTRAVERSION" #$(and extra-version - (string-append "-" extra-version))) + (string-append "-" extra-version))))) + (replace 'configure + (lambda* (#:key inputs native-inputs #:allow-other-keys) (let ((build (assoc-ref %standard-phases 'build)) (config (assoc-ref inputs "kconfig"))) @@ -1210,6 +1229,111 @@ (define-public linux-libre-with-bpf (inputs (modify-inputs (package-inputs base-linux-libre) (prepend cpio)))))) + +;;; +;;; Linux kernel customization functions. +;;; + +(define*-public (modify-linux #:key name + (linux linux-libre) + source + defconfig + (configs "") + extra-version) + "Make a Linux package NAME as a modification of another LINUX package. + +If NAME is not given, then it defaults to the same name as the LINUX package. + +Unless SOURCE is given the source of LINUX is used. + +A DEFCONFIG file to be used can be given as a package, as a file like object +(file-append, local-file etc.), or as a string with the name of a defconfig file +available in the Linux sources. If DEFCONFIG is not given, then a defconfig +file will be saved from the LINUX package configuration. + +Additional CONFIGS will be used to modify the given or saved defconfig, which +will finally be used to build Linux. + +CONFIGS can be a list of strings, with one configuration per line. The usual +defconfig syntax has to be used, but there is a special extension to ease the +removal of configurations. Comment lines are supported as well. + +Here is an explaining usage example: + + '(;; This string defines the version tail in 'uname -r'. + \"CONFIG_LOCALVERSION=\\\"-handcrafted\\\" + ;; This '# CONFIG_… is not set' syntax has to match exactly! + \"# CONFIG_BOOT_CONFIG is not set\" + \"CONFIG_NFS_SWAP=y\" + ;; This is a multiline configuration: + \"CONFIG_E1000=y +# This is a comment, below follow two special removal extensions: +CONFIG_CMDLINE_EXTEND +CONFIG_CMDLINE_FORCE=\") + +A string of configurations instead of a list of configuration strings is also +possible. + +EXTRA-VERSION can be a string overwriting the EXTRAVERSION setting of the LINUX +package, after being prepended by a hyphen. It will be visible in the output +of 'uname -r' behind the Linux version numbers." + (package + (inherit linux) + (name (or name (package-name linux))) + (source (or source (package-source linux))) + (arguments + (substitute-keyword-arguments + (package-arguments linux) + ((#:imported-modules imported-modules %gnu-build-system-modules) + `((guix build kconfig) ,@imported-modules)) + ((#:modules modules) + `((guix build kconfig) ,@modules)) + ((#:phases phases) + `(modify-phases ,phases + (replace 'configure + (lambda* (#:key inputs #:allow-other-keys #:rest arguments) + (let* ((srcarch + ,(system->linux-srcarch (or (%current-target-system) + (%current-system)))) + (configs (string-append "arch/" srcarch "/configs/")) + (guix_defconfig (string-append configs "guix_defconfig"))) + ,(cond + ((not defconfig) + `(begin + ;; Call the original 'configure phase. + (apply (assoc-ref ,phases 'configure) arguments) + ;; Save a defconfig file. + (invoke "make" "savedefconfig") + ;; Move the saved defconfig to the proper location. + (rename-file "defconfig" + guix_defconfig))) + ((string? defconfig) + ;; Use another existing defconfig from the Linux sources. + `(rename-file (string-append configs ,defconfig) + guix_defconfig)) + (else + ;; Copy the defconfig input to the proper location. + '(copy-file (assoc-ref inputs "guix_defconfig") + guix_defconfig))) + (modify-defconfig guix_defconfig ',configs) + ,@(if extra-version + `((setenv "EXTRAVERSION" + ,(string-append "-" extra-version))) + '()) + (invoke "make" "guix_defconfig")) + #t)))))) + (native-inputs + (append (if (or (not defconfig) + (string? defconfig)) + '() + ;; The defconfig should be a package or file-like object. + `(("guix_defconfig" ,defconfig))) + (package-native-inputs linux))))) + +(define-public (make-defconfig uri sha256-as-base32) + (origin (method url-fetch) + (uri uri) + (sha256 (base32 sha256-as-base32)))) ;;; -- 2.35.1