On 3/15/21 2:07 PM, Ard Biesheuvel wrote:
On Mon, 15 Mar 2021 at 04:11, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote:
On Tue, Mar 09, 2021 at 07:47:25PM +0100, Ard Biesheuvel wrote:
On Tue, 9 Mar 2021 at 19:10, Rob Clark <robdclark@xxxxxxxxx> wrote:
...
fwiw, the valid use-case for ACPI boot on these things is for distro
installer.. it might not be the shiny accelerated experience, but you
want to be able to get thru the installer and then install updates to
get latest kernel/dtb/etc
it is a small use-case, but kinda an important step ;-)
That is a fair point. However, as I understand it, we need this to work around
- the need to pass efi=novamap
- broken poweroff on Flex5g
One more: broken EFI variable runtime services on all Snapdragon laptops
It's been another pain of running debian-installer (d-i) on these
laptops, where EFI NV variables are just stored on UFS disk. So after
Linux takes over the control of UFS, EFI NV variable runtime services
then become out of service. Currently, we have to apply a hack [1] on
d-i grub-installer to get around the issue, and it's been the only
remaining out-of-tree patch we have to carry for d-i. With this nice
`OverrideSupported` support, we will be able to drop that hack
completely.
So an installer either needs to set the EFI variable, or pass
efi=novamap on the first boot. Note that there are no arm64 EFI
systems known where efi=novamap causes problems. In fact, I would
prefer to stop using SetVirtualAddressMap() altogether, as it does not
provide any benefit whatsoever. So perhaps we should make efi=novamap
the default and be done with it.
Broken poweroff is hardly a showstopper for an installer, given that
we cannot even install GRUB correctly.
In summary, I am more than happy to collaborate constructively on this
(which is why I wrote the patch), but I don't think we're at a point
yet where this is the only thing standing in our way when it comes to
a smooth out-of-the-box Linux installation experience.
There might be more to be done for getting a smooth Linux installation
experience. But IMHO, this `OverrideSupported` thing is definitely
a big step to that.
So the problem here seems to be that grub-install (or efibootmgr)
tolerates efivarfs being absent entirely, but bails out if it exists
but gives an error when trying to access it, right?
This is not only a problem on Snapdragon systems afaik - most Uboot
based arm64 systems booting via EFI are affected by this as well.
So it would be good if we could align with those folks, and maybe the
ones working on RISC-V as well, to see if we can get some consensus
around taking this approach.
For the folks newly cc'ed on this thread: full version here
https://lore.kernel.org/linux-arm-msm/20210306113519.294287-1-ardb@xxxxxxxxxx/
Note that I am both the author of the patch, and the maintainer
pushing back on it. Please chime in if you think there are reasons why
we want this, something like this or nothing like this.
Hello Ard,
looking at this thread it is hard to understand why this patch should be
needed.
If an UEFI application does not want to consume a service, it can do so
without having to manipulate the RT properties table.
Which UEFI applications are broken? Why can't they be fixed instead of
patching the kernel?
Can we have complete descriptions of the deficiencies of the involved
applications. I saw GRUB and the Debian installer mentioned in the
thread. Are there others?
Best regards
Heinrich
