On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel <a...@kernel.org> wrote: > > 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?
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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
