Hi, Ard & Arnd, On Wed, Mar 2, 2022 at 5:20 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > 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(). It seems I'm wrong. EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER controls "initrd=xxxx" from BIOS to EFISTUB, but has nothing to do with a0/a1/a2 usage (which controls the "initrd=xxxx" from efistub to raw kernel). The real reason is our UEFI BIOS has an old codebase without LoadFile2 support. Then, my new questions are: 1, Is EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER an unacceptable option for a new Arch? If yes, we should backport LoadFile2 support to our BIOS. 2, We now all agree that EFISTUB is the standard and maybe the only way in future. But, can we do the efistub work in the second series, in order to make the first series as minimal as possible? (I will update the commit message to make it clear that a0/a1/a2 usage is only an internal interface between efistub and raw kernel). Huacai > > 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
