Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

> Hi, attached is a draft for a blog post (or a section in the cookbook)
> for explaining how to install the Guix System on an ARM board. WDYT?

LOL! \O/

This should be a cookbook section, and released soon unless other people
find some error or important things missing (I still do not use some ARM
SoC, but hope to test soon)

What about to start a wip-cookbook-install-on-arm branch with a 1/2
weeks time frame to allow patch proposals from interested
parties?... then publish? :-)

I have just a couple of comments and one typo... BTW discussion based on
my comments should be postponed after your section is published in the
cookbook, since I don't have patch proposals :-D

[...]

> Most boards can be booted from an existing GNU+Linux distribution.  You will
> need to install a distribution (any of them) and install GNU Guix on it, using
> e.g. the installer script.

Is it possible to install to SDD (eventually with external HDD) using
another host (e.g. my laptop) with `guix system disk-image...` and then
``dd ... of=/dev/sdX`` on SDD?

[...]

> ### The kernel modules

[...]

AFAIU this is the only "tricky" part for the user: can we find a way for
Guix to help them automagically populate the list of needed initrd
kernel modules for their SoC?

> Your own board may need other kernel modules to boot properly, however it is hard to discover
> them.  Guix can tell you when a module is missing in your configuration file if it is loaded
> as a module.  Most distros however build these modules in the kernel directly, so Guix cannot
> detect them reliably.  Another way to find what drivers might be needed is to look at the output
> of `dmesg`.  You'll find messages such as:

This implies that we are booting a distro on the SoC, so (if possible)
we cannot install using `guix system disk-image`.  This means that the
only way to make Guix automagically know the list of base modules needed
for each SoC should be to... define them in Guix.

Should be possible to extend (gnu system linux-initrd) whith code
defining default-initrd-modules if string-match some specific SoC
architectures (are they detected?) ?

--8<---------------cut here---------------start------------->8---
(define* (default-initrd-modules
           #:optional
           (system (or (%current-target-system)
                       (%current-system))))
  "Return the list of modules included in the initrd by default."
  (define virtio-modules
    ;; Modules for Linux para-virtualized devices, for use in QEMU guests.
    '("virtio_pci" "virtio_balloon" "virtio_blk" "virtio_net"
      "virtio_console" "virtio-rng"))

  `("ahci"                                  ;for SATA controllers
    "usb-storage" "uas"                     ;for the installation image etc.
    "usbhid" "hid-generic" "hid-apple"      ;keyboards during early boot
    "dm-crypt" "xts" "serpent_generic" "wp512" ;for encrypted root partitions
    "nls_iso8859-1"                            ;for `mkfs.fat`, et.al
    ,@(if (string-match "^(x86_64|i[3-6]86)-" system)
          '("pata_acpi" "pata_atiixp"    ;for ATA controllers
            "isci")                      ;for SAS controllers like Intel C602
          '())

    ,@virtio-modules))
--8<---------------cut here---------------end--------------->8---

I mean something like adding a proper form of this pseudocode:

--8<---------------cut here---------------start------------->8---
    ,@(if (string-match "^(<architecture+SoC>)-" system)
          '("sd_mod" "ahci_sunxi"    ;for sunxi ATA controller
            "sunxi-mmc")             ;for sunxi MMC
          '())
--8<---------------cut here---------------end--------------->8---

Obviously there should be quite some work to do to extend our
default-initrd-modules this way for each SoC (or class of SoCs) since we
should find them reading some appropriate documentation or testing
things like you described in this draft, but once done it's forever and
for all :-)

> Installing the Guix System
> --------------------------

[...]

> In this scenario, we use the foreign system as we would the installer iso, using the manual
> installation procedures described in the manual.  Essentially, you have to partition your SSD
> to your liking, format your new partations and make sure to reference the correct partition
                                      ^ i (typo)
[...]

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures