On Mon, Apr 27, 2020 at 3:11 PM Ard Biesheuvel <a...@kernel.org> wrote: > > On Mon, 27 Apr 2020 at 23:16, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > Am April 27, 2020 8:58:57 PM UTC schrieb Heinrich Schuchardt > > <xypron.g...@gmx.de>: > > >Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel > > ><a...@kernel.org>: > > >>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. > > > > > >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? > > > > Yes. If you use GRUB, it is provided by GRUB. Otherwise, it can be > provided by U-Boot or EDK2. >
Thanks for the discussion. I got clarification as well. I will work on adding LOAD_FILE2 support in GRUB. > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards, Atish _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
