all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: Stefan <stefan-guix@vodafonemail.de>,
	Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org
Subject: Re: Supporting *multiple* bootloaders for arm64 on a single install?
Date: Sat, 19 Jun 2021 14:03:50 -0700	[thread overview]
Message-ID: <87v969lg7d.fsf@yucca> (raw)
In-Reply-To: <6577B35F-1261-4EFF-81E4-E531A3FD6930@vodafonemail.de>

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

On 2021-06-19, Stefan wrote:
>>> 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.
...
>> 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.
...
>> 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.
>
> Referring to the patch #48314, the efi-bootloader-chain got
> simplified. It basically prepares a profile with all files to be
> copied as is, no special “collection” folder any more. And the
> installer of the grub-efi-netboot-(removable-)bootloader is now merely
> a simple “(copy-recursively bootloader-profile)“ procedure.

>>> 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...
...
> I believe that the ARM future is UEFI, like on PCs. A lot of
> distributions already chainload U-Boot and GRUB an arm systems. There
> is a specification for ARM servers which demands UEFI¹. And there is
> even the choice between U-Boot and TianoCore/EDK II.

Yes, standardizing on UEFI in general would be a good thing, especially
because u-boot can increasingly fill that role for boards that don't
have a tianocore/edkII implementation.

My heart is more with u-boot, but i also value standardization. :)


> I think meanwhile that it would be beneficial, if, beside a bootloader
> field, Guix would accept an optional firmware field. Then the U-Boot
> or TianoCore/EDK II (or coreboot) could become some board specific
> firmware, and the actual bootloader would be grub-efi installed on an
> EFI System Partition. For systems like the Raspberry, which require
> their firmware on a FAT partition, there is the already working
> efi-bootloader-chain solution.

Yeah, I like that idea! Das U-boot functionally is both kind of boot
firmware as well as a bootloader rolled into one; I could see treating
it more as a firmware which may not actually even need a separate
bootloader (other than maybe generating a boot script or extlinux.conf),
or a firmware implments EFI (and thus can load grub-efi).


> The firmware could only be installed on explicit request. It's not
> expected to see frequent changes – every re-installation is a risk to
> brick the system. (For my taste the bootloader is re-installed too
> often already.)

Mixed feelings on that; it puts you in the situation of not knowing when
the current guix bootloader/firmware is broken if you don't reinstall it
(although maybe it could be made smarter and only reinstall
bootloader/firmware when it actually changes).

It's already possible to pass an empty bootloader that just generates
the configuration files for grub or extlinux which doesn't re-install(to
my knowledge). Extending that to the proposed firmware idea would make
some sense...


live well,
  vagrant

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

  reply	other threads:[~2021-06-19 21:04 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
2021-06-19 15:11   ` Stefan
2021-06-19 21:03     ` Vagrant Cascadian [this message]
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

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

  git send-email \
    --in-reply-to=87v969lg7d.fsf@yucca \
    --to=vagrant@debian.org \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    --cc=stefan-guix@vodafonemail.de \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.