Hi, Ard, On Wed, Mar 2, 2022 at 4:58 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Wed, 2 Mar 2022 at 09:56, Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > > > Hi, Arnd & Ard, > > > > On Tue, Mar 1, 2022 at 6:19 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > > > 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. > > Hmm, I thought that new UEFI SPEC is a requirement of efistub, maybe I'm wrong? > > > > > > > > > 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? > > Things become simple if we only consider efistub rather than raw elf. > > But there are still some problems: > > 1, We want the first patch series as minimal as possible, efistub > > support will add a lot of code. > > 2, EFISTUB hides the interface between bootloader and raw kernel, but > > the interface does actually exist (efistub itself is also a > > bootloader, though it binds with the raw kernel). In the current > > implementation (a0=argc a1=argv a2=bootparaminterface), we should > > select EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER which is marked as > > deprecated. Is this acceptable? If not, we still need to change the > > bootloader-kernel interface, maybe use the method in my previous > > email? > > Why do you need this? Because in the current implementation (a0=argc a1=argv a2=bootparaminterface), initrd should be passed by cmdline (initrd=xxxx). If without that option, efi_load_initrd_cmdline() will not call handle_cmdline_files(). Huacai > > > 3, I know things without upstream means "nothing" for the community, > > but if we can provide raw elf kernel support to be compatible with > > existing products (not just a working draft, they are widely used > > now), it also seems reasonable. > > > > Huacai > > > > > > > > Arnd
