RFC: Handling of multiple EFI System Partitions

[Ilias Apalodimas]

Hi Janne, 

[...]

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

Yes, but I'd skip the 'currently not implemented' part.  If you store your EFI
variables in a file on the ESP, we will *never* be able to (sanely) support SetVariable
at runtime. 

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

It is possible.  In fact we already have code in U-Boot that stores the EFI
variables in an RPMB partition of the eMMC.  We also have (unfortunately
not yet upstreamed) code that stores the in an i2c eeprom in the secure
world. 

This is again situational though and none of these applies to MBPs.
SetVariable at runtime in an RPMB comes with it's own set of problems.
You basically need to replace the runtime services with OS provided ones...
The I2C one works fine.

But letting the implementation details aside, what we need to keep in mind,
is that being able to support SetVariable-RT primarily depends on the *hardware*
and there's gonna be hardware we'll never be able to support this. 

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

Ok fair enough,  I'll talk to Heinrich and see if The current idea from
Mark can be wired up without causing too much of a mess.

> At the current stage it is not possible to support UEFI bootflow.
> 
> Best regards
> 
> Janne


Cheers
/Ilias