Re: Steps forward for the LoongArch UEFI bringup patch? (was: Re: [PATCH V14 11/24] LoongArch: Add boot and setup routines)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/3/22 17:32, Xi Ruoyao wrote:
On Thu, 2022-06-02 at 22:09 +0800, WANG Xuerui wrote:

For this, I don't know if Huacai should really just leave those
modification in the downstream fork to keep the upstream Linux clean of
such hacks, because to some degree dealing with such notoriety is life,
it seems to me. I think at this point Huacai would cooperate and tweak
the patch to get rid of the SVAM and other nonstandard bits as much as
possible, and I'll help him where necessary too.
To me any new firmware for PC-like platforms should implement UEFI.  For
embedded platforms device tree support will be added later.

For those guys impossible or unwilling to upgrade the firmware, it may
be possible to implement a compatibility layer and the booting procedure
will be like:

old firmware -> bootloongarch.efi -> customized u-boot -> bootloongarch64.efi (grub) -> efi stub (kernel)
                 --------- compatibility layer --------    ^^^^^^^^ normal UEFI compatible stuff ^^^^^^^^^

new firmware -> bootloongarch64.efi (grub) -> efi stub (kernel)

The old firmware route would be similar to the booting procedure of
Asahi Linux.  I think this can be implemented because it's already
implemented on M1 even while Apple is almost completely uncooperative.

This is a bit off-topic (we're basically hurrying up to get the port into v5.19-rc1 and discussing ways to achieve that), but yeah definitely. I've had the same idea right after knowing the LoongArch firmware would also have "new-world" variant, then I contacted some firmware engineers working on LoongArch boards, I think they agreed on the approach overall.

However, making the kernel itself capable of booting on both BPI and new-world UEFI firmware flavors may have its merits after all; one scenario I could come up with is that user reboots and upgrades their firmware, *before* updating their old-world kernel, and bang! system soft-bricked. All such cases involve old-world distros that already deviate a little bit from vanilla upstream code, so such BPI support needn't be mainlined for avoiding this scenario.


Just my 2 cents. I know almost nothing about booting.
That's fine, we all know nothing in the beginning ;-)



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux