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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux