Re: [PATCH V6 09/22] LoongArch: Add boot and setup routines

[Arnd Bergmann]

On Tue, Mar 1, 2022 at 5:17 AM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> On Mon, Feb 28, 2022 at 7:35 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Mon, 28 Feb 2022 at 12:24, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > On Mon, Feb 28, 2022 at 11:42 AM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> > > Can't you just use the UEFI protocol for kernel entry regardless
> > > of the bootloader? It seems odd to use a different protocol for loading
> > > grub and the kernel, especially if that means you end up having to
> > > support both protocols inside of u-boot and grub, in order to chain-load
> > > a uefi application like grub.
> > >
> >
> > I think this would make sense. Now that the EFI stub has generic
> > support for loading the initrd via a UEFI specific protocol (of which
> > u-boot already carries an implementation), booting via UEFI only would
> > mean that no Linux boot protocol would need to be defined outside of
> > the kernel at all (i.e., where to load the kernel, where to put the
> > command line, where to put the initrd, other arch specific rules etc
> > etc) UEFI already supports both ACPI and DT boot
>
> After one night thinking, I agree with Ard that we can use RISCV-style
> fdt to support the raw elf kernel at present, and add efistub support
> after new UEFI SPEC released.

I think that is the opposite of what Ard and I discussed above.

> If I'm right, it seems that RISC-V passes a0 (hartid) and a1 (fdt
> pointer, which contains cmdline, initrd, etc.) to the raw elf kernel.
> And in my opinion, the main drawback of current LoongArch method
> (a0=argc a1=argv a2=bootparamsinterface pointer) is it uses a
> non-standard method to pass kernel args and initrd. So, can the below
> new solution be acceptable?
>
> a0=bootparamsinterface pointer (the same as a2 in current method)
> a1=fdt pointer (contains cmdline, initrd, etc., like RISC-V, I think
> this is the standard method)

It would seem more logical to me to keep those details as part of the
interface between the EFI stub and the kernel, rather than the
documented boot interface.

You said that there is already grub support using the UEFI
loader, so I assume you have a working draft of the boot
protocol. Are there still open questions about the interface
definition for that preventing you from using it as the only
way to enter the kernel from a bootloader?

        Arnd