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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 8E31BC4338F for ; Mon, 23 Aug 2021 20:09:12 +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 ACF7C613D0 for ; Mon, 23 Aug 2021 20:09:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ACF7C613D0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 9E079807FE; Mon, 23 Aug 2021 22:09:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="YM3qp5TY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CA04C807FE; Mon, 23 Aug 2021 22:09:05 +0200 (CEST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 623F080796 for ; Mon, 23 Aug 2021 22:08:59 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72f.google.com with SMTP id y144so20597985qkb.6 for ; Mon, 23 Aug 2021 13:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DTCwBmB4m85eF4RxcbpyV26gXzB4VNL+rMH5BL1HgmA=; b=YM3qp5TYt14hssivRvxcoRcKwsEmZNlPLiI1rLC+d4aI7RHjOqTBj/C6Lz1PQXKv1e wRSnBoIkvw8a8plWDKDgYI3zqFIuqfbtB2G3Ny8o8wOSzWv9yDBXr1SPvEqdCUHfzYSJ d3MIbwz0o16c4B3TnkyYWBgse9atL4omo1sXU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DTCwBmB4m85eF4RxcbpyV26gXzB4VNL+rMH5BL1HgmA=; b=Icil5Q+jv51UnxtN5WI9bMVgBhhhFygmUZ0SEvO3D/pzxsykQh3QQftvlvA8aZS32I ZsoKekOk53lmcSTfVV3L8JI2vH/W6dzBeM1eyFRJcUEo+aLoG3Dw11lN1BGS+5q6oCoE Jb6MuOEh+7AcwwUsPoQfoqmcprDSbtR+qQyeLok8a49BlmCHuQwi9sbarr+OA8axuFrg 8gITkF/F1F3FSoC90tioggNkNF+X15KEaN9ZQUl8auPMyb/aJu81I0vDGZi6W/7MljbZ ywdRrYz5j4D2m9jBGw9Wjk7lQeZ3gxqNt08ldt8L6AlrfiAN7mrWM6ZeJCRcKJnFGbn6 wB7A== X-Gm-Message-State: AOAM5303zeMwrIWQBvUd/0NqZID2nON6+errHrc78RNKnR+cGOwTfBEz 8eJK+ki5gHdd6+PcWzj3LBUndw== X-Google-Smtp-Source: ABdhPJz898g34YUXtqxynMRaAbErg6w8Zhbcboto/CIeVmUm5byL2xWTFojCViR2M29STOKQLXid0w== X-Received: by 2002:a37:cd6:: with SMTP id 205mr23438269qkm.19.1629749337993; Mon, 23 Aug 2021 13:08:57 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-180d-b350-bd40-4e05.res6.spectrum.com. [2603:6081:7b01:cbda:180d:b350:bd40:4e05]) by smtp.gmail.com with ESMTPSA id i16sm7117038qtw.15.2021.08.23.13.08.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Aug 2021 13:08:57 -0700 (PDT) Date: Mon, 23 Aug 2021 16:08:54 -0400 From: Tom Rini To: Simon Glass Cc: Ilias Apalodimas , U-Boot Mailing List , Steffen Jaeckel , Michal Simek , Dennis Gilmore , Daniel Schwierzeck , Lukas Auer , Jaehoon Chung , Matthias Brugger , Peng Fan , Stephen Warren , Stephen Warren Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow Message-ID: <20210823200854.GH858@bill-the-cat> References: <20210819034601.1618773-1-sjg@chromium.org> <20210819135944.GX858@bill-the-cat> <20210819172750.GB858@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+WPm3QkAPy0k3+m5" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --+WPm3QkAPy0k3+m5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 23, 2021 at 11:25:40AM -0600, Simon Glass wrote: > Hi Ilias, >=20 > 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 au= tomatically boot > > > > > > an Operating System without custom scripting and other customis= ation: > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows (o= wned by U-Boot) > > > > > > - bootflow - a description of how to boot (owned by the distr= o) > > > > > > > > > > > > This series provides an initial implementation of these, enable= to scan > > > > > > for bootflows from MMC and Ethernet. The only bootflow supporte= d is > > > > > > distro boot, i.e. an extlinux.conf file included on a filesyste= m or > > > > > > tftp server. It works similiarly to the existing script-based a= pproach, > > > > > > 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 b= oot each > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > It is intended that this approach be expanded to support mechan= isms other > > > > > > than distro boot, including EFI-related ones. With a standard w= ay to > > > > > > identify boot devices, these features become easier. It also sh= ould > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > The first patch of this series moves boot-related code out of c= ommon/ 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 implem= entation. > > > > > > Much of this series consists of cleaning up that code and refac= toring it > > > > > > into something closer to a module that can be called, teasing a= part its > > > > > > reliance on the command-line interpreter to access filesystems = and the > > > > > > like. Also it now uses function arguments and its own context s= truct > > > > > > internally rather than environment variables, which is very har= d to > > > > > > follow. No core functional change is included in the included P= XE patches. > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > There is quite a long list of future work included in the docum= entation. > > > > > > One question is the choice of naming. Since this is a bootloade= r, should > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix i= s already > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC= 12/view?usp=3Dsharing > > > > > > > > > > > > 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 insta= ller > > > > > 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 / O= S boot. > > > > > But there's already standards for that, which they do, and we sho= uld be > > > > > implementing (and do, via the current distro_boot) or making easi= er to > > > > > enable. Thanks! > > > > > > > > Here you are talking about scanning for a bootflow. It is not actua= lly > > > > 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 implement= ed > > > > 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 distr= o.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? >=20 > (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. >=20 > > > > 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 supp= ort > > EFI booting for more devices), I would map existing extlinux configs in= to > > efibootmgr entries. >=20 > 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) Well, here's where I'm a bit curious. I have seen at least twice "wait, EFI stub in the linux kernel adds how much?" type commentary. I don't know how prevalent that type of concern will really be given just how often I don't see the Linux kernel config shrunk down from what the reference platform started with. And as Ilias is pointing out, you can do _a_lot_ with efibootmgr and without grub/whatever. And both Arm (the company) and RISC-V (the overarching organization) are both pushing to standardize around the idea that if you're on something bigger than an MCU, EFI-the-ABI should get you up and running. --=20 Tom --+WPm3QkAPy0k3+m5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEkAFYACgkQFHw5/5Y0 tywAZAwAl7wi1GEMDftFRI+gOeTkbxobp/T4abJ91UemlrXuNU80ioh2UfcBgKRQ a9KqgYJE4EikWK+DGKUoo6f7Td4c5LCD8U9fK064Z0Ee/9vcqS55cRFBXqXHB5Qg xnix79SSxAp/AF14nNKqn7uSdA0u16cYeXuCYJyZKJewsUI6+S75fV0zvAHyTYUc uySRhzigmko4HWdY1P6BZb7ayNQciKOei0OvD9DzmZT/7IftZciq6dZBi7Auta6l TLb/HMzTQk8sLySdP0384QPtJ7t9PF6dy0OspMVZrwYS7o6yzmp1g8hD7BGRY7+s uFWAbA1DfMOWqG0AneLQVjt62ls9FCDQvBjOmewPnXPsDAnlJC7jQ2rAa10PgHAg f5tpJgrB6B/1aJ1uzSyr/XHUjNysyu02JRQSgKWMUi/EBxmY09gIp6dVky6AWMrB zS5sur3FXespE8UZ6Mg76gCoT269qfZHnJD7TqY3s/lrYVckHc6Nzw3RrYFSG+c7 EcmLNjTO =Bc7B -----END PGP SIGNATURE----- --+WPm3QkAPy0k3+m5--