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=-5.8 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 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 D0DFFC4338F for ; Fri, 20 Aug 2021 03:15:44 +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 E2F7F610CB for ; Fri, 20 Aug 2021 03:15:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E2F7F610CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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 792AD82BFA; Fri, 20 Aug 2021 05:15:41 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="UuT8DrJx"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4C34A81EBD; Fri, 20 Aug 2021 05:15:39 +0200 (CEST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 88A3F81EBD for ; Fri, 20 Aug 2021 05:15:34 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pj1-x102f.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so12883778pjr.1 for ; Thu, 19 Aug 2021 20:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=E39uPkY7z/czUjSm7FyTXyOypGdQvD/AUV/xwb3POg0=; b=UuT8DrJxz/uHFUqrXIYn8sIyL/CiytOYQlN92/N86T3PboDttGzv0DjblTL2aqXYN+ WLLfOBbpNaMFrm48V3LGBJaO39rBAEQGFbz4PTu32dc5OW34kZ4KuUkbXrEghsX/GO+K oKqM8vQZObCMRXsyI4po5+fw1vYVgb5P6BbGrxW3zl2wYKaVe0JUXCor3qvaxnYkRSvO IQfv2w1LHNlrVs9KaP9DWJwALDHtj/GkgW7sDpyAyXPipQEs3RNVMQqE5zJFOekMsWzL 0a1WxkwMTiQn4t6BOdKIGURfJEapNKMAACHXlKOpcEstIob7lAfBHL0fTLSnHLHiQr63 LrnA== 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=E39uPkY7z/czUjSm7FyTXyOypGdQvD/AUV/xwb3POg0=; b=Mc+iy7IZZ6ODeih5MTS370VIYo0huZ+kpRKKK9aFYLWIcxUtRhrB0EGNb4fxz+0aJn HR9l1wHOKSTvDgbbdxHBZu/6kaJAErPil6rdiD5jXyCYpHTpEEN/dCQiCWwN62IoExMS tS6vv0mmpvM9HFpdnryHUWBqgmOxnwAL90gNGPFpL4n4cQ4tqxa8d18Zl8V70FF2aMut cHKbFDvhUKIxoCLXHaL4mgvvDgaIxNIIHk9ZWudt3/ruDkZh2RYyVyRxzzfH2glCZpfy pXRJ2jMkxE31xpHUycsnE4w3F8iA0ISk30UJHyXir2tqp/puNs+WV+lkp+XY87jGN/Ra diQg== X-Gm-Message-State: AOAM532DzCYnc/YBMDh48+F+MrgDAFx/l8ogtjIoVFyP5JMobzLB+M++ +Oby4gAPGVn8fRqcWPx1o4Z0Jg== X-Google-Smtp-Source: ABdhPJzn1PFdvfj7LMBfwt5PT1xZIbrtpK6+fSKstFxdkmr6U+44qFZ5dKEVjg5HeoeGlWzycWO1yA== X-Received: by 2002:a17:90a:ce16:: with SMTP id f22mr2357345pju.90.1629429332533; Thu, 19 Aug 2021 20:15:32 -0700 (PDT) Received: from laputa (pdb6272e8.tkyea130.ap.so-net.ne.jp. [219.98.114.232]) by smtp.gmail.com with ESMTPSA id e8sm6001993pgg.31.2021.08.19.20.15.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Aug 2021 20:15:32 -0700 (PDT) Date: Fri, 20 Aug 2021 12:15:18 +0900 From: AKASHI Takahiro To: Simon Glass Cc: 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 Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow Message-ID: <20210820031518.GA13452@laputa> Mail-Followup-To: AKASHI Takahiro , Simon Glass , 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 References: <20210819034601.1618773-1-sjg@chromium.org> <20210819135944.GX858@bill-the-cat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Simon, 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. Regarding the naming, I'm still a bit confused with bootmethod vs. bootflow. Personally, I prefer a more intuitive name against bootmethod, say, bootmedia or bootdevice (as the original distro_bootcmd uses). > > > 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! I had the same concern. > 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. If I correctly understand this framework, we will have to write several functions: (Here I will ignore "UEFI boot manager" sequence.) 1)boot/distro_efi.c distro_boot_efi_setup() ; almost the same as distro_boot_setup() distro_boot_efi() ; search for /EFI/BOOT/BOOTAA64.EFI (and dtb) 2)boot/bootflow.c bootmethod_find_efi_in_blk() call distro_boot_efi_setup() bootflow_boot() CASE BOOTFLOWT_DISTRO_EFI: ; new bootflow type call distro_boot_efi() 3)drivers/mmc/mmc_bootmethod.c mmc_efi_get_bootflow() call bootmethod_find_efi_in_blk() U_BOOT_DRIVER(mmc_efi_bootmethod) = .name = "mmc_efi_bootmethod", .id = UCLASS_BOOTMETHOD, 4)drivers/mm/Makefile obj-$(CONFIG_$(SPL_TPL_)BOOTMETHOD) += mmc_bootmethod.o mmc_efi_bootmethod.o Do you think that the above is correct? If so, does (3) (+ (1)/(2)) inevitably increase the code size as we need functions for all devices? -Takahiro Akashi > Regards, > Simon