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 08DDBC4338F for ; Wed, 25 Aug 2021 13:12:17 +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 04C3F610CE for ; Wed, 25 Aug 2021 13:12:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 04C3F610CE 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 7360982952; Wed, 25 Aug 2021 15:12:14 +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="KIOzm9OP"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id F2E2282DF6; Wed, 25 Aug 2021 15:12:03 +0200 (CEST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 585E381EBD for ; Wed, 25 Aug 2021 15:11:57 +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-x42b.google.com with SMTP id q11so9432027wrr.9 for ; Wed, 25 Aug 2021 06:11:57 -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=IvbzY0iemejKUh1sf/0bKQ0ddZQznjiuTCVI3KTFMjw=; b=KIOzm9OPA2kp9gMKaVPbsI2Mmt5YSeLDhB8xZWf1nV2oaXyFpLaTH+EjVikI0JiIbA zfWRB+F1QipvZCUJGTa4FUMgCPUSoymrvGds2Y3uaiUqu1jB/juy9/Bp2/DFD9Zefnl2 tvX+J9+CmqzmrtTl/nuVKFUVN8IsEkzmRv9aY= 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=IvbzY0iemejKUh1sf/0bKQ0ddZQznjiuTCVI3KTFMjw=; b=MNPApqQ1KtDVhPrbDLl3IB+WyCwiUZ1tKLNQPAmWCtXf+fk7NiWAAQB2uC8UL2DlLX cacBsCPCIq389yB5aFS04x2TtngWrSiY+JzLnjGI1H6D98kB1kUxLON3YpLLNFnTqQb2 a25KYXGBPkTT2HfsmiA21JH0TMGjZ0AeflcTv8tXSyKNhMmoiLV720Yzf46P7m19Q1pl u1A/Kg5dJfG7vlXX5dAj5ka3xDFJTrxNkJnuWh5scYvZIumIa7ypQpU+QR/fdbLn5gds HbOFN2S2xvSzVzfIIhqlIxox90ZpEMUunJgufKUU1DTyoVmAUUDorRRAaft5WbR4hpqv SYKg== X-Gm-Message-State: AOAM530N7bx9xiW4UlEVOxQm5QfyF5Dw2/W2CoDCe4vRfACjasRstOOS RZQzbGTdPT0AB8YABlWckB91aQEWzgRroKEF7i+KlA== X-Google-Smtp-Source: ABdhPJwxYlL9E3RTiLDvo8w+70SUzOYgXH4ji8CsdyCp5BC/ftvU3X7vyQ4DLIHMrR8ULz+lasy6U8zzrd0nrutip54= X-Received: by 2002:adf:eb89:: with SMTP id t9mr26393108wrn.66.1629897116520; Wed, 25 Aug 2021 06:11:56 -0700 (PDT) MIME-Version: 1.0 References: <20210819034601.1618773-1-sjg@chromium.org> <56140f0c4976b9f9@bloch.sibelius.xs4all.nl> <20210823200146.GG858@bill-the-cat> <561412964a77c660@bloch.sibelius.xs4all.nl> <20210825124523.abf62a19a25e7491a4b4dae1@bidouilliste.com> In-Reply-To: <20210825124523.abf62a19a25e7491a4b4dae1@bidouilliste.com> From: Simon Glass Date: Wed, 25 Aug 2021 07:11:44 -0600 Message-ID: Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow To: Emmanuel Vadot Cc: Mark Kettenis , Tom Rini , U-Boot Mailing List , Ilias Apalodimas , 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, On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot wrote: > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > Mark Kettenis wrote: > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > From: Tom Rini > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > Hi Mark, > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > 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 > > > > > > > > > > How does the user control the order in which devices are scanned/booted? > > > > > > > > That is not supported in distroboot at present, at least so far as I > > > > can see. For Fedora it seems to happen in grub. Do I have that right? > > > > > > Well, there's "find the next stage", which is boot_targets environment > > > variable, and then "where that next stage looks for stuff" which is > > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell > > > grub to find the full grub.cfg file elsewhere, and sometimes it's a full > > > grub.cfg file. I think Mark is talking about the former, and you've > > > said it's not part of this series, yet, but on the TODO list. > > > > Right. With the current distroboot code the order of the devices that > > appears in boot_targets is determined by per-board/SOC/machine config > > files and the order isn't the same for all of them. Users can change > > the order if necessary by modifying the environment variable and > > saving the environment. And for a one-off boot from a different > > device they can simply run an appropriate boot command. The > > boot_targets variable in particular is documented in various install > > documents so it would probably be good of the new "bootmethod" code > > would respect this variable. > > > > For OpenBSD I'm not really interested in the bootflow part. As I > > explained in the past, that part of the problem is solved in a > > (mostly) uniform way across platforms by the OpenBSD bootloader which > > can read an /etc/boot.conf that allows bootflow customization. So as > > long as the default of the new code still results in > > \EFI\BOOT\BOOT{machine type short-name}.EFI being loaded and run if > > there is no U-Boot specific bootflow configured, I'm happy. > > Mostly the same for FreeBSD, as long as the efi boot.efi is > loaded and run by default (respecting the boot_targets order) we will > be fine. OK thanks for the info. My expectation is that bootmethod/bootflow can support this easily enough (it is actually simpler than distro boot). > > > I can't speak for the other BSDs, but my impression is that they are > > pretty much in the same position. The FreeBSD bootloader for example > > supports a high-degree of "bootflow" customization and I doubt that > > taking it out of the loop is a viable option for most users. I think the same may happen with grub. E.g. with Ubuntu I see quite a bit of code in the grub.cfg file and it's not clear to me that it can be replaced with a 'data instead of code' approach. Still, a valid bootflow is simply to jump to an EFI app, which seems to be what is happening here. The bootflow side is really just about describing what to do, and this case is no different. For now I see three types of bootflow, PXE/syslinux, EFI boot manager and EFI app. I'm travelling for three weeks soon, so if it doesn't happen this week I'll continue this after that. Regards, Simon