universal aarch64/riscv64 images

universal aarch64/riscv64 images

[Efraim Flashner]

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

I've been thinking some about how we create our disk images for aarch64
devices and how we'll eventually create images for riscv64 devices.
Currently we use u-boot to load extlinux to boot linux. I propose we use
u-boot with its EFI interface to load grub-efi to boot linux.

Major benefit of this is that we can create one generic aarch64 image
using raw-with-offset to create the image and then ship a separate
script to flash either the SD card or an SPI chip or whatever someone
wants. We also don't need to reflash u-boot at every reconfigure (I
couldn't follow the code well enough to see if that's currently the
case), just regenerate extlinux or grub-efi like we do on x86_64.

Currently here's the script to install u-boot on the disk image for a pine64:

(define install-allwinner64-u-boot
  #~(lambda (bootloader root-index image)
      (let ((spl (string-append bootloader "/libexec/u-boot-sunxi-with-spl.bin"))
            (u-boot (string-append bootloader "/libexec/u-boot-sunxi-with-spl.fit.itb")))
        (write-file-on-device spl (stat:size (stat spl))
                              image (* 8 1024))
        (write-file-on-device u-boot (stat:size (stat u-boot))
                              image (* 40 1024)))))

And in the OS config:

    (bootloader (bootloader-configuration
                 (bootloader u-boot-pine64-lts-bootloader)
                 (targets '("/dev/vda"))))

This would transition to (work in progress):

(define install-allwinner64-u-boot
  #~(lambda (bootloader root-index image)
      (let ((spl (string-append bootloader "/libexec/u-boot-sunxi-with-spl.bin"))
            (u-boot (string-append bootloader "/libexec/u-boot-sunxi-with-spl.fit.itb")))
        (write-file-on-device spl (stat:size (stat spl))
                              image (* 8 1024))
        (write-file-on-device u-boot (stat:size (stat u-boot))
                              image (* 40 1024)))))

;; This needs to be fixed up to actually work!!
;; To be run (as root): 'u-boot-installer-pine64-lts /dev/sda'
(define-public u-boot-installer-pine64-lts
  (program-file "u-boot-installer-pine64-lts"
    #~((let ((bootloader u-boot-pine64-lts)
             (image $1)))
       #$(install-allwinner-u-boot))))

(bootloader (bootloader-configuration
             (bootloader grub-efi)
             (targets '("/dev/vda"))))

(extra-special-file `(("/sbin/flash-u-boot" ,u-boot-installer-pine64-lts)))



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: universal aarch64/riscv64 images

[Vagrant Cascadian]

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

On 2023-02-27, Efraim Flashner wrote:
> I've been thinking some about how we create our disk images for aarch64
> devices and how we'll eventually create images for riscv64 devices.
> Currently we use u-boot to load extlinux to boot linux. I propose we use
> u-boot with its EFI interface to load grub-efi to boot linux.
>
> Major benefit of this is that we can create one generic aarch64 image
> using raw-with-offset to create the image and then ship a separate
> script to flash either the SD card or an SPI chip or whatever someone
> wants.

It is certainly worth exploring this!

That said...

By default u-boot will pass a device-tree from the one included u-boot,
which may or may not be compatible with the kernel you want to
boot. There is a mechanism for grub to load a specific device-tree,
but... that will be device-specific again, kind of weakening the
benefits of a device-agnostic "universal" image. Or fix grub to support
a device-tree-directory (much like u-boot syslinux/extlinux support).

U-boot does not (yet?) implement EFI variables, such as the boot order
for EFI to load, so you have to use the fallback /EFI/BOOT/BOOTX64.efi
path, rather than, say, /EFI/GUIX/GRUBX64.efi.

There are probably more surprises!


Ideally, you could build an image that supports both grub-efi and one of
u-boot's other boot methods (boot.scr, syslinux/extlinux style menu,
etc.) ... fundamentally speaking, I do not see any compelling reason you
could not have both grub-efi/grub.cfg and extlinux.conf on the same boot
media, and I have manually built images that do exactly that.

Then people can "bring their own boot firmware" either by using a system
with EFI already out of the box, or installing u-boot (possibly shipped
with guix) to other media, or directly onto the image itself. Or using
https://tow-boot.org, a u-boot fork for some platforms configured to be
installed outside of the boot media when possible (e.g. SPI or eMMC boot
partitions).

For maximal compatibility, I would suggest the first partition should
start at 16MB with an MBR/DOS-style partition table(GPT is basically
incompatible with sunxi64), leaving the rest of the image empty up till
the first partition, so that you can install u-boot directly to the
image if needed or desired. Welcome to the festival of rabbit holes!


live well,
  vagrant

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