U-Boot for Raspberry Pi

U-Boot for Raspberry Pi

[phodina via]

Hi,

I'm trying to run Guix System on Raspberry Pi. In order to do that we need a way to boot it up.

There is the nonfree Broadcom bootloader, which does the job and it's used by many distributions.

However, there is also an open source alternative as U-Boot supports the BCM SoCs.

I had look at different u-boot definitions under gnu/packages/bootloaders.scm and gnu/bootloader.scm.

From my understanding the way how to define a new board is find the defconfig name in the configs directory in U-Boot.
Then use the make-u-boot-package with the config name and target triplet to define the package.

Unfortunately, the definitions below are not found by Guix if I run guix search -L. raspberry

If I inherit from the u-boot itself and specify the name, it's then in the list and I can build it.
But the I can't use the package for the bootloader record.

There must be something trivial I had overlooked.

Could you please guide me on the procedure for porting the u-boot to new board as a new Guix package?

--8<---------------cut here---------------start------------->8---
(define-module (raspberry-pi)
#:use-module (guix packages)
#:use-module (gnu packages bootloaders)
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix build-system gnu)
#:use-module ((guix licenses) #:prefix license:))

(define-public u-boot-raspberry-pi-2
(make-u-boot-package "rpi_2" "arm-linux-gnueabihf"))

(define-public u-boot-raspberry-pi-3
(make-u-boot-package "rpi_3" "aarch64-linux-gnu"))

(define-public u-boot-raspberry-pi-4
(make-u-boot-package "rpi_4" "aarch64-linux-gnu"))

Re: U-Boot for Raspberry Pi

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On 2021-10-30, phodina via wrote:
> I'm trying to run Guix System on Raspberry Pi. In order to do that we
> need a way to boot it up.
>
> There is the nonfree Broadcom bootloader, which does the job and it's
> used by many distributions.
>
> However, there is also an open source alternative as U-Boot supports
> the BCM SoCs.

Well, you still need to load u-boot from the broadcom
firmware/bootloader...


> If I inherit from the u-boot itself and specify the name, it's then in the list and I can build it.
> But the I can't use the package for the bootloader record.
>
> There must be something trivial I had overlooked.
>
> Could you please guide me on the procedure for porting the u-boot to new board as a new Guix package?

There are install targets defined in gnu/bootloader/u-boot.scm, though
most (all?) of those targets install to a raw device offset, whereas
u-boot for the rpi needs u-boot.bin to be copied to your firmware
partition and needs to be specified as a "kernel" in config.txt, if I
recall correctly.


> (define-public u-boot-raspberry-pi-4
> (make-u-boot-package "rpi_4" "aarch64-linux-gnu"))

I would also try to keep the u-boot-BOARD matching the defconfig,
e.g. u-boot-rpi-4 instead of u-boot-raspberry-pi-4. Not for any
technical reason, per se, just keeping the u-boot target naming
consistent.

You might want to just build the u-boot package, and then manually copy
it to your firmware partition and configure that appropriately once, and
then just use guix to generate and update the extlinux.conf... I forget
the exact syntax to generate extlinux.conf without actually installing
u-boot, but I've done it in the past.

Another option would be to build the raspberry pi UEFI (not 100% sure of
the licensing, but reasonably free) instead of u-boot, and then use
guix's standard UEFI configuration with grub-efi and such.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: U-Boot for Raspberry Pi

[phodina]

Hi vagrant,

On Sunday, October 31st, 2021 at 12:05 AM, Vagrant Cascadian <vagrant@debian.org> wrote:

> On 2021-10-30, phodina via wrote:
>
> > I'm trying to run Guix System on Raspberry Pi. In order to do that we
> >
> > need a way to boot it up.
> >
> > There is the nonfree Broadcom bootloader, which does the job and it's
> >
> > used by many distributions.
> >
> > However, there is also an open source alternative as U-Boot supports
> >
> > the BCM SoCs.
>
> Well, you still need to load u-boot from the broadcom
>
> firmware/bootloader...

Yes, unfortunately you are right. The VC4 GPU core is started first and requires
the closed source binaries (bootcode.bin, start.elf and fixup.dat).

Also no disrespect was meant to the Guix help mailing list. I thought the closed source code could
be avoided.

>
> > If I inherit from the u-boot itself and specify the name, it's then in the list and I can build it.
> >
> > But the I can't use the package for the bootloader record.
> >
> > There must be something trivial I had overlooked.
> >
> > Could you please guide me on the procedure for porting the u-boot to new board as a new Guix package?
>
> There are install targets defined in gnu/bootloader/u-boot.scm, though
>
> most (all?) of those targets install to a raw device offset, whereas
>
> u-boot for the rpi needs u-boot.bin to be copied to your firmware
>
> partition and needs to be specified as a "kernel" in config.txt, if I
>
> recall correctly.

As you correctly pointed out that you can specify in the config.txt the next executable
to be loaded which in this case is the u-boot.

Also with U-boot it's the usually the case that you place it at specific flash location.

However, Raspberry Pi has BootRom which is able to access FAT file system
and load files from there. Therefore the SD card has to be formatted with
MBR layout, FAT boot partition and then let's say Linux root partition.

>
> > (define-public u-boot-raspberry-pi-4
> >
> > (make-u-boot-package "rpi_4" "aarch64-linux-gnu"))
>
> I would also try to keep the u-boot-BOARD matching the defconfig,
>
> e.g. u-boot-rpi-4 instead of u-boot-raspberry-pi-4. Not for any
>
> technical reason, per se, just keeping the u-boot target naming
>
> consistent.

Good idea. Though the longer version would be more readable.

>
> You might want to just build the u-boot package, and then manually copy
>
> it to your firmware partition and configure that appropriately once, and
>
> then just use guix to generate and update the extlinux.conf... I forget

That's the point of my original question as I created this package definition.
It builds fine and all the files are there. But as stated above can't be passed
to the bootloader record in the operating-system.

(define-public u-boot-rpi-2
  (let ((base (make-u-boot-package "rpi_2" "arm-linux-gnueabihf")))
  (package
  (inherit base)
  (name "uboot-rpi-2"))))

The contents of the package are here:

tree /gnu/store/77syxs86n0c52pslnzfsn9xzv1dzmxhc-uboot-rpi-2-2021.10/libexec
/gnu/store/77syxs86n0c52pslnzfsn9xzv1dzmxhc-uboot-rpi-2-2021.10/libexec
├── arch
│   └── arm
│       └── dts
│           ├── bcm2835-rpi-a.dtb
│           ├── bcm2835-rpi-a-plus.dtb
│           ├── bcm2835-rpi-b.dtb
│           ├── bcm2835-rpi-b-plus.dtb
│           ├── bcm2835-rpi-b-rev2.dtb
│           ├── bcm2835-rpi-cm1-io1.dtb
│           ├── bcm2835-rpi-zero.dtb
│           ├── bcm2835-rpi-zero-w.dtb
│           ├── bcm2836-rpi-2-b.dtb
│           ├── bcm2837-rpi-3-a-plus.dtb
│           ├── bcm2837-rpi-3-b.dtb
│           ├── bcm2837-rpi-3-b-plus.dtb
│           └── bcm2837-rpi-cm3-io3.dtb
├── doc
│   └── README.commands.spl
├── dts
│   └── dt.dtb
├── lib
│   └── efi_loader
│       └── helloworld.efi
├── scripts
│   └── Makefile.spl
├── tools
│   └── binman
│       └── test
│           └── descriptor.bin
├── u-boot
├── u-boot.bin
└── u-boot-nodtb.bin

>
> the exact syntax to generate extlinux.conf without actually installing
>
> u-boot, but I've done it in the past.

So do I now need to define a new bootloader target in gnu/bootloader/u-boot.scm,
where instead of writing directly to the image follow more the pattern of function
install-grub-efi, where based on the UEFI you also need to have EFI FAT partition
and just copy the files over to their correct location?

>
> Another option would be to build the raspberry pi UEFI (not 100% sure of
>
> the licensing, but reasonably free) instead of u-boot, and then use
>
> guix's standard UEFI configuration with grub-efi and such.

Then I can treat the closed source firmware to boot as UEFI and
just package the u-boot, right?

>
> live well,
>
> vagrant

Re: U-Boot for Raspberry Pi

[Stefan]

Hi!

