Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux

[Ard Biesheuvel]

On Mon, 27 Apr 2020 at 23:16, Heinrich Schuchardt <address@hidden> wrote:
>
> Am April 27, 2020 8:58:57 PM UTC schrieb Heinrich Schuchardt <address@hidden>:
> >Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel
> ><address@hidden>:
> >>On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel <address@hidden> wrote:
> >>>
> >>> On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt
> >><address@hidden> wrote:
> >>> >
> >>> > Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel
> >><address@hidden>:
> >>> > >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt
> >><address@hidden>
> >>> > >wrote:
> >>> > >>
> >>> > >> On 4/27/20 1:01 PM, Daniel Kiper wrote:
> >>> > >> > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel
> >>wrote:
> >>> > >> >> On Sun, 26 Apr 2020 at 21:40, Atish Patra
> >><address@hidden>
> >>> > >wrote:
> >>> > >> >>>
> >>> > >> >>> This series adds grub loader support for RISC-V Linux.
> >>Thanks to
> >>> > >the awesome
> >>> > >> >>> initial RISC-V support added by Alex, we just needed a
> >>loader for
> >>> > >RISC-V to
> >>> > >> >>> load and execute Linux using UEFI protocol.
> >>> > >> >>>
> >>> > >> >>> Fortunately, ARM64 Linux loader is written in an
> >>architecture
> >>> > >agnostic manner
> >>> > >> >>> so thatgeneric RISC-V can easily reuse the loader code.
> >>Thus, the
> >>> > >first patch
> >>> > >> >>> just moves the ARM64 code to common code. I have compile
> >>tested
> >>> > >for
> >>> > >> >>> ARM64/ARM32. Even though it doesn't introduce any
> >functional
> >>> > >change
> >>> > >> >>> for ARM/ARM64, any real testing will be helpful.
> >>> > >> >>
> >>> > >> >> May I suggest that we not blindly adopt the ARM code here,
> >>but
> >>> > >> >> instead, use the new initrd loading protocol that removes
> >the
> >>need
> >>> > >for
> >>> > >> >> GRUB to modify or even know about the device tree at all?
> >>> > >>
> >>> > >> Does this protocol exist in EDK2 by now?
> >>> > >>
> >>> > >
> >>> > >Yes. It exists as a shell command, and as a load option for OVMF.
> >>> > >
> >>> > >> In U-Boot there is a basic implementation which can provide a
> >>single
> >>> > >> initrd image with a hardcoded file name. The file_path argument
> >>> > >passed
> >>> > >> to U-Boot is ignored due to Ilias' security concerns when he
> >>wrote
> >>> > >the
> >>> > >> patch.
> >>> > >>
> >>> > >> GRUB is only needed if we have multiple kernels to choose from
> >>with
> >>> > >> distinct initial ramdisks.
> >>> > >>
> >>> > >> Please, describe what you expect the initrd loading protocol to
> >>do
> >>> > >when
> >>> > >> called from GRUB. How will the ramdisk fitting the kernel
> >chosen
> >>in
> >>> > >GRUB
> >>> > >> be identified?
> >>> > >>
> >>> > >
> >>> > >The same what GRUB's 'initrd' command does. Whichever initrd you
> >>> > >select with it is the one that gets returned by the protocol.
> >>> >
> >>> > Will GRUB provide the absolute device path in parameter file_path?
> >>> >
> >>>
> >>> Which parameter 'file_path" is that?
> >>
> >>Ah, I guess you mean the LoadFile2 argument? That is always
> >>end-of-device-path in this case, since the initrd device path only
> >>consists of the vendor media GUID.
> >>
> >>The thing to keep in mind here is that the OS does not *choose* an
> >>initrd, it simply loads the one that the bootloader has staged for it.
> >
> >How should U-Boot know which initrd fits the kernel chosen by the user
> >in GRUB? That information exists in grub.cfg only.
> >
> >If GRUB cannot provide this information, what is GRUB's added value in
> >the boot process?
>
> Hello Ard,
>
> Did I misunderstand you and you want to provide a LOAD_FILE2 implementation 
> in GRUB and not use the one in the firmware?
>

Yes. If you use GRUB, it is provided by GRUB. Otherwise, it can be
provided by U-Boot or EDK2.