Removing DT dependency from LoongArch EFI stub

Removing DT dependency from LoongArch EFI stub

[Ard Biesheuvel]

Hello,

One of the things I didn't quite like was that LoongArch now uses
libfdt only because our EFI stub code depends on it. I would like to
fix this.

I have pushed a branch here that implements this. Unfortunately, it
doesn't proceed beyond

and I need some help debugging the error.

EFI stub: Booting Linux Kernel...
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services ...

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=efi-cleanups-for-v6.1

The idea is to pass the EFI system table pointer and the command line
pointer directly. In previous patches, the initrd and memmap code is
updated so it exposes the information via configuration tables that
the generic code can parse.

Any help is greatly appreciated.

Thanks,
Ard.

Re: Removing DT dependency from LoongArch EFI stub

[Huacai Chen]

Hi, Ard,

On Sat, Sep 17, 2022 at 2:37 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> Hello,
>
> One of the things I didn't quite like was that LoongArch now uses
> libfdt only because our EFI stub code depends on it. I would like to
> fix this.
>
> I have pushed a branch here that implements this. Unfortunately, it
> doesn't proceed beyond
>
> and I need some help debugging the error.
>
> EFI stub: Booting Linux Kernel...
> EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
> EFI stub: Exiting boot services ...
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=efi-cleanups-for-v6.1
>
> The idea is to pass the EFI system table pointer and the command line
> pointer directly. In previous patches, the initrd and memmap code is
> updated so it exposes the information via configuration tables that
> the generic code can parse.
>
> Any help is greatly appreciated.
I'm sorry but I suggest keeping the current light FDT approach. Of
course the upstream LoongArch kernel uses UEFI+ACPI, but it only
supports high-end systems (Loongson-3A/3C CPU with LS7A chipset). In
fact, low-end systems (Loongson-2K CPU in SoC) support is already on
the way and target for 6.2, which uses FDT in order to share a number
of existing drivers. Using the current approach can share lots of boot
code for both high-end and low-end systems, and doesn't break boot
again.

Thanks,
Huacai

>
> Thanks,
> Ard.

Re: Removing DT dependency from LoongArch EFI stub

[Ard Biesheuvel]

On Sat, 17 Sept 2022 at 09:59, Huacai Chen <chenhuacai@kernel.org> wrote:
>
> Hi, Ard,
>
> On Sat, Sep 17, 2022 at 2:37 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Hello,
> >
> > One of the things I didn't quite like was that LoongArch now uses
> > libfdt only because our EFI stub code depends on it. I would like to
> > fix this.
> >
> > I have pushed a branch here that implements this. Unfortunately, it
> > doesn't proceed beyond
> >
> > and I need some help debugging the error.
> >
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
> > EFI stub: Exiting boot services ...
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=efi-cleanups-for-v6.1
> >
> > The idea is to pass the EFI system table pointer and the command line
> > pointer directly. In previous patches, the initrd and memmap code is
> > updated so it exposes the information via configuration tables that
> > the generic code can parse.
> >
> > Any help is greatly appreciated.
> I'm sorry but I suggest keeping the current light FDT approach. Of
> course the upstream LoongArch kernel uses UEFI+ACPI, but it only
> supports high-end systems (Loongson-3A/3C CPU with LS7A chipset). In
> fact, low-end systems (Loongson-2K CPU in SoC) support is already on
> the way and target for 6.2, which uses FDT in order to share a number
> of existing drivers. Using the current approach can share lots of boot
> code for both high-end and low-end systems, and doesn't break boot
> again.
>

Ah fair enough. I didn't realize you were planning on using FDT as a
platform description.

I may still propose some enhancements that clean up the way we use FDT
in the EFI stub, but omitting it entirely is not going to be a
priority then.

Thanks,
Ard.