From: Janne Grunau <j@jannau.net>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
u-boot@lists.denx.de, ilias.apalodimas@linaro.org,
sjg@chromium.org, marcan@marcan.st
Subject: Re: RFC: Handling of multiple EFI System Partitions
Date: Mon, 19 Dec 2022 10:48:17 +0100 [thread overview]
Message-ID: <20221219094817.GA4629@jannau.net> (raw)
In-Reply-To: <7FDA0F19-CF1D-4897-A338-DE043E980622@gmx.de>
On 2022-12-18 20:40:20 +0100, Heinrich Schuchardt wrote:
>
>
> Am 18. Dezember 2022 15:21:06 MEZ schrieb Mark Kettenis <mark.kettenis@xs4all.nl>:
> >The Asahi installer, which is what most people use to get their Apple
> >Silicon Mac into a state where it is possible to install another OS on
> >the machine, offers the posibility to create multiple OS installs.
> >For each of these it creates a separate APFS partition (which holds
> >among other things, some essential system firmware) and separate EFI
> >System Partitions. This has a few benefits:
> >
> >* It allows control over which version of the system firmware is used
> > by the OS. This is especially important for things like the GPU and
> > DCP (display controller) firmware, where the firmware interface
> > isn't exactly what we'd call "stable". This way system firmware is
> > paired with the OS install (similar to what macOS does for itself)
> > which prevents breaking other OS installs on the same disk.
> >
> >* It allows us to store a 2nd stage bootloader (m1n1+u-boot+dtb) on
> > the EFI System Partition (ESP) such that it can be easily upgraded
> > from within Linux without affecting other OS installs on the same
> > disk.
> >
> >* It allows the use of the "native" boot picker to switch between
> > OSes.
> >
> >The approach the Asahi team has taken is to pair the APFS partition
> >with the ESP by adding a proprty that contains the partition UUID to
> >the device tree. The installer ships u-boot with a patched distro
> >boot script that looks at this device tree property, figures out what
> >the right ESP is and loads the EFI bootloader
> >(efi/boot/bootaarch64.efi) from that partition.
> >
> >This approach has some drawbacks:
> >
> >1. U-Boot will still consider the first ESP as *the* ESP, which means
> > that the ubootefi.var file is still read from and written from the
> > first ESP.
> >
> >2. The distro boot script modifications don't work if U-Boot's
> > built-in efibootmgr is used. This probably also affects Simon's
> > bootstd stuff.
> >
> >So my idea is to have U-Boot recognize the device tree property and
> >use it when it determines what partition is *the* ESP. A proof of
> >concept diff is attached below. This probably needs a bit of
> >massaging as reading the device tree property in generic EFI code
> >like
> >this is probably not acceptable. A better approach might be to have
> >a
> >function that can be called from board-specific code that sets the
> >UUID.
> >
> >Thoughts? Would such a feature be useful on other hardware
> >platforms?
>
> efi/boot/bootaarch64.efi is only a fallback if load options are not
> set up. Once the operating system has generated a load option it is
> not used anymore.
Setting load options from operation systems is currently not
implemented. The only readily available method to store variables is a
file in the ESP. This obviously can not be supported as UEFI runtime
service while the operation system is using the same disk.
It might be possible to use NOR flash as UEFI variable store. This could
cause issues with the primary boot loader iboot which we can not avoid
or with macOS in dual boot configurations.
> The MacBooks only have one drive. Why would you want two ESPs on one
> drive?
The lack of support for setting boot variable form the operating system
makes it hard to support multiple OS with a single ESP. The systems
comes with an accessible graphical boot picker which should be preferred
over an u-boot based boot manager. Accessibility and the ability to boot
macOS are the most important advantages.
At the current stage an u-boot based boot manager is not a viable option
since the devicetree can not be guaranteed to be backwards compatible.
The most recent breaking change was the addition of a phy phandle
reference for USB controller nodes for USB3 support. Older kernel will
obviously miss a driver for the phy and at least on Linux the USB
controller will not be initialized. This breaks USB completely.
The devicetree is transformed by the loader before u-boot in a
non-trivial way. If u-boot were to use kernel version specific DTB
templates from the ESP it would require a non-trivial amount of code to
update the template by the information added by the loader.
> Why can't the Asahi team use the current UEFI bootflow? We should
> avoid unneeded deviations. Can the current deviations be removed in
> Asahi Linux?
See above, the main reason is the lack of support for setting UEFI
variables at runtime from operating systems. Even if that those were
supported it's impossible to upgrade all installed operating systems
when the devicetree changes in a non backward compatible way due to
additional hardware support.
At the current stage it is not possible to support UEFI bootflow.
Best regards
Janne
next prev parent reply other threads:[~2022-12-19 9:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-18 14:21 RFC: Handling of multiple EFI System Partitions Mark Kettenis
2022-12-18 19:40 ` Heinrich Schuchardt
2022-12-19 9:48 ` Janne Grunau [this message]
2022-12-19 10:52 ` Ilias Apalodimas
2022-12-19 11:18 ` Hector Martin
2022-12-19 14:29 ` Ilias Apalodimas
2022-12-19 10:17 ` Hector Martin
2022-12-19 10:51 ` Mark Kettenis
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=20221219094817.GA4629@jannau.net \
--to=j@jannau.net \
--cc=ilias.apalodimas@linaro.org \
--cc=marcan@marcan.st \
--cc=mark.kettenis@xs4all.nl \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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.
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 NNTP newsgroup(s).