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 CB68EC4338F for ; Wed, 25 Aug 2021 13:12:27 +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 CDA2661101 for ; Wed, 25 Aug 2021 13:12:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CDA2661101 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 585FB82E3F; Wed, 25 Aug 2021 15:12:19 +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="ZrRiy0vu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D5D2981EBD; Wed, 25 Aug 2021 15:12:07 +0200 (CEST) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 5A06E82D5B for ; Wed, 25 Aug 2021 15:11:59 +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-wm1-x32b.google.com with SMTP id v20-20020a1cf714000000b002e71f4d2026so3618584wmh.1 for ; Wed, 25 Aug 2021 06:11:59 -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=uifnvtHxZxdafMRPAxbN6/A9U3K7dHA5kCdeI4xRe9o=; b=ZrRiy0vu1ZMeFDNNpwYaNWc/gcDv4qB7aHzNIhffcwGACNFInt2YBdGDJnYQCLucG2 Ie7x7k3TCiSA1iDmquYDY7bOT/wgRDY1Ys39vqdeGB0innvTRIT+e9h1U5HIZ/QgY/Gn kOhoixrheuPYhI7StXZRUPDiP0ZbAkZHa4l18= 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=uifnvtHxZxdafMRPAxbN6/A9U3K7dHA5kCdeI4xRe9o=; b=mj8PGkmASSWvhupO1k9Wk49KfveiMhwGCwZcHxcdVtfuhqkAN7eK+rUh3BH6wCVHbL FXoRGsOTNCDijm7dC5b5OCT2wg0s+JcLtGbOz2bcsCezxjjJ5Zd4yJUi4lFBCnIcf+ht FLQU2dV8f/5Pux9m9JoM0ZTTZp6ZPFmM0UbDpBBp5iA0xB65RLs26xwD4o9HfY48anqF 6Go3xae4rLhJIKEN1vE433Nz+QRwYL98ATFu+rT9XY0uKC44CazjIXPFuCXdzsjVrPMi YWgdsdhiMcFCj3LhQG5v5LYTdsmNolEBtwh7ancvAtqkDGhE1N2Dw2HwaNtOIff21nzy tZ2Q== X-Gm-Message-State: AOAM533i6O6Nboe9uo+epWXQm103VdDjB1P7Aa1zIBIz5SqCzj19Tdjg 1VfohATsAJmsviEQ0YYXgIVecE7Wwg7v3/eQaX29AQ== X-Google-Smtp-Source: ABdhPJzWS1LBOiw7LXodSnNXB2qxis/YTf+y+U6lcQjTy6X0ktUpXfiOwfJC8k8SexV+hg3i36brXOJVXfIR25Z/HTM= X-Received: by 2002:a05:600c:220f:: with SMTP id z15mr348938wml.74.1629897118535; Wed, 25 Aug 2021 06:11:58 -0700 (PDT) MIME-Version: 1.0 References: <20210819034601.1618773-1-sjg@chromium.org> <20210819135944.GX858@bill-the-cat> <20210819172750.GB858@bill-the-cat> <20210823200854.GH858@bill-the-cat> In-Reply-To: From: Simon Glass Date: Wed, 25 Aug 2021 07:11:46 -0600 Message-ID: Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow To: Ilias Apalodimas Cc: Tom Rini , U-Boot Mailing List , 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 Ilias, On Tue, 24 Aug 2021 at 03:30, Ilias Apalodimas wrote: > > Hi Tom, > > > > > > > > > > > [...] > > > > > > > > > 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! > > > > > > > > > > > > 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. > > > > > > > > > > OK, good. I'd certainly like to see how this looks with EFI added. > > > > > > > > > > > > > What would be the order preference after scanning? > > > > > > (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. > > > > > > > > > > > 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 support > > > > EFI booting for more devices), I would map existing extlinux configs into > > > > efibootmgr entries. > > > > > > 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. > > Exactly. Keep in mind that RISC-V is looking into EBBR as well, so this is > far from an 'Arm thing'. Moreover, the efi stub side of the kernel for > risc-v, will only load an initrd using the EFI_LOAD_FILE2 protocol we added > support for. So right now the only way to properly boot a RISC-V with EFI is > through the manager. I had heard that RISC-V was just going to use UEFI (and not U-Boot), but perhaps that is not correct. So far I have not really done anything with RISC-V so am not familiar with it. Regards, Simon