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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC637C433EF for ; Fri, 29 Oct 2021 17:09:46 +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 D09056101B for ; Fri, 29 Oct 2021 17:09:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D09056101B 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 D403182FE7; Fri, 29 Oct 2021 19:09:43 +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="I/A/kOFZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 31FFB831B2; Fri, 29 Oct 2021 19:09:42 +0200 (CEST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 9FB1D82C4C for ; Fri, 29 Oct 2021 19:09:37 +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=ilias.apalodimas@linaro.org Received: by mail-yb1-xb2a.google.com with SMTP id 67so25845237yba.6 for ; Fri, 29 Oct 2021 10:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jdl/XR/sdi3meOPYROd6qUUkUPiblXVDbXrE2NerNTM=; b=I/A/kOFZ3sA8PjsTr0isnq0xQnChI2gXdgSxyuv8u2hHDz93o5J+Ng4ckKR7IeX9+Q XtwS36sv37f9IJSeqJrv6HcS/ivIG3W7NecbIz+JwkGkT4qoao56OVnWdswDUqjkRvit HB0fauUBX0NZvdPGr8TCY5OumJ7eS6zhyrKPqAlBe2VziOPL2H8eG02cE0XvcNqBA2Oy A6lg/6ck/pFkRNsczuSvFKocQPLLxXc1CcnbTMs9+FANu2KNk+DefcXW1C20GN0FwGbQ Gk1l0PAJU9lOkHossKpdVJGnPvA8D8SWsVBdUa3b4MBTQwM3+A60Z4qJHCdcUkqv5Nnj Q4TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jdl/XR/sdi3meOPYROd6qUUkUPiblXVDbXrE2NerNTM=; b=nXEvR1eG/xjS5IWS1ArDoAmSrlXQoUie1nas1oSX+xyGm+6LtcOHq7JkKAeNUTtYl0 Vambw5raEPwdu1B25GozcSJrVhLE1GiVimu+UiO/5u/TxQISbqAE9hZeGwYb/NFnmSb4 P1NQGT8rFaL5wAlWiihAn6qg92hZ42ejuZmFtyk0gUj/JmhKjpktALNWaPIECn+HOXZ2 Xy4jiaTnagUyMVqrZTaEXMg0FopT6JKZQIl8HG+KoZLFQyDElkCGCcJC7WXRS+cvdR// XMtUGyobdbt6j6+I+ttmO7Ru1wG/UvvCeahGzV3JEBfkk1ZSzce3L40Fx7kD2d3wiy3s ssYQ== X-Gm-Message-State: AOAM530uJdDrc0XbPllIYr2JmnziHVsnEnwXFLbWn4xPxIXLICtjIVD2 X0lg63vMg378m8WTsxb76pCJlLfnttiM+Npj4kWi+Q== X-Google-Smtp-Source: ABdhPJw2oRltU52qY1A8LFStzy6LBG2xOELiu6h3u/1d3/mLpgMvhyoAOhUxiUypL2ObgdZTs755mb2yp96XNZDarTY= X-Received: by 2002:a25:bacd:: with SMTP id a13mr14655467ybk.216.1635527375743; Fri, 29 Oct 2021 10:09:35 -0700 (PDT) MIME-Version: 1.0 References: <20211023232635.9195-1-sjg@chromium.org> <20211023232635.9195-22-sjg@chromium.org> <20211029123907.GS8284@bill-the-cat> In-Reply-To: From: Ilias Apalodimas Date: Fri, 29 Oct 2021 20:08:58 +0300 Message-ID: Subject: Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot To: Mark Kettenis Cc: trini@konsulko.com, sjg@chromium.org, u-boot@lists.denx.de, michal.simek@xilinx.com, xypron.glpk@gmx.de, daniel.schwierzeck@gmail.com, jaeckel-floss@eyet-services.de, marek.behun@nic.cz, lukas.auer@aisec.fraunhofer.de, dennis@ausil.us 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 Mark, On Fri, 29 Oct 2021 at 19:37, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Fri, 29 Oct 2021 16:42:45 +0300 > > > > Hi Tom, > > > > On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > > > > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > > > Hi Ilias, > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass wrote: > > > > > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER. > > > > > > > > > > > > > > > > > > In effect, this provides the same functionality as the 'bootefi' command > > > > > > > > > and shares the same code. But the interface into it is via a bootmeth, > > > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. Future work may > > > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE being enabled. > > > > > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't include this > > > > > > > > patch at all. EFI has it's bootmgr which can handle booting just fine. > > > > > > > > I don't see why we should duplicate the functionality. The new boot > > > > > > > > method can just have an entry called 'EFI' and then let the existing > > > > > > > > EFI code to decide. > > > > > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr starts > > > > > > > being used then it can still be invoked from standard boot. The point > > > > > > > is that there is a standard way of booting that supports EFI and other > > > > > > > things. > > > > > > > > > > > > This patch tries to reason about the default naming EFI imposes on it's > > > > > > boot files. distro_efi_read_bootflow() will try to find files following the > > > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If those are > > > > > > found it will try to boot them right? That's not the right thing to do though. > > > > > > On the EFI spec these files are tried if no Boot#### variables are found. > > > > > > So we can get rid of this entirely, add a dummy entry on the bootflow that > > > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > > > > > The efibootmgr then will check Boot#### variables and if none are found, > > > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > > > essentially offering identical functionality. > > > > > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > > > for that too, as you can see in the other patch. We may need to adjust > > > > > the order, by the sound of it, if it needs to run before EFI things. > > > > > But that is easy enough. > > > > > > > > That's the point though. I don't want to have 2 different ways of booting EFI > > > > as I don't see any benefit. Do you? > > > > > > Unless we're saying that "bootefi bootmgr" is ready to be used always > > > and without further pre-req support (which I don't think is quite the > > > case, since we don't have persistent EFI vars, so can't set Boot### > > > persistently or via userspace) _something_ is likely needed to either > > > set those, or scan a configurable list of where, to find the EFI > > > payload. > > > > The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if > > Boot### variables are not found. The Boot#### themselves are > > obviously configurable from U-Boot(at boot time). Since this method > > doesn't allow Linux to edit the boot options either, is it something > > we need? Since distros usually name their SHIM as bootaa64.efi, I am > > afraid we are adding code that we will rarely (if at all) ever use. > > Hi Ilias, > > I'm still seeing: > > Device 0: Vendor: Lexar Rev: 1100 Prod: USB Flash Drive > Type: Removable Hard Disk > Capacity: 30526.0 MB = 29.8 GB (62517248 x 512) > ... is now current device > Scanning usb 0:1... > ** Unable to read file / ** > Failed to load '/' > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > BootOrder not defined > EFI boot manager: Cannot load any image > Found EFI removable media binary efi/boot/bootaa64.efi > 170694 bytes read in 9 ms (18.1 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > Booting /efi\boot\bootaa64.efi > > So it doesn't seem that efibootmgr will try to bootaa64.efi just yet. Yea Akashi-san already corrected me on this one. I was somehow under the impression we do that already, while it's the distro bootcmd doing that. In any case it would make much more sense for me to add the missing pieces in the efibootmgr, instead of an extra app. That way we can either cleanup the distro bootmcd or skip this patch when Simon's proposal gets resubmitted. Thanks! /Ilias > > Cheers, > > Mark