Date:   Thu, 2 Jun 2022 22:09:32 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     Ard Biesheuvel <ardb@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>
Cc:     linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Huacai Chen <chenhuacai@...il.com>,
        Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-efi@...r.kernel.org, WANG Xuerui <git@...0n.name>,
        Yun Liu <liuyun@...ngson.cn>, Jonathan Corbet <corbet@....net>,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Airlie <airlied@...ux.ie>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Steps forward for the LoongArch UEFI bringup patch? (was: Re: [PATCH
 V14 11/24] LoongArch: Add boot and setup routines)

Hi Ard,

Sorry for sounding particularly rushed and I really don't like rushing 
things either, but as explained in the previous reply [1], what we want 
to do is mainly to get the arch/loongarch into mainline first, 
stabilizing an ABI surface already under heavy testing for many months; 
plus Huacai has removed the questioned kernel version string, and the 
Loongson-specific "boardinfo" sysfs file that doesn't really belong to 
/sys/firmware/efi.

So, would you please clarify and explain how Huacai and I could best 
proceed to hopefully get the *rest* of the port readied for a (late) 
merge window PR? Otherwise much of userspace development would have to 
shift target once more, and many Linux distros would have to carry and 
rebase this big patchset for another 2 months which is real churn.

If some more background is necessary, let me explain a bit more about 
the LoongArch boot protocol peculiarities...

For one thing, the standard EFI stub boot flow is a recent development, 
and has not shipped yet; all currently existing LoongArch systems 
actually implement the previous Loongson-specific boot protocol based on 
"struct bootparamsinterface", or BPI for short, that was carried over 
from the MIPS era. Systems with BPI firmware provide full EFI services 
too, but all pointers in BPI structs are virtual addresses, and the 
memory maps are not provided in the same way as their new firmware. In 
addition to that, all BPI systems launch Linux via a special GRUB2 that 
can only boot ELF files (so cannot chainload an EFI stub), and it's 
unclear whether directly booting an EFI stub would work, so the EFI stub 
logic is not invoked at all but SVAM still have to be executed somehow 
to ensure sanity. All of this means the SVAM oddity will eventually get 
in, regardless of whether we take it out now or not, if the BPI support 
is to be mainlined in the future.

For another thing, it seems Loongson really wanted to support the "PMON" 
use case that wouldn't provide full EFI services but sharing some logic 
with UEFI boot. PMON is one of the MIPS firmware varieties that Loongson 
has supported back in the days, and they seem to have ported it to 
LoongArch as well.

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.


[1]: 
https://lore.kernel.org/all/47b559c0-b1e8-e800-0491-2431e2083dad@xen0n.name/

Powered by blists - more mailing lists