There is already a patch series available since May – patiently awaiting a review –, which brings support for the Raspberry Pi. It even supports booting via NFS, which helps to avoid all the common troubles with microSD cards. 

For the usual mircoSD card installation just partition and format it as usual, and put the well known bootloader blob on the FAT partition. Then do a ‘guix system init config.scm /mnt/microsd’. The patch series contains an example configuration at ‘gnu/system/examples/raspberry-pi-64.tmpl’.   

Take a look here: <http://issues.guix.gnu.org/48314#10>


In hope to get more attention and interest for a review, allow me to add two side notes.

Ever in need for a Guix System on an USB thump drive? Give the new ‘grub-efi-netboot-removable-bootloader’ a try instead of ‘grub-efi-bootloader’. It is not only usable for booting over network.

Ever in need to quickly modify the kernel Linux? Give the new function ‘modify-linux’ a try. For the Raspberry this is needed to get the kernel linux-libre working. (By the way, would Guix System be the first distribution using a libre kernel on the Raspberry?)

For example to enable NFS root functionality for virtual machines, use a kernel definition like this in your operating-system definition:

(kernel (modify-linux #:configs '("CONFIG_E1000=y"
                                  "CONFIG_ROOT_NFS=y"
                                  "CONFIG_NFS_FS=y"
                                  "CONFIG_NFS_V4=y")))

Bye

Stefan

Re: U-Boot for Raspberry Pi

[phodina]

Hi Stefan,

On Monday, November 1st, 2021 at 12:09 AM, Stefan <stefan-guix@vodafonemail.de> wrote:

> Hi!
>
> There is already a patch series available since May – patiently awaiting a review –, which brings support for the Raspberry Pi. It even supports booting via NFS, which helps to avoid all the common troubles with microSD cards.

Thanks for your amazing work! I've applied the patches and it builds the system.

>
> For the usual mircoSD card installation just partition and format it as usual, and put the well known bootloader blob on the FAT partition. Then do a ‘guix system init config.scm /mnt/microsd’. The patch series contains an example configuration at ‘gnu/system/examples/raspberry-pi-64.tmpl’.


However, I ran into several issues.

Firstly it's hard to run the init command as it requires root.
What I did is the following:

sudo guix environment --pure guix --ad-hoc coreutils findutils which

This gives me pure environment with the patches and root access.

Do you have different suggestion on how to invoke the guix system init command?

Secondly I have to run the command to init the system on the microSD card with the following flag --skip-checks:

[env]# ./pre-inst-env guix system init -s aarch64-linux gnu/system/examples/raspberry-pi-64.tmpl /mnt  --skip-checks

Otherwise I have to build with the following initrd config:

(initrd-modules (append (list "mmc_block" "rtsx_pci_sdmmc" "rtsx_pci")
   ;;                             %base-initrd-modules))

But adding these the build fails. Thought they might be needed as the kernel needs to access the blocks on microSD.

Another issue were certificates:

...
initializing operating system under '/mnt'...
copying to '/mnt'...  [#########################################################                                                    ]i/o error: /gnu/store/j76446v1asknzjl5lvzp9mnrg8gxl24d-nss-certs-3.59/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem: No such file or directory
copying to '/mnt'...  [##################################################################                                           ]i/o error: /gnu/store/db3kp42msgw9f53jk5hvp2bgsaq6jdyv-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem: No such file or directory
copying to '/mnt'...
populating '/mnt'...

Lastly the init fails as the FAT file system not supporting symlinks.

guix system: error: symlink: Operation not permitted: "/boot/efi/gnu/store"

I formatted the microSD card with FAT32 and Ext4 partitions.
The FAT32 partition is mounted to /boot.

Could you please help me as I've might done something incorrectly?

>
> Take a look here: http://issues.guix.gnu.org/48314#10
>
> In hope to get more attention and interest for a review, allow me to add two side notes.
>
> Ever in need for a Guix System on an USB thump drive? Give the new ‘grub-efi-netboot-removable-bootloader’ a try instead of ‘grub-efi-bootloader’. It is not only usable for booting over network.
>
> Ever in need to quickly modify the kernel Linux? Give the new function ‘modify-linux’ a try. For the Raspberry this is needed to get the kernel linux-libre working. (By the way, would Guix System be the first distribution using a libre kernel on the Raspberry?)
>
> For example to enable NFS root functionality for virtual machines, use a kernel definition like this in your operating-system definition:
>
> (kernel (modify-linux #:configs '("CONFIG_E1000=y"
>
> "CONFIG_ROOT_NFS=y"
>
> "CONFIG_NFS_FS=y"
>
> "CONFIG_NFS_V4=y")))
>
> Bye
>
> Stefan

Re: U-Boot for Raspberry Pi

[Stefan]

Hi!

> Thanks for your amazing work! I've applied the patches and it builds the system.

Welcome, and thanks for the feedback.

> However, I ran into several issues.

Your troubles might indicate that you didn’t properly mount the ext4 and FAT file systems below /mnt. You should follow the manual regarding an EFI system¹: Mount the ext4 partition of the microSD card at /mnt and the FAT partition of the microSD card at /mnt/boot/efi – you will have to call ‘mkdir -p /mnt/boot/efi’ after mounting the ext4 partition and before mounting the FAT partition.

> Do you have different suggestion on how to invoke the guix system init command?

Please separate build and installation. First build guix as described in the manual² without any sudo but inside its build environment with the amount of cores you like to use:

$ guix environment --pure guix
$ ./bootstrap
$ ./configure --localstatedir=/var
$ make -j 4
$ exit

Then use the new guix outside its build environment to initialize the system with sudo:

$ sudo -E ./pre-inst-env guix system init --system=aarch64-linux gnu/system/examples/raspberry-pi-64.tmpl /mnt

The --system flag is needed in your case executing the command on a host PC. However, I built and installed my system directly on the Raspberry, so I didn’t use it. Also --skip-checks was not necessary in my case. But building guix with only 1 GB is meanwhile close to impossible.

Is there possibly an issue with checks when installing for another system? It could also be that these checks got “improved” but fail in this case. At least additional initrd modules are not needed. So just add the --skip-checks option, if guix complains otherwise.

I hope this will solve your issues.

The certificate issues could have been due to your unconventional use of sudo. The symlink issue must have been due to the wrong mount point of the FAT partition.


Bye

Stefan


¹ <https://guix.gnu.org/devel/devel/manual/en/guix.html#Bootloader>
² <https://guix.gnu.org/devel/devel/manual/en/guix.html#Building-from-Git>

Re: U-Boot for Raspberry Pi

[Reza Alizadeh Majd]

Hi Stefan, 

First of all, thanks for your great work to bring the Guix for RPi. 


>Your troubles might indicate that you didn’t properly mount the ext4
>and FAT file systems below /mnt. You should follow the manual
>regarding an EFI system¹: Mount the ext4 partition of the microSD card
>at /mnt and the FAT partition of the microSD card at /mnt/boot/efi –
>you will have to call ‘mkdir -p /mnt/boot/efi’ after mounting the ext4
>partition and before mounting the FAT partition.
>
>> Do you have different suggestion on how to invoke the guix system
>> init command?  
>
>Please separate build and installation. First build guix as described
>in the manual² without any sudo but inside its build environment with
>the amount of cores you like to use:
>
>$ guix environment --pure guix
>$ ./bootstrap
>$ ./configure --localstatedir=/var
>$ make -j 4
>$ exit
>
>Then use the new guix outside its build environment to initialize the
>system with sudo:
>
>$ sudo -E ./pre-inst-env guix system init --system=aarch64-linux
>gnu/system/examples/raspberry-pi-64.tmpl /mnt


I just followed your instructions from Guix host machine, but I faced
following error during the `guix system init process: 

--8<---------------cut here---------------start------------->8---
@ unsupported-platform /gnu/store/4dc56sq286h0pdvs0s6917vvzlr9xsrg-module-import-compiled.drv aarch64-linux
while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/4dc56sq286h0pdvs0s6917vvzlr9xsrg-module-import-compiled.drv', but I am a `x86_64-linux'
--8<---------------cut here---------------end--------------->8---

it seems that the `--system=aarch64-linux` doesn't work as expected to
cross-compile the image for RPi. 

here is more details about my build process: 
- I tried to build the Guix for RPi compute module 4 with embedded 32GB
  emmc. 
- identified the `rootfs` and `boot` partitions using usbboot [1].
- mounted the `rootfs` to the `/mnt`
- created the `/mnt/boot/efi` prior to mounting the `boot` partition
  there. 
- added following required initrd modules to the system configuration.

--8<---------------cut here---------------start------------->8---
 (initrd-modules (append (list "uas" "usb_storage")
                                %base-initrd-modules))
  (initrd-modules (append (list "uas" "usb_storage")
  %base-initrd-modules))
--8<---------------cut here---------------end--------------->8---


1. https://github.com/raspberrypi/usbboot


Best, 
Reza


-- 
Reza Alizadeh Majd
PantherX Team
https://pantherx.org

Re: U-Boot for Raspberry Pi

[Ricardo Wurmus]

Reza Alizadeh Majd <r.majd@pantherx.org> writes:

> it seems that the `--system=aarch64-linux` doesn't work as expected to
> cross-compile the image for RPi. 

Are you using qemu-binfmt-service-type?

-- 
Ricardo

Re: U-Boot for Raspberry Pi

[Reza Alizadeh Majd]

On Sat, 19 Feb 2022 00:12:37 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

>
>Are you using qemu-binfmt-service-type?
>

Thank you, adding the service to the host machine, resolves the build
issue. 


however the previously mentioned issue in this thread about
the `mmc_block` kernel module still persists during the build:

adding the following kernel modules: 

--8<---------------cut here---------------start------------->8---
(initrd-modules (append (list "mmc_block" "rtsx_pci_sdmmc" "rtsx_pci")
                        %base-initrd-modules))
--8<---------------cut here---------------end--------------->8---

I receive following error: 

--8<---------------cut here---------------start------------->8---
Backtrace:
           5 (primitive-load "/gnu/store/gdz17k41dvf1b38y9wzs8assi9n?")
In ice-9/eval.scm:
    619:8  4 (_ #f)
   626:19  3 (_ #<directory (guile-user) 7fffb6a71f00>)
   293:34  2 (_ #(#<directory (guile-user) 7fffb6a71f00> #<procedu?>))
In srfi/srfi-1.scm:
   586:17  1 (map1 ("mmc-block" "rtsx_pci_sdmmc" "rtsx_pci" "ahci" ?))
In gnu/build/linux-modules.scm:
    257:5  0 (find-module-file _ _)

gnu/build/linux-modules.scm:257:5: In procedure find-module-file:
kernel module not found "mmc-block" "/gnu/store/8pms0r4zvqxx6bqaz8rw2h3ynjfynqdx-linux-libre-arm64-generic-5.14.15/lib/modules"
--8<---------------cut here---------------end--------------->8---


Regards, 
Reza

-- 
Reza Alizadeh Majd
PantherX Team
https://pantherx.org

Re: U-Boot for Raspberry Pi

[Ricardo Wurmus]

Reza Alizadeh Majd <r.majd@pantherx.org> writes:

> however the previously mentioned issue in this thread about
> the `mmc_block` kernel module still persists during the build:
>
> adding the following kernel modules: 
>
> (initrd-modules (append (list "mmc_block" "rtsx_pci_sdmmc" "rtsx_pci")
>                         %base-initrd-modules))
>
>
> I receive following error: 
>
> Backtrace:
>            5 (primitive-load "/gnu/store/gdz17k41dvf1b38y9wzs8assi9n?")
> In ice-9/eval.scm:
>     619:8  4 (_ #f)
>    626:19  3 (_ #<directory (guile-user) 7fffb6a71f00>)
>    293:34  2 (_ #(#<directory (guile-user) 7fffb6a71f00> #<procedu?>))
> In srfi/srfi-1.scm:
>    586:17  1 (map1 ("mmc-block" "rtsx_pci_sdmmc" "rtsx_pci" "ahci" ?))
> In gnu/build/linux-modules.scm:
>     257:5  0 (find-module-file _ _)
>
> gnu/build/linux-modules.scm:257:5: In procedure find-module-file:
> kernel module not found "mmc-block" "/gnu/store/8pms0r4zvqxx6bqaz8rw2h3ynjfynqdx-linux-libre-arm64-generic-5.14.15/lib/modules"

mmc-block or mmc_block?

What does the directory contain?  If the module doesn’t exist you’ll
have to build a kernel with a configuration that enables this module.

-- 
Ricardo

Re: U-Boot for Raspberry Pi

[Reza Alizadeh Majd]

On Mon, 21 Feb 2022 12:14:50 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:


>
>mmc-block or mmc_block?

based on the following thread I thought that it might be the issue with
module name, so I tested with both mmc_block an mmc-block.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34902

unfortunately neither of those worked for me and I received the error
message I mentioned before. 

>
>What does the directory contain?  If the module doesn’t exist you’ll
>have to build a kernel with a configuration that enables this module.
>


--8<---------------cut here---------------start------------->8---
$ find /gnu/store/*-linux-libre-arm64-generic-5.14.15/lib/modules -name '*mmc*'
/gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc
/gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/mmc_spi.ko
/gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/of_mmc_spi.ko
--8<---------------cut here---------------end--------------->8---

so it seems that the module is actually not available. is that because
of the the libre kernel restrictions?



-- 
Reza Alizadeh Majd
PantherX Team
https://pantherx.org

Re: U-Boot for Raspberry Pi

[Ricardo Wurmus]

Reza Alizadeh Majd <r.majd@pantherx.org> writes:

> On Mon, 21 Feb 2022 12:14:50 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>
>>
>>mmc-block or mmc_block?
>
> based on the following thread I thought that it might be the issue with
> module name, so I tested with both mmc_block an mmc-block.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34902
>
> unfortunately neither of those worked for me and I received the error
> message I mentioned before. 
>
>>
>>What does the directory contain?  If the module doesn’t exist you’ll
>>have to build a kernel with a configuration that enables this module.
>>
>
> $ find /gnu/store/*-linux-libre-arm64-generic-5.14.15/lib/modules -name '*mmc*'
> /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc
> /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/mmc_spi.ko
> /gnu/store/gjm8fcl4z9zl7qql5d3cvpbrdlkfjx27-linux-libre-arm64-generic-5.14.15/lib/modules/5.14.15-gnu-v7l/kernel/drivers/mmc/host/of_mmc_spi.ko
>
> so it seems that the module is actually not available. is that because
> of the the libre kernel restrictions?

What restrictions?

The list of modules depends largely on the kernel configuration.  I
encourage you to check if you need to add something to the kernel
configuration and build your own kernel.

-- 
Ricardo

Re: U-Boot for Raspberry Pi

[Vincent Legoll]

Hello Reza Alizadeh Majd,

On Tue, Feb 22, 2022 at 9:31 AM Ricardo Wurmus <rekado@elephly.net> wrote:
> The list of modules depends largely on the kernel configuration.  I
> encourage you to check if you need to add something to the kernel
> configuration and build your own kernel.

See here for details on how to achieve this:
https://guix.gnu.org/en/cookbook/en/html_node/Customizing-the-Kernel.html#Customizing-the-Kernel

I was about to suggest:

The config item you will probably need to add is
CONFIG_MMC_BLOCK=y (in .config syntax)
or
("CONFIG_VIRTIO_BLK" . m) (in guix guile syntax)

but then I had a look:

~/dev/repo/upstream/guix$ grep -r 'CONFIG_MMC_BLOCK='
./gnu/packages/aux-files/linux-libre/*-arm*.conf
./gnu/packages/aux-files/linux-libre/4.14-arm.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/4.19-arm64.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/4.19-arm.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.10-arm64.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.10-arm.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.15-arm64.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.15-arm.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.16-arm64.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.16-arm.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.4-arm64.conf:CONFIG_MMC_BLOCK=y
./gnu/packages/aux-files/linux-libre/5.4-arm.conf:CONFIG_MMC_BLOCK=y

it looks like this option is already properly set to "y" for all
relevant guix kernels...

Sorry, someone more familiar with this part of guix will have to chime in to
help further.

Regards

-- 
Vincent Legoll

Re: U-Boot for Raspberry Pi

[Vincent Legoll]

On Tue, Feb 22, 2022 at 10:05 AM Vincent Legoll
<vincent.legoll@gmail.com> wrote:
> I was about to suggest:
> ("CONFIG_VIRTIO_BLK" . m) (in guix guile syntax)

modulo the copy/paste gotcha, it should have been

("CONFIG_VIRTIO_BLK" . y) (in guix guile syntax)

-- 
Vincent Legoll