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,URIBL_BLOCKED,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 0A2CEC432BE for ; Thu, 26 Aug 2021 13:03:33 +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 281E761002 for ; Thu, 26 Aug 2021 13:03:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 281E761002 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 50A0282F4D; Thu, 26 Aug 2021 15:03:28 +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="D1ccpOA1"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E870E82F4D; Thu, 26 Aug 2021 15:03:25 +0200 (CEST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 D04F882C87 for ; Thu, 26 Aug 2021 15:03:19 +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-qv1-xf2c.google.com with SMTP id jv8so1947106qvb.3 for ; Thu, 26 Aug 2021 06:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=T++0nv5RsyCZEX15H8bRIiRr4sUn7TiIItpuHiY8Mr4=; b=D1ccpOA1eEoPjkB6s82ZvO0seMk+WGO8+SKZUXHAhsmCnY69RmLfYCM59/47PhLvAt x91iPelE76WXagxrOmownbMBR2WG6hZgDmGHicledvbOSc2DOm+1TdJq9DANu+iwyF5s lbEvtCseXO7rEn8kraeEOJCGiapNRMgUXDkeI= 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:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=T++0nv5RsyCZEX15H8bRIiRr4sUn7TiIItpuHiY8Mr4=; b=mH/TNB5Hp5HWQF4SkFHKnjtSdbWHCoixLB3XcVqMarBNJq05gjWW5PS1wth4RMUNHp 628c2nff75v7Rke/6QKJLsY4IunSmtvJF4FRymA0U/toe0DnfG1+v7EQeZGwJsIh4MO4 YjXGXt1hoBnmpQhYL/Xt/yEups2fywMF0cm7xeiRXgeqxCfyOT4pcIN1JdsQSIiP7K1C Kd8I8jj6r2sYolWjOvjPeC0qev46nGtwvrx0wLYA/Y4uCTJFq3N0SK+F5jAY4Pi/r/Pg Ms/EK2/MLd2d9L7cXnxXLlxiEo8KGCFJqsvSiM7kABTr0VF5V5y43u/MyWKuVCGMy7Jo h3VA== X-Gm-Message-State: AOAM532lNOyWW2/cVlXjY5b02dHmbiyakikUxyA0Vdo24tTMlW52mN5/ 49GF/Ocxr45SGoxNzlSqBIihmA== X-Google-Smtp-Source: ABdhPJx0VautSDWwvw2gyI/0WBdE3vqAWa+Os3osZg+RWNjn0v1xD4lMJy34caVpZZVgs82EWHuSuw== X-Received: by 2002:a0c:fd21:: with SMTP id i1mr3487284qvs.29.1629982998385; Thu, 26 Aug 2021 06:03:18 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-519a-4843-2801-9790.res6.spectrum.com. [2603:6081:7b01:cbda:519a:4843:2801:9790]) by smtp.gmail.com with ESMTPSA id p1sm2464839qkh.115.2021.08.26.06.03.16 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Aug 2021 06:03:17 -0700 (PDT) Date: Thu, 26 Aug 2021 09:03:15 -0400 From: Tom Rini To: AKASHI Takahiro , Mark Kettenis , sjg@chromium.org, manu@bidouilliste.com, u-boot@lists.denx.de, ilias.apalodimas@linaro.org, jaeckel-floss@eyet-services.de, michal.simek@xilinx.com, dennis@ausil.us, daniel.schwierzeck@gmail.com, lukas.auer@aisec.fraunhofer.de, jh80.chung@samsung.com, mbrugger@suse.com, peng.fan@nxp.com, swarren@nvidia.com, swarren@wwwdotorg.org Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow Message-ID: <20210826130315.GJ858@bill-the-cat> References: <20210823200146.GG858@bill-the-cat> <561412964a77c660@bloch.sibelius.xs4all.nl> <20210825124523.abf62a19a25e7491a4b4dae1@bidouilliste.com> <20210825144251.GB89209@laputa> <20210825145635.GV858@bill-the-cat> <56141a22c6ddf02a@bloch.sibelius.xs4all.nl> <20210825220605.GB858@bill-the-cat> <20210826063307.GA49579@laputa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LqRRTKS1oYfaDrOC" Content-Disposition: inline In-Reply-To: <20210826063307.GA49579@laputa> 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 --LqRRTKS1oYfaDrOC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 26, 2021 at 03:33:07PM +0900, AKASHI Takahiro wrote: > Mark, Tom, >=20 > On Wed, Aug 25, 2021 at 06:06:05PM -0400, Tom Rini wrote: > > On Wed, Aug 25, 2021 at 11:54:58PM +0200, Mark Kettenis wrote: > > > > Date: Wed, 25 Aug 2021 10:56:35 -0400 > > > > From: Tom Rini > > > >=20 > > > > On Wed, Aug 25, 2021 at 11:42:51PM +0900, AKASHI Takahiro wrote: > > > > > Simon, > > > > >=20 > > > > > On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > > > > > > Hi, > > > > > >=20 > > > > > > 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 wro= te: > > > > > > > > > > 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 ot= her 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 t= hese, enable to scan > > > > > > > > > > > > for bootflows from MMC and Ethernet. The only bootf= low supported is > > > > > > > > > > > > distro boot, i.e. an extlinux.conf file included on= a filesystem or > > > > > > > > > > > > tftp server. It works similiarly to the existing sc= ript-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 su= pport mechanisms other > > > > > > > > > > > > than distro boot, including EFI-related ones. With = a standard way to > > > > > > > > > > > > identify boot devices, these features become easier= =2E It also should > > > > > > > > > > > > support U-Boot scripts, for backwards compatibility= only. > > > > > > > > > > > > > > > > > > > > > > > > The first patch of this series moves boot-related c= ode out of common/ and > > > > > > > > > > > > into a new boot/ directory. This helps to collect t= hese related files > > > > > > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existin= g PXE implementation. > > > > > > > > > > > > Much of this series consists of cleaning up that co= de and refactoring it > > > > > > > > > > > > into something closer to a module that can be calle= d, teasing apart its > > > > > > > > > > > > reliance on the command-line interpreter to access = filesystems and the > > > > > > > > > > > > like. Also it now uses function arguments and its o= wn context struct > > > > > > > > > > > > internally rather than environment variables, which= is very hard to > > > > > > > > > > > > follow. No core functional change is included in th= e 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 'bo= ot' prefix is already > > > > > > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l= 61L2dav4ZkNC12/view?usp=3Dsharing > > > > > > > > > > > > > > > > > > > > > > > > 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 leas= t so far as I > > > > > > > > > > can see. For Fedora it seems to happen in grub. Do I ha= ve that right? > > > > > > > > > > > > > > > > > > Well, there's "find the next stage", which is boot_target= s environment > > > > > > > > > variable, and then "where that next stage looks for stuff= " which is > > > > > > > > > OS-dependent. Sometimes the ESP grub.cfg file is just en= ough to tell > > > > > > > > > grub to find the full grub.cfg file elsewhere, and someti= mes 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 l= ist. > > > > > > > > > > > > > > > > Right. With the current distroboot code the order of the d= evices that > > > > > > > > appears in boot_targets is determined by per-board/SOC/mach= ine config > > > > > > > > files and the order isn't the same for all of them. Users = can change > > > > > > > > the order if necessary by modifying the environment variabl= e and > > > > > > > > saving the environment. And for a one-off boot from a diff= erent > > > > > > > > device they can simply run an appropriate boot command. The > > > > > > > > boot_targets variable in particular is documented in variou= s install > > > > > > > > documents so it would probably be good of the new "bootmeth= od" 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 i= n a > > > > > > > > (mostly) uniform way across platforms by the OpenBSD bootlo= ader which > > > > > > > > can read an /etc/boot.conf that allows bootflow customizati= on. So as > > > > > > > > long as the default of the new code still results in > > > > > > > > \EFI\BOOT\BOOT{machine type short-name}.EFI being loaded an= d run if > > > > > > > > there is no U-Boot specific bootflow configured, I'm happy. > > > > > > > > > > > > > > Mostly the same for FreeBSD, as long as the efi boot.e= fi is > > > > > > > loaded and run by default (respecting the boot_targets order)= we will > > > > > > > be fine. > > > > > >=20 > > > > > > OK thanks for the info. My expectation is that bootmethod/bootf= low can > > > > > > support this easily enough (it is actually simpler than distro = boot). > > > > > >=20 > > > > > > > > > > > > > > > I can't speak for the other BSDs, but my impression is that= they are > > > > > > > > pretty much in the same position. The FreeBSD bootloader f= or example > > > > > > > > supports a high-degree of "bootflow" customization and I do= ubt that > > > > > > > > taking it out of the loop is a viable option for most users. > > > > > >=20 > > > > > > I think the same may happen with grub. E.g. with Ubuntu I see q= uite 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 va= lid > > > > > > bootflow is simply to jump to an EFI app, which seems to be wha= t is > > > > > > happening here. The bootflow side is really just about describi= ng 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. > > > > >=20 > > > > > By "EFI app", do you mean a way of booting "/efi/boot/bootXX.efi" > > > > > (default file name in case that no image path is specified)? > > > > >=20 > > > > > In fact, this behavior, or removable media support, is defined > > > > > as part of UEFI boot manager in UEFI specification. (See section = 3.5) > > > > > What this means is that the boot order, including a removable med= ia > > > > > case and user-provided BootXXXX cases, should be controlled solely > > > > > by "BootOrder" variable. > > > > > So the current combination of distro_bootcmd + UEFI boot manger d= oesn't > > > > > fully comply with the specification. > > > > >=20 > > > > > Even if those two cases are integrated, I don't know how "BootOrd= er" > > > > > semantics can be preserved in your approach. > > > >=20 > > > > I think the high level answer is that whereas today part of > > > > distro_bootcmd (and so iterating over boot_targets) "bootefi bootmg= r" > > > > gets run, with what Simon is proposing we would have an easier / qu= icker > > > > way to get over to just running that. Perhaps a clean-up to just u= se > > > > that, even? Or are we not to the point yet where we could remove t= he > > > > direct fall-back to /efi/boot/bootXX.efi ? > > >=20 > > > I think "bootefi bootmgr" only works if the BootOrder variable is > > > defined, and currently that isn't the case. > > >=20 > > > The boot manager behaviour as specified in the UEFI specification is > > > somewhat problematic to implement in U-Boot because of the limitations > > > in how variables can be set at runtime. This is one of the reasons > > > OpenBSD doesn't actually bother with setting the variables and simple > > > relies on the "removable media" support mentioned above. All my >=20 > Well, if this is everyone's consensus in (U-Boot) community, > it would be fine. But different people may have different > opinions/requirements on different systems. So I believe that > the safest way is to make UEFI implementation as compliant to > the specification as possible. Since a tangent to this has come up elsewhere recently, I just want to be clear that we should follow the spec, when there is a spec. > > > OpenBSD systems that use U-Boot print the follwing lines: > > >=20 > > > BootOrder not defined > > > EFI boot manager: Cannot load any image > > > Found EFI removable media binary efi/boot/bootaa64.efi > > >=20 > > > But maybe that last step can be intgrated into bootefi bootmgr at some > > > point? >=20 > Yes, it is doable, even I'm now trying to examine and address this issue > as I am fully aware of the situation. Yay. > > > Also note that manually manipulating the EFI variables to change the > > > boot order is quite cumbersome; it isn't a matter of just changed the > > > aforementioned BootOrder variable. That's why I think boot_targets is > > > the preferable way to define the order in which devices should be > > > booted. I don't think that violates the UEFI specification. It > > > merely is the way U-Boot implements the boot device selection that > > > more traditional UEFI implementations implement using a menu. > >=20 > > As I don't want to side-track Simon's thread even further, I would like > > to see a bit more detailed explanation of why U-Boot cannot support EFI > > variables, or if it's just a matter of someone doing the work, and it's > > not been a priority yet. >=20 > It is more or less a matter of implementation. > Historically, removable media support was added to distro_bootcmd first > and then boot manager was implemented later, only both were integrated > at script level. Since then, nobody, AFAIK, has complained about > the lack of integrity. That's what we see now. >=20 > One of difficulties that I found in the implementation is > how to specify preferred boot media in a form of EFI device path. > Take an example; I want to do > =3D> efidebug boot add -b 1 USB usb 0 "" -s "" ; USB port-1 > ^^^^^^^^ no image file specified > =3D> efidebug boot add -b 2 USB usb 1 "" -s "" ; USB port-2 > =3D> efidebug boot add -b 3 MMC mmc 0 "" -s "" ; MMC slot-1 > =3D> efidebug boot add -b 4 MYKERNEL scsi 0:1 /.../vmlinux.efi -s "..." > =3D> efidebug boot order 1 2 3 4 > =3D> bootefi bootmgr >=20 > First three commands will fail now. >=20 > Under the current implementation, neither "usb 0", "usb 1" nor "mmc 0", > which is set to be converted to device path representation in BootXXXX > variable, are recognized as a valid device since there is no physical > device attached to corresponding bus/port/slots at this time. > Internally, UEFI system/efidebug always tries to look for a U-Boot's > existing block device to identify the correct device path. > (Remember that *buses* and *controller* are even not udevices?). > So we would have to manage to create a valid internal representation of > bus or port for those media. >=20 > # FYI, my current prototype work already supports the following command l= ine > # and enables booting the system from the USB media if some storage device > # is attached to the port-1: > # =3D> efidebug boot add -b 1 USB usb 0:1 "" -s "" ; USB port-1 > ^^^^^^^ >=20 > As I'm not well-versed in U-Boot's device model, the rework > would be simpler than I anticipate. Thanks for the update on where you're at so far. --=20 Tom --LqRRTKS1oYfaDrOC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEnkRMACgkQFHw5/5Y0 tyweUgv+MpwgaE6BY6GqPcUa2OUEKRaXAL86P8G6WFk2h/JgizzDYZUwHxt430nZ Acnen57wbTPzMf0puKWxoNuQfVYL1007bf7U2RXQR8CXtIAjUcNbNOMeMowHnk1x GqBk9V1VL2h+OcNj369oZLX1F65iFky2mW6JGGrghxaZVlCb5pT7tjWgsb1UPhjO IVAiokXSDVY6gHyZYMAvwyURfwkvq3hCde8NWQLT5WrjEvKEbEwhm/3MEofzLRBz wwVSXzVIMLc521s9UgcWYm18c80338GMXD7khETCcwgnIBIzDNeSphhp4RigHYVD c+vTpmyU998WQQ2XqBMW7QPs1iFIuYgfMMsYY+F5zf/wuEnfAfbRd/CGV1N1KSS3 I7q4S3X8t1yMlOGOf03QcBzJjIbQTdBjZyekUpeinY/8WunrXYEbxNt5y7qpj8Sd m8R4wtAeDHQXcWw/VgtbwY4rfgDfZ/ep/TOBQffuBKvfABA53bqLbw+BBShyNluD aH79zjUS =Zz/+ -----END PGP SIGNATURE----- --LqRRTKS1oYfaDrOC--