Hi, Ard & Arnd, 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: > > > On Mon, Feb 28, 2022 at 4:52 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Mon, 28 Feb 2022 at 09:38, Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > > > > > > > > > > > RISC-V is a useful reference for the changes needed - this is the most > > > > > > recent addition to the EFI stub, and avoids some legacy stuff that new > > > > > > architectures have no need for. > > > > > We still want to support the raw elf kernel (RISC-V also does), > > > > > because LoongArch also has MCU and SoC and we want to support FDT (I > > > > > think this is reasonable, because RISC-V also supports raw elf). > > > > > > > > > > > > > That is fine. So perhaps the best course of action is to omit the > > > > UEFI/ACPI parts entirely for now, and focus on the DT/embedded use > > > > case. Once all the spec pieces are in place, the UEFI + ACPI changes > > > > can be presented as a single coherent set. > > > It seems that I made you confusing. :) > > > There are big CPUs and small CPUs (MCU and SoC), big CPUs use > > > UEFI+ACPI, while small CPUs use FDT. > > > At present, the only matured LoongArch CPU is Loongson-3A5000 (big > > > CPU) which uses UEFI+ACPI. > > > We want to support raw elf because it can run on both ACPI firmware > > > and FDT firmware, but at present we only have ACPI firmware. > > > > 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. 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) Huacai
