[Top][All Lists]

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

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

From: Danny Milosavljevic
Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install?
Date: Sat, 19 Jun 2021 14:16:10 +0200

Hi Vagrant,

On Sun, 06 Jun 2021 14:38:27 -0700
Vagrant Cascadian <> wrote:

> 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!


> 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.

Uhhh?  Doesn't sound possible to me then to use the same image for both?
I'm probably missing something.

> But as I understand it, guix only supports a single bootloader entry. 

That is correct.

> 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.

Stefan wrote a Guix chain bootloader that is in master--but it's meant
to be only used for bootloaders where there is a primary "bare-metal-loaded"
bootloader and the others are chain-loaded one-after-another from ONE filesystem
(for example Raspberry Pi and/or EFI bootloaders).

(It's currently used in order to use an EFI bootloader hosted on NFS--which
is an awesome way to manage embedded boards)

The chain bootloader itself is one Guix bootloader.

I advise you to search for mails by Stefan on the guix-devel mailing list--those
are very illuminating.

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

    #~(lambda* (bootloader root-index image #:key idb-destination-offset)

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

                                image (or idb-destination-offset (* 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)
> 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...

It's in the "bootloader" record, field "disk-image-installer".

If you search for "bootloader-disk-image-installer" in the Guix source code,
you find the (two) callers of it.

> Is it possible to definte multiple bootloaders [in the same operating-system] 
> currently, 

No--and I don't think that would have any advantages.

If the thing is not a chain then Guix doesn't need to logically split the
bootloaders in the first place.

Ok: stage1 -> stage2 -> stage3 represented as (chain-bootloaders stage1 stage2 

Not ok: stage1-arch1 stage1-arch2 represented as two different bootloaders
that both are specified in the same operating-system inside the same list.

Instead, I think it's fine to just model that as one "weird" bootloader
(arm64-pinebook-generic-bootloader)--especially if both use u-boot anyway and 
especially if they reuse some of their parts anyway (it's gonna have weird
interdependencies in any case--so any apparent modularity would just be a ruse).

> 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?

Could you elaborate on what you mean?  Pass where?  On the Guix command line?

If you mean the disk-image-installer, that's just a procedure (which is run
build-side).  You can make it do whatever you want--including hardcoding weird
offsets.  I'm pretty sure it gets the entire image (one could potentially 
as a parameter anyway.

> 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...

If you do want to chainload grub-efi eventually, that's supported in Guix 
see "efi-bootloader-chain".  It's meant for the end user to be able to use.

> 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...

Yeah, that's possible right now.  After all, you don't have to load the 
guix system disk image on bare metal.  Just boot it in qemu and install u-boot
there for example.  Or even edit the image manually by using dd.  
on almost every ARM system I set up Guix on so far, one or both of those were

That said, it's nice to have officially supported ARM systems where you can just
generate a disk image and it will boot without having to do weird extra stuff
outside Guix.

(In general, I want to reiterate that the buildroot project already has genimage
scripts for almost all ARM boards--and Guix uses genimage anyway!  It makes a 
of sense to write an importer for those instead of reinventing the wheel.  You
really do not want to develop & maintain u-boot installation recipes for all
34432 ARM variants out there yourself--just use the recipes already developed

Attachment: pgpv1ga_mGRLp.pgp
Description: OpenPGP digital signature

reply via email to

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