From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2726C4338F for ; Mon, 23 Aug 2021 17:26:36 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0AB0760F45 for ; Mon, 23 Aug 2021 17:26:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0AB0760F45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 03B3582BE5; Mon, 23 Aug 2021 19:26:15 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="kcBXUYit"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4B20880837; Mon, 23 Aug 2021 19:26:05 +0200 (CEST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5E89C8033E for ; Mon, 23 Aug 2021 19:25:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-wr1-x42c.google.com with SMTP id d26so6993638wrc.0 for ; Mon, 23 Aug 2021 10:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6BcGXSA3t6Ig8tdsZyHLmWve8fG/234mscHv8ai3jpU=; b=kcBXUYitQRgYqsYr6fJWML06wPpZAOtZJUtCMneFsPkGDmf5RIrHZZzy8YAnU3D+U+ Ps0iY4A+A/CL8giOgyQGtQhG9FtmgmvAodZ8PqZPNhdBXvmo/nRUygm1Ax/H1AkJfeBr sZEKuJ0hN7owXFNMtJnIq1jJZFu68JQvFKMQk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6BcGXSA3t6Ig8tdsZyHLmWve8fG/234mscHv8ai3jpU=; b=re5yjJfuUkHrpeLd8TF1cPs3AyS2ncEW8ASljv69Gt8XDzmSxKg8E2lM965qLVMNhe nR9hDunGmSOdXPtTUJufB4gCJgFXqeojy1FeOqC2z6OgBaIfL6gIrN+c3RfsZqBQijwY XBPUAMw6+HhbLwxqjfGdbZus6pbySyP6XW98l6bRn59+lRKcHkGCx2RDhBta51grV3Xa bwlwGtRygw9mp/YUTqObp8ueDv4D6wueMrw9axDWCB6pdLGUEdXZLlro9Qqj6bpUU2kK MOGFcUvzLG428aNWid7okdMuU/pOvSPd0ytGo82pmyCBJPRHMBs/Dq17jKS+jsQhYiTL nKew== X-Gm-Message-State: AOAM532EETWvHdU/+0QS1QNLeoaWSrDMwrzbYbEp+2rmMmkCjk0JN3Ea FfP7tzh3bDFSuRBSMJpqJHzG9wmpVN4ilKMX2pl/fg== X-Google-Smtp-Source: ABdhPJzkZOJktyba/iNPTQnfBtPSkkh8VWzM1iTXTJdYxxzMA+p0NQ5hGJ1YJXHwFVOwuErw/wzd7vRMOmgILJ8X5UQ= X-Received: by 2002:adf:eb89:: with SMTP id t9mr15402789wrn.66.1629739552536; Mon, 23 Aug 2021 10:25:52 -0700 (PDT) MIME-Version: 1.0 References: <20210819034601.1618773-1-sjg@chromium.org> <20210819135944.GX858@bill-the-cat> <20210819172750.GB858@bill-the-cat> In-Reply-To: From: Simon Glass Date: Mon, 23 Aug 2021 11:25:40 -0600 Message-ID: Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow To: Ilias Apalodimas Cc: Tom Rini , U-Boot Mailing List , Steffen Jaeckel , Michal Simek , Dennis Gilmore , Daniel Schwierzeck , Lukas Auer , Jaehoon Chung , Matthias Brugger , Peng Fan , Stephen Warren , Stephen Warren Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hi Ilias, On Mon, 23 Aug 2021 at 06:35, Ilias Apalodimas wrote: > > On Thu, Aug 19, 2021 at 01:27:50PM -0400, Tom Rini wrote: > > On Thu, Aug 19, 2021 at 08:25:33AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 19 Aug 2021 at 07:59, Tom Rini wrote: > > > > > > > > On Wed, Aug 18, 2021 at 09:45:33PM -0600, Simon Glass wrote: > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to automatically boot > > > > > an Operating System without custom scripting and other customisation: > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows (owned by U-Boot) > > > > > - bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > This series provides an initial implementation of these, enable to scan > > > > > for bootflows from MMC and Ethernet. The only bootflow supported is > > > > > distro boot, i.e. an extlinux.conf file included on a filesystem or > > > > > tftp server. It works similiarly to the existing script-based approach, > > > > > but is native to U-Boot. > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > bootflow scan -lb > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to boot each > > > > > one (-b). The final patch shows this. > > > > > > > > > > It is intended that this approach be expanded to support mechanisms other > > > > > than distro boot, including EFI-related ones. With a standard way to > > > > > identify boot devices, these features become easier. It also should > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > The first patch of this series moves boot-related code out of common/ and > > > > > into a new boot/ directory. This helps to collect these related files > > > > > in one place, as common/ is quite large. > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE implementation. > > > > > Much of this series consists of cleaning up that code and refactoring it > > > > > into something closer to a module that can be called, teasing apart its > > > > > reliance on the command-line interpreter to access filesystems and the > > > > > like. Also it now uses function arguments and its own context struct > > > > > internally rather than environment variables, which is very hard to > > > > > follow. No core functional change is included in the included PXE patches. > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > There is quite a long list of future work included in the documentation. > > > > > One question is the choice of naming. Since this is a bootloader, should > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix is already > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > The design is described here: > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > My question / concern is this. Would the next step here be to > > > > implement the generic UEFI boot path? Today, I can write Fedora 34 for > > > > AArch64 to a USB stick, boot U-Boot off of uSD card and the installer > > > > automatically boots. I'm sure I could do the same with the BSDs. > > > > Reading the documentation left me with the impression that every OSV > > > > would be expected to write something, so that their installer / OS boot. > > > > But there's already standards for that, which they do, and we should be > > > > implementing (and do, via the current distro_boot) or making easier to > > > > enable. Thanks! > > > > > > Here you are talking about scanning for a bootflow. It is not actually > > > OS-specific. If it were, there would be no point to this :-) > > > > > > If you look in the distro scripts you will see 'scan_dev_for_efi' (and > > > also scan_dev_for_scrips). At least the first needs to be implemented > > > a bit like the distro boot is at present. So far I have only > > > implemented scan_dev_for_extlinux (plus pxe) as it is enough to show > > > the concept. > > > > > > Adding EFI it's likely to be about the same amount of code as distro.c > > > at present, perhaps a little less since we don't have the network > > > case. It is used by Fedora 34, I believe, so is easy enough for me to > > > do. But I wanted to get something out as the concept is visible in > > > this series. > > > > OK, good. I'd certainly like to see how this looks with EFI added. > > > > What would be the order preference after scanning? (from other thread) With distro boot this is done with an environment variable, as I understand it. That is not implemented in this series, but is easy to do and is in the TODO. For now it can only be done with aliases to set the order of the bootmethods and that requires adding to the DT, so I don't think it scales well. I'm open to ideas though. > > Keep in mind that our efibootmgr is pretty complete wrt to booting. > It can even support booting multiple OS'es without GRUB2 (even loading > different initrds is supported). Ideally (and assuming we want to support > EFI booting for more devices), I would map existing extlinux configs into > efibootmgr entries. Yes I understand. I believe distro boot supports multiple OSes too, but perhaps only on different media? I'm not sure. Anywayt ere are always going to be people who don't want or need to use EFI (or grub) and it would be nice to support both seamlessly with the same concepts. From my side, my objective here is to provide suitable frameworks for: - locating devices we can boot from (via 'bootmethod' drivers) - locating instructions from OSes to boot (called 'bootflows') There are core features for a bootloader and U-Boot should probably have had them some time ago. >From what I can tell, we can make substantial improvements to the integration of the EFI code within U-Boot, particularly when the DM migrations are done. I see bootmethod/bootflow as part of that. BTW in the other direction, I have a prototype of U-Boot booting on EFI and accessing EFI devices from which to boot. It is based on Heinrich's work for iSCSI. Regards, Simon