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

[Heinrich Schuchardt]

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?