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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id D2764C433F5 for ; Mon, 4 Apr 2022 14:51:47 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 982F483774; Mon, 4 Apr 2022 16:51:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=freebsd.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; secure) header.d=freebsd.org header.i=@freebsd.org header.b="K/3Ye5Oc"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0322083921; Mon, 4 Apr 2022 16:51:43 +0200 (CEST) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EFB5283774 for ; Mon, 4 Apr 2022 16:51:35 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=freebsd.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kevans@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id DB1669294D for ; Mon, 4 Apr 2022 14:51:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXDHp5Mqsz4mXF for ; Mon, 4 Apr 2022 14:51:34 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649083894; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Coc4hYOWUSR/wgwqe3eRCASsBC2oucz2xEuNH4kykmw=; b=K/3Ye5OcSHB9qNrPTGGXk6cr5gvDhf9WjEgwdwyxahqSJGPsXKeHQ+r82wQuNuO+3QLewi Jb/mcCLBVEg3pgoYPBE53rJ81sJXb3kj42dD3HvXgcjNJzmv0EWmOxPGcK4EHJIxuhIcDj gPGadihqx+ASzH1bTygIDh3iVzT6+37NKmO5g49wRMVHOptDSNUIk9v2yXE510Dz96RB04 WkMz6QoHh22R4JmEb8E6lH5NH34UZsyLVftVkSDRcYcpglDGqkUk28Pm6WzOJfkzMcAwXN Cin7L98g2zCr+3hmQU4TKwNM6S7LzyOGLH41HkLCSvsMPBheTmn4nHursv3uLQ== Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 5E0B68203 for ; Mon, 4 Apr 2022 14:51:34 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f169.google.com with SMTP id g24so13205133lja.7 for ; Mon, 04 Apr 2022 07:51:34 -0700 (PDT) X-Gm-Message-State: AOAM532Ok9GPpDjiJEg8tU9CiUR050tpZ6OmnMcdLjAbWR+etkJpUxnF ZL/HOwOMlxcbUGQvPp7XUpi7NoiYGSkpwPCR9e0= X-Google-Smtp-Source: ABdhPJwDmqSa0Ez6HKELokftK4gIMRb8flTfQOudqo0lJ1Igs2ujPG+LhYbg0BoeS1LoO1X7QqRx+syxTgktlNoHrcg= X-Received: by 2002:a2e:bf22:0:b0:247:da0b:e091 with SMTP id c34-20020a2ebf22000000b00247da0be091mr90336ljr.489.1649083892994; Mon, 04 Apr 2022 07:51:32 -0700 (PDT) MIME-Version: 1.0 References: <20210112195842.252946-1-xypron.glpk@gmx.de> <20210112195842.252946-4-xypron.glpk@gmx.de> <7304AC06-9D2D-4F24-8066-F9CF854F7334@gmx.de> <9491CEF0-F9F2-4DED-833D-3DE3F2670B53@gmx.de> In-Reply-To: <9491CEF0-F9F2-4DED-833D-3DE3F2670B53@gmx.de> From: Kyle Evans Date: Mon, 4 Apr 2022 09:51:21 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 3/3] efi_loader: setting boot device To: Heinrich Schuchardt Cc: Alexander Graf , Joe Hershberger , Simon Glass , Joao Marcos Costa , Richard Genoud , Niel Fourie , u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649083894; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Coc4hYOWUSR/wgwqe3eRCASsBC2oucz2xEuNH4kykmw=; b=tsNWMdc27iwhJGc+SAOUyEhrxK+8+o15ztdMfMWHiRTm1SFXtst6s7xFViejIMsGcByiXh TzzWb+EY/dkJRLjwH7bYSjsOIWXFomWHF8DPqANPaX/kHJ146mfETgNYveivWSNP7IzMpr ApBcOK0Oy4L+eYPjeZALGv8lVch1qMdkr8j2JEVMV6IAD/lT3YglMfJVmnExxZ5X+KKau7 ACXIIZ+u9vwhxXm4C9/FWN3/78o0qw/knpy+PAhXC3oXesmS3j8tkK3wXKaouHohURE4FT 2iLTnkVm7qX4X6sTx8xT8YwUWAb7Z/cHULKVKTVWkwapgaV92I8ppodBAeNVTA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649083894; a=rsa-sha256; cv=none; b=Gtthqoz7zuXR9bxvFgjruXF2C2t0UqqSVRzUxOpW0VqmaIbKOCcHB/dwU9tZEKu5FYETyH ncepA/dzL73qyVNtHaRVEXsglwGfSqByTyQAZFrsjtvQ9kJYbquKROg1hJXR/cOIZSWjVm 3w6magxolPpaAS3/SnbKdiBPK7hJVdrNLVESFmZzl245I/GRXxeffQIC9vbXPwzRP/8kPE WDazKRefD6nTsAjq/RRwZIMXvfx8BjfdR+fMYx9ds+AY6fSwjsnMuYjmik8jbMgkODYWg8 Dra3cxZWUzo7DTROgJg9eqz4gCKc/KzQrShtN6Xf6OXBvEB5nMwpu8faOe+3mA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean On Mon, Apr 4, 2022 at 12:59 AM Heinrich Schuchardt wrote: > > Am 4. April 2022 07:40:16 MESZ schrieb Kyle Evans : > >On Mon, Apr 4, 2022 at 12:09 AM Heinrich Schuchardt wrote: > >> > >> Am 3. April 2022 23:08:33 MESZ schrieb Kyle Evans : > >> > On Tue, Jan 12, 2021 at 1:59 PM Heinrich Schuchardt wrote: > >> >> > >> >> Up to now the bootefi command used the last file loaded to determine the > >> >> boot partition. This has led to errors when the fdt had been loaded from > >> >> another partition after the EFI binary. > >> >> > >> >> Before setting the boot device from a loaded file check if it is a PE-COFF > >> >> image or a FIT image. > >> >> > >> >> For a PE-COFF image remember address and size, boot device and path. > >> >> > >> >> For a FIT image remember boot device and path. > >> >> > >> >> If the PE-COFF image is overwritten by loading another file, forget it. > >> >> > >> >> Do not allow to start an image via bootefi which is not the last loaded > >> >> PE-COFF image. > >> >> > >> > > >> >Hi, > >> > > >> >I'm only a little late on this, but may I ask what the rationale of > >> >this last part is? I'm afraid there are some real-world use cases > >> >where a compromise would be great, allowing bootefi to accept a random > >> >region of memory to boot -- in my case, I have the payload (FreeBSD's > >> >loader.efi) already in memory when U-Boot starts and it's unclear that > >> > >> Could you, please, describe your use case in some more detail. > >> > >> Why can't you load loader.efi from the ESP? > >> > > > >I'm explicitly trying to override the loader.efi from ESP, because > >it's broken and I can't (easily) keep switching it out. This is on > >Apple's M1, so I can happily inject the new loader.efi from m1n1 (much > >like the JTAG use-case mentioned in this file) for testing new > >iterations. > > You could use the loady command to load the EFI binary via the UART. This should work with an unpatched U-Boot v2022.04-rc5. > Indeed, thanks! It's a bit less convenient than being able to script this from the beginning, but it's a lot better than having to distribute a patched u-boot to folks working on this with me. > > > >> >I can come up with some other way to boot it that doesn't involve a > >> >lot of backflips. > >> >My specific suggestion, which I can formally post to the list if you > >> >don't immediately object, is this: > >> >https://people.freebsd.org/~kevans/uboot.patch > >> > > >> >It basically adds another form: > >> > > >> >`bootefi addr [fdt [size]]` > >> > >> What should size be used for? > >> Both EFI binaries and device-trees provide their size in a header field. > >> > > Please, send your patch for review to the mailing list and me. > Will do- I considered dropping the size or adding a subcommand that does this instead and reading the size from the header, but I think it's grown on me as a cheap/easy way to extend the base bootefi without adding the footgun of a previously invalid command suddenly doing the wrong thing. If you just plopped it into memory, knowing the size should be an easy task