guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix System on RockPro64


From: Vagrant Cascadian
Subject: Re: Guix System on RockPro64
Date: Wed, 04 May 2022 09:14:40 -0700

On 2022-05-04, Tom Fitzhenry wrote:
> On 4/5/22 04:53, Tobias Platen wrote:
>> I had a look at the guix page, there is a latest version image for the
>> PineBook Pro, which uses the same SoC.
> The SoC is the same, but the PineBook Pro and RockPro64 have different 
> u-boot bootloaders: u-boot-rockpro64-rk3399-bootloader and 
> u-boot-pinebook-pro-rk3399-bootloader, both in gnu/bootloader/u-boot.scm .
...
> However, it's inconvenient that each aarch64 platform needs its own 
> aarch64 image.

You could create a "generic" image that supports UEFI or standard u-boot
methods, and the user can bring-their-own UEFI implementation
(e.g. tianocore, recent versions of u-boot with EFI) or install u-boot
or barebox or whatever manually.

Another approach used by debian-installer images is to ship the image
that is used by all the platforms, and then a small firmware portion
that is device-specific:

  
https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/README.concatenateable_images

It's a little more cumbersome to download two images and dump them onto
the media, although I imagine guix could implement this part and make it
relatively simple, while still having a shared substitute for the bulk
of the image.


> To improve on this, I'm working on Tow-Boot[0] support 
> for Guix. The result is that a single generic aarch64 image will work 
> across all Tow-Boot supported devices[1], including the RockPro64.
>
> 0. https://tow-boot.org/
> 1. https://tow-boot.org/devices/index.html

My understanding was tow-boot was mostly, at this point, something to
avoid installing as part of the distro image. You can basically do the
same thing with mainline u-boot, if you install u-boot to media other
than the distro media. Or does tow-boot have fancier features working
yet (e.g. menu interfaces from the firmware) ?


> +    (initrd-modules '())
> +    (kernel linux-libre-arm64-generic)

I've managed to get the default linux-libre working, installed with
rootfs on SATA. It does require a fairly extensive list of modules to
load in the initrd:

  (kernel linux-libre-5.17) ;; from before it was default
  (initrd-modules
   (append                                                                      
                                                            (list
     ;; scsi modules
     "ahci"
     "libata"
     "sd_mod"
     "scsi_common"
     "t10_pi"
     ;; regulators and clocks
     "rk808-regulator"
     "clk-rk808"
     "fixed"
     "fan53555"
     "rk808"
     "i2c-rk3x"
     "pl330"
     "dwc3"
     "rtc-rk808"
     "sdhci"
     "sdhci-pltfm"
     "dw_mmc"
     "dw_mmc-pltfm"
     ;; "dw_mmc-rockchip"
     "phy_rockchip_pcie"
     "pcie_rockchip_host"
     "nvme")))

I've recently noticed it taking a long time on shutdown or reboot with
"dw_mmc_rockchip" still loaded, but I don't use the mmc bus for anything
other than the bootloader itself installed on microSD. If you're using
microSD or eMMC I'd be curious if that still happened.


Although using the generic kernel, with guix's primitive module handling
from the initrd (essentially looping through the list and manually
loading each one), it might be easier to support a single image with
linux-libre-arm64-generic kernel, where most features are built-in
rather than modular.


live well,
  vagrant

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]