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

[Heinrich Schuchardt]

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?

Regards

Heinrich