unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: guix-devel@gnu.org, Stefan <stefan-guix@vodafonemail.de>
Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install?
Date: Sat, 19 Jun 2021 14:16:10 +0200	[thread overview]
Message-ID: <20210619140050.0715df69@scratchpost.org> (raw)
In-Reply-To: <87y2bmznak.fsf@ponder>

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

Hi Vagrant,

On Sun, 06 Jun 2021 14:38:27 -0700
Vagrant Cascadian <vagrant@debian.org> 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!

Awesome!

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

    #~(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 stage3).

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 also
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 mangle)
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 master,
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 generated
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.  (unfortunately,
on almost every ARM system I set up Guix on so far, one or both of those were
necessary)

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 lot
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
instead)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-06-19 12:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06 21:38 Supporting *multiple* bootloaders for arm64 on a single install? Vagrant Cascadian
2021-06-19 12:16 ` Danny Milosavljevic [this message]
2021-06-19 15:11   ` Stefan
2021-06-19 21:03     ` Vagrant Cascadian
2021-06-20  6:00     ` Bengt Richter
2021-06-20 12:57       ` Stefan
2021-06-19 20:42   ` Vagrant Cascadian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210619140050.0715df69@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    --cc=stefan-guix@vodafonemail.de \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).