On Sat, Mar 19, 2022 at 3:38 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > This patch adds basic boot, setup and reset routines for LoongArch. > LoongArch uses UEFI-based firmware. The firmware uses ACPI and DMI/ > SMBIOS to pass configuration information to the Linux kernel. > > Now the boot information passed to kernel is like this: > 1, kernel get 3 register values (a0, a1 and a2) from bootloader. > 2, a0 is "argc", a1 is "argv", so "kernel cmdline" comes from a0/a1. > 3, a2 is "environ", which is a pointer to the "struct boot_params". > 4, "struct boot_params" include a "systemtable" pointer, whose type is > "efi_system_table_t". Most configuration information, include ACPI > tables and SMBIOS tables, come from here. > > The above interface is an internal interface between bootloader (grub, > efistub, etc.) and the raw kernel. You can use this method to boot the > Linux kernel in raw elf format, but it is recommend to use the standard > UEFI boot protocol when efistub is added later. > > ECR for adding LoongArch support in ACPI: > https://mantis.uefi.org/mantis/view.php?id=2203 > > ECR for adding LoongArch support in ACPI (version update): > https://mantis.uefi.org/mantis/view.php?id=2268 > > ECR for adding LoongArch support in UEFI: > https://mantis.uefi.org/mantis/view.php?id=2313 > > ACPI changes of LoongArch have been approved in the last year, but the > new version of ACPI SPEC hasn't been made public yet. And UEFI changes > of LoongArch are under review now. > > Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> > Cc: linux-efi@xxxxxxxxxxxxxxx > Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx> I think this is still the most controversial bit of the series, and my feeling is that it would be better to have the UEFI stub bits in place first, so the custom entry point can be avoided completely. Unfortunately I don't have access to mantis.uefi.org, can you explain what the current status is? Are there still ABI relevant decisions that need to be made about the UEFI entry point? If the timing works out, the best approach may be to instead send a draft version of the UEFI wrapper based boot implementation for review now, so it can be merged once the standard has found consensus. Having the code openly accessible should also help with speed up the review. Arnd
