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