On Fri, 3 Jun 2022 at 12:37, WANG Xuerui <kernel@xxxxxxxxxx> wrote: > > On 6/3/22 18:02, Arnd Bergmann wrote: > > On Fri, Jun 3, 2022 at 11:27 AM WANG Xuerui <kernel@xxxxxxxxxx> wrote: > >> On 6/3/22 15:20, Huacai Chen wrote: > >>> Add basic boot, setup and reset routines for LoongArch. Now, LoongArch > >>> machines use UEFI-based firmware. The firmware passes configuration > >>> information to the kernel via ACPI and DMI/SMBIOS. > >>> > >>> Currently an existing interface between the kernel and the bootloader > >>> is implemented. Kernel gets 2 values from the bootloader, passed in > >>> registers a0 and a1; a0 is an "EFI boot flag" distinguishing UEFI and > >>> non-UEFI firmware, while a1 is a pointer to an FDT with systable, > >>> memmap, cmdline and initrd information. > >>> > >>> The standard UEFI boot protocol (EFISTUB) will be added later. > >>> > >>> Cc: linux-efi@xxxxxxxxxxxxxxx > >>> Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> > >>> Reviewed-by: WANG Xuerui <git@xxxxxxxxxx> > >>> Reviewed-by: Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> > >>> Co-developed-by: Yun Liu <liuyun@xxxxxxxxxxx> > >>> Signed-off-by: Yun Liu <liuyun@xxxxxxxxxxx> > >>> Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx> > >> Would you please look at this patch, which has all the arch-independent > >> changes backed out, and Ack if it is fit for mainlining? > >> > >> I communicated a little with Huacai about the approach for supporting > >> alternative boot protocols down the road, and we agreed to carry the > >> respective changes downstream. And if needs truly arise for modifying > >> common EFI logic, we can do so in a non-rushed manner later. > >> > >> For the current status of the code, apparently it just accepts the > >> standard efistub-shape FDT pointer from (whatever booting the image), > >> and everything onwards are fully using the common code without > >> modification as you can see from the diffstat. I rebased my BPI support > >> patch on top of this (basically translating Loongson BPI data structures > >> into the expected FDT form), and can confirm the boot can progress to > >> the same point as before -- indeed the SVAM changes etc. are not > >> necessary for a working system, and the code remains working. > > I'm a bit lost here: Does this mean the v15 version is back to the old > > pre-efistub interface and allows booting with existing firmware, or > > is it now left out completely? I still see a kernel_entry() function > > in head.S, and I see references to loongson_sysconf, but I don't > > see if that is what gets passed in from the bootloader. > It's not the same interface as in some of the very early revisions; the > earlier versions relied on "struct bootparamsinterface" or BPI, while > it's the same FDT-based interface to initialize EFI from, as in > arch/arm64 and arch/riscv I believe. No Loongson-specific things remain now. OK, excellent. > > > > I really want to make sure that without the EFI stub, there is no > > other way to boot the kernel that would have to get maintained > > in the long run. > Yeah this is the case right now. No LoongArch bootloader that I know of > can prepare the EFI stub-shaped FDT that the current code expects, and I > don't know of any future Loongson plan to do that either (Loongson's > previous in-house efforts all looked something different). So it's > pretty safe to say the current code wouldn't get frozen once mainlined. The use of DT is part of the internal stub <-> kernel ABI, and if LoongArch does not make use of DT otherwise, I could well imagine changing this down the road. I'll send out some RFC patches for review after the merge window closes.
