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 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 84DC3C4338F for ; Mon, 23 Aug 2021 00:46:18 +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 83FF160F5E for ; Mon, 23 Aug 2021 00:46:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 83FF160F5E 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 B76CA821F0; Mon, 23 Aug 2021 02:46:14 +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="da6diSq5"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 61D9982C0C; Mon, 23 Aug 2021 02:46:13 +0200 (CEST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 8E82680394 for ; Mon, 23 Aug 2021 02:46:08 +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-pg1-x52f.google.com with SMTP id r2so15085298pgl.10 for ; Sun, 22 Aug 2021 17:46:08 -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=5+FqHAzjerzp3ziRXLyYcyeRtQl68vgqReZ4NdF5DaE=; b=da6diSq5F+Jf6mtO14+fjZ0w56+39wE3K7nsbQkSvscsXrVkgPqBH95Pc3Ucv63Gsq UZuyhWWTR3B0OAe3xpMHXbipyAr2a+hEnXc7DGhSlVs/4gve0eRBHzYNOfqoVhgMxHQ1 UfIITniuVpTgc8CL1OkKDTDnzB/3vOWcwRtbeKgr8qco461N5CzTVRyU9ZdZAbCqe1ds sdmc2MLaLIZlBd6ZVCqUEGE7FGQ5fDOzUkHfcZyTz8Ijt8wHRJBXzPfjHBRKUxDiDroK hYFimACYFoA1fD/AYRgwKMqnjqwDjAnhtemymepo0xWH3u+KNQd12ycwgxwELA1oDxJ0 fvQw== 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=5+FqHAzjerzp3ziRXLyYcyeRtQl68vgqReZ4NdF5DaE=; b=OTiWAHjLNQtNgrkq6hAIx3hGhfeMdVcjjrjwH0s4NpwHv21+Ahy+vLt5dc03UbougS 2bmjelAANB61tH0Zx12W9ELfNWJ3l/lFIPQgT5A3lAbD00y20bRvhsN2QMkc1zMnlDha Q2BDPQ9GHeh859dpOUpG/+6ELgX3A3VMPcRlvCB1tctNh5xy81PEqu0KLSdtf6t/ry7x epiJtuimHNpJv3cm0tdkFbCy6Npec73noSqTAXaLgk3H8GlPbC8sG0p2XdrJNBLF42kd QLFbwlj12w0Os+KldkYJaQxVWRl3SEPBFynip3jQwA2CFzBqvLLOvYpSW/hyHzh5/zHA 1bKw== X-Gm-Message-State: AOAM531Cgc/2dnQqac+DxxGR4KLpfCj6ekQJ9BxXE26D7bkJ8UC6nvan qTiydeIxfX8Ba7NptCTSgM773A== X-Google-Smtp-Source: ABdhPJw9fiM1NDlYRaG86s4cnCXWXeKc68hqEIews40hp4M2X4bc1yGyS8PH04ltKQALElKGyTgLcQ== X-Received: by 2002:a05:6a00:1891:b0:3eb:17e6:2847 with SMTP id x17-20020a056a00189100b003eb17e62847mr7851151pfh.20.1629679566306; Sun, 22 Aug 2021 17:46:06 -0700 (PDT) Received: from laputa (pdb6272e8.tkyea130.ap.so-net.ne.jp. [219.98.114.232]) by smtp.gmail.com with ESMTPSA id n41sm14117036pfv.43.2021.08.22.17.46.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Aug 2021 17:46:05 -0700 (PDT) Date: Mon, 23 Aug 2021 09:46:00 +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: <20210823004600.GA40863@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> <20210820031518.GA13452@laputa> 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 On Fri, Aug 20, 2021 at 12:22:17PM -0600, Simon Glass wrote: > Hi Takahiro, > > On Thu, 19 Aug 2021 at 21:15, AKASHI Takahiro > wrote: > > > > 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). > > I quite like bootmedia. Would just 'media' be OK? That would reduce > the use of the 'boot' prefix which I think is overused. If 'boot' prefix is removed, I'm afraid that the word, either media, method or flow, sounds quite generic and so ambiguous. As far as the commands are concerned, on the other hand, it might be one way to have sub-commands under 'boot', like "boot media ..." or "boot flow ..." although I'm not sure it is a preferred style on U-Boot. # I have no strong opinion here. > > > > > > > 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. > > OK see my reply to Tom on this point. The separate of concerns between > providing media and booting an OS is a key purpose of this series. > > I have Fedora 34 in my lab and will send an update for it next week. > > > > > > 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) > > Yes > > > > > 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() > > Yes > > > > > 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, > > No, this is not needed. Bootmethod provides the media so we don't have > a separate one for EFI. It is the bootflow detection that needs to be > changed (as above). Well, this is what I didn't really understand. How are all the boot flows enumerated? Looking at do_bootflow_scan(), for (i = 0, ret = 0; i < 100 && ret != -ESHUTDOWN; i++) { ret = bootmethod_get_bootflow(dev, i, &bflow); Here, the second argument, i (or seq), is used to indicate a partition number. So how can we add more than one bootflow to the same bootmethod (bootmedia in my language :)? -Takahiro Akashi > > > > 4)drivers/mm/Makefile > > obj-$(CONFIG_$(SPL_TPL_)BOOTMETHOD) += mmc_bootmethod.o mmc_efi_bootmethod.o > > No, this is not needed. > > See also the todo at the end of the bootflow docs. One day we may want > to expand add sort of interface for locating the files, instead of > calling it directly from bootflow. > > > > > 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? > > Yes, of course any feature increases the code size., although I'd > argue this is a feature that could/should have been added instead of > the scripts approach. It is much easier to understand and test. > > BTW you can try this out with sandbox. > > $ u-boot -T > => bootmethod list > => bootflow scan > > etc. > > Regards, > Simon