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

[Heinrich Schuchardt]

Am April 27, 2020 8:47:51 PM UTC schrieb Ard Biesheuvel <address@hidden>:
>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?

See:

https://github.com/trini/u-boot/blob/master/lib/efi_loader/efi_load_initrd.c#L80

I hope we are talking about the same protocol.