Am April 27, 2020 8:47:51 PM UTC schrieb Ard Biesheuvel <a...@kernel.org>: >On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt <xypron.g...@gmx.de> >wrote: >> >> Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel ><a...@kernel.org>: >> >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt ><xypron.g...@gmx.de> >> >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 <atish.pa...@wdc.com> >> >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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
