guix-devel
[Top][All Lists]
Advanced

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

Supporting *multiple* bootloaders for arm64 on a single install?


From: Vagrant Cascadian
Subject: Supporting *multiple* bootloaders for arm64 on a single install?
Date: Sun, 06 Jun 2021 14:38:27 -0700

So, I've managed to get a single image that supports booting both the
Pinebook and Pinebook Pro reasonably well! I can pop the microSD card
out of one and put it into the other, and it boots!

Maybe this is not a big deal to those used to x86, but in the ARM world,
it is unfortunately more complicated than one would hope:

  https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

The only problem with my single image for multiple pinebooks variants is
it requires manually installing u-boot to different offsets for Pinebook
Pro (e.g. idbloader.img at sector 2112 rather than sector 64), as parts
of the Pinebook bootloader are installed at overlapping offsets.

I don't think it would be terribly hard to create an image that also
supports booting EFI! And as u-boot can provide an EFI implementation,
it would not be totally unreasonable to want to install both u-boot and
EFI in the same system configuration...

But as I understand it, guix only supports a single bootloader entry. To
support all of the above, I would need three separate bootloader
instances... one for Pinebook, one for Pinebook Pro, and lastly a
grub-efi bootloader.

Installing u-boot-pinebook uses:

(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)))))

Installing u-boot-pinebook-pro-rk3399 uses:

(define install-rockpro64-rk3399-u-boot
  #~(lambda (bootloader root-index image)
      (let ((idb (string-append bootloader "/libexec/idbloader.img"))
            (u-boot (string-append bootloader "/libexec/u-boot.itb")))
        (write-file-on-device idb (stat:size (stat idb))
                              image (* 64 512))
        (write-file-on-device u-boot (stat:size (stat u-boot))
                              image (* 16384 512)))))

(define install-pinebook-pro-rk3399-u-boot install-rockpro64-rk3399-u-boot)

;; yes, these could be refactored into a single function!

But now I need to figure out how to pass a non-default offset for the
"idb" part for rockchip platforms.

In a system config.scm, you'd define it like so:

  (bootloader (bootloader-configuration
               (bootloader u-boot-pinebook-pro-rk3399-bootloader)
               (target "/dev/mmcblk0")))

u-boot-pinebook-pro-rk3399-bootloader is defined in
gnu/bootloader/u-boot.scm, which inherits from u-boot-bootloader, which
inherits from extlinux-bootloader in gnu/bootloader/extlinux.scm...

And somewhere along the way I've lost track of how we get to
install-pinebook-pro-rk3399-u-boot...


Is it possible to definte multiple bootloaders currently, or if not,
what would need to change to be able to support that? Where would one
pass non-default offsets for a given platform?


Strictly speaking, the extlinux.conf generation would be optional for an
EFI generated image(as u-boot can load grub-efi), although at the moment
I'd prefer using extlinux.conf if available as it makes for more
consistent matching of device-tree/.dtb file with the running kernel...


A related idea would be to generate an EFI bootable image with
sufficient emtpy space before the first partition (16MB) and then one
could manually install the appropriate u-boot, maybe with some helper
scripts to avoid having to do it completely manually...


Thoughts, advice, help? :)


live well,
  vagrant

Attachment: signature.asc
Description: PGP signature


reply via email to

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