From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jTBxh-00079H-AB for mharc-grub-devel@gnu.org; Mon, 27 Apr 2020 18:10:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37996) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jTBxe-00077M-M5 for grub-devel@gnu.org; Mon, 27 Apr 2020 18:10:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jTBxd-00036u-Vr for grub-devel@gnu.org; Mon, 27 Apr 2020 18:10:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:37380) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jTBxd-00036j-Ei for grub-devel@gnu.org; Mon, 27 Apr 2020 18:10:45 -0400 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A8C5020575 for ; Mon, 27 Apr 2020 22:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588025443; bh=2j7CYL/3C/ZTHFUa+Gwtedw0Jyqw1qBEKg5YzXn4eH8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vHntsU6LXE5BretdP00xWUfSKFuNUExJnKejVKbKjdycCnAT+iXAGu66b1CQHcqha jmxlkei01jey7ldOve3v2sgDSSKG7V9B6j8/CEH3TgAo6qBjub4aro2T/OLJZbwxaA sk4VXXUg2a6CcrBCC1Q1WYhn/LUG2H8QRjrbwXYw= Received: by mail-io1-f48.google.com with SMTP id b12so20654992ion.8 for ; Mon, 27 Apr 2020 15:10:43 -0700 (PDT) X-Gm-Message-State: AGi0PuaqrmJVjelKrnjv1crHlE1q3pQY+Lc0JwGbeVm6IdHqQ9c604Di v9QC7C0a4ep+iQvMO1zxchWMKyps8osR5Pk1Efw= X-Google-Smtp-Source: APiQypJ0JdS+ZUH1ZFJ882k7gcxfRDsieTVTGYu4Bw0vr/z4M68zpwOSynqI0ZZNtBuGgc549bBjvVhcNs/4yspyMOs= X-Received: by 2002:a02:3341:: with SMTP id k1mr23203289jak.74.1588025443108; Mon, 27 Apr 2020 15:10:43 -0700 (PDT) MIME-Version: 1.0 References: <20200426194007.382925-1-atish.patra@wdc.com> <20200427110106.r2jqkaeheiw3lunl@tomti.i.net-space.pl> <68c6f6a8-6c13-f2f4-f2ca-287c3f5330f4@gmx.de> <0C4E5FD2-6DE1-4A42-84E1-2202F62E04A5@gmx.de> <28180641-DF47-48A2-A675-1351B83FA073@gmx.de> <4A85F54A-DF7D-4178-9407-4A97E7529A9E@gmx.de> In-Reply-To: <4A85F54A-DF7D-4178-9407-4A97E7529A9E@gmx.de> From: Ard Biesheuvel Date: Tue, 28 Apr 2020 00:10:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux To: Heinrich Schuchardt Cc: Daniel Kiper , Atish Patra , grub-devel@gnu.org, David Abdurachmanov , Leif Lindholm , Alexander Graf , Chester Lin , Ilias Apalodimas Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=198.145.29.99; envelope-from=ardb@kernel.org; helo=mail.kernel.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/27 15:11:06 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Received-From: 198.145.29.99 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 22:10:47 -0000 On Mon, 27 Apr 2020 at 23:16, Heinrich Schuchardt wrote: > > Am April 27, 2020 8:58:57 PM UTC schrieb Heinrich Schuchardt : > >Am April 27, 2020 8:52:43 PM UTC schrieb Ard Biesheuvel > >: > >>On Mon, 27 Apr 2020 at 22:47, Ard Biesheuvel wrote: > >>> > >>> On Mon, 27 Apr 2020 at 22:47, Heinrich Schuchardt > >> wrote: > >>> > > >>> > Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel > >>: > >>> > >On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt > >> > >>> > >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 > >> > >>> > >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.