On Tue, Jul 27, 2021 at 1:53 PM Huacai Chen <chenhuacai@xxxxxxxxx> wrote:
> On Tue, Jul 6, 2021 at 6:16 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Tue, Jul 6, 2021 at 6:18 AM Huacai Chen <chenhuacai@xxxxxxxxxxx> wrote:
> >
> > > +
> > > +#ifdef CONFIG_64BIT
> > > + /* Guess if the sign extension was forgotten by bootloader */
> > > + if (start < CAC_BASE)
> > > + start = (int)start;
> > > +#endif
> > > + initrd_start = start;
> > > + initrd_end += start;
> > > + return 0;
> > > +}
> > > +early_param("rd_start", rd_start_early);
> > > +
> > > +static int __init rd_size_early(char *p)
> > > +{
> > > + initrd_end += memparse(p, &p);
> > > + return 0;
> > > +}
> > > +early_param("rd_size", rd_size_early);
> >
> > The early parameters should not be used for this, I'm fairly sure the UEFI
> > boot protocol already has ways to communicate all necessary information.
> We use grub to boot the Linux kernel. We found X86 uses private data
> structures (seems not UEFI-specific) to pass initrd information from
> grub to kernel. Some archs use fdt, and other archs use cmdline with
> "initrd=start,size" (init/do_mounts_initrd.c). So, I think use cmdline
> is not unacceptable, but we do can remove the the rd_start/rd_size
> parsing code here
(adding Ard Biesheuvel to Cc for clarification)
As far as I understand it, this should be using the kernel's UEFI stub
as documented in Documentation/admin-guide/efi-stub.rst
This lets you load the initrd from within the kernel and pass the
address using the architecture specific boot information.
Maybe I misunderstood and you already do it like this?
Arnd
