On Tue, 27 Jul 2021 at 15:14, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Tue, Jul 27, 2021 at 2:51 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Tue, 27 Jul 2021 at 14:41, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > > On Tue, Jul 27, 2021 at 1:53 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> > >
> > > As far as I understand it, this should be using the kernel's UEFI stub
> > > as documented in Documentation/admin-guide/efi-stub.rst
> > >
> >
> > That document describes how the EFI stub can load an initrd from the
> > partition that the kernel image itself was loaded from.
> >
> > After loading it, the EFI stub still needs to tell the kernel proper
> > where the initrd lives in memory, and it uses either struct bootparam
> > (x86) or DT's /chosen node (other arches) for this.
> >
> > I think we should avoid inventing yet another way of passing this
> > information, but if the architecture in question does not use DT (and
> > is != x86), I don't think we have a choice.
>
> Ok, I see.
>
> Would the existing early_param("initrd", early_initrd); in
> init/do_mounts_initrd.c work for this then? This would be
> similar to the proposed rd_start()/rd_size() early_parem
> additions, but use architecture-independent code.
>
Yes, I think that should be fine. The reason we use the /chosen node
for DT architectures is simply because that is how the command line
itself gets passed as well, and DT nodes are more structured than the
command line. Otherwise, initrd= should be perfectly suitable for DT
platforms as well, modulo the syntax clash between the stub's initrd=
and the kernel's initrd=
> How is other information passed from grub to the efi stub
> and from there to the kernel on loongarch?
I don't think this architecture boots via EFI at all - it looks like a
data structure is created in memory that looks like an EFI system
table, and provided to the kernel proper without going through the
stub. This is not surprising, given that the stub turns the kernel
into a PE/COFF executable, and the PE/COFF spec nor the EFI spec
support the LoongSon architecture.
This is problematic from a maintenance point of view, given that the
interface between the kernel proper and the EFI stub is being promoted
from an internal interface that we can freely modify to one that needs
to remain stable for compatibility of new kernels with older firmware.
I don't think we should be going down this path tbh.
> I suppose at the minimum we need memory regions, ACPI
> tables, and command line, in addition to the initrd.
>
> Arnd
