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 04F9DC433F5 for ; Mon, 4 Apr 2022 05:59:36 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1382283B25; Mon, 4 Apr 2022 07:59:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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; secure) header.d=gmx.net header.i=@gmx.net header.b="jIXk+39j"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7095683AEF; Mon, 4 Apr 2022 07:59:22 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 1D8B283AEF for ; Mon, 4 Apr 2022 07:58:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1649051888; bh=o7KtVwxRhHY9rLlOitHVmSDXl9DugI+enIYk26WFKpk=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=jIXk+39jUvvE13HemN8HUAc5MopEYT1/katMYb4RsDsJ2Xf6ux7o6xWRcZzqgZd2s NEbvRfCavgNk+DTnNy5lJuZc5gZH7gqt2ZVT76Mu8+tsWt0B13suJVvNA3J1RVkRKU HzmukgyN1euTce9zu5Jdk13Kvh/wAxXPW1jticV0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([88.152.144.107]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M3UUy-1nahlK0tXe-000buO; Mon, 04 Apr 2022 07:58:08 +0200 Date: Mon, 04 Apr 2022 07:58:10 +0200 From: Heinrich Schuchardt To: Kyle Evans CC: Alexander Graf , Joe Hershberger , Simon Glass , Joao Marcos Costa , Richard Genoud , Niel Fourie , u-boot@lists.denx.de Subject: Re: [PATCH 3/3] efi_loader: setting boot device User-Agent: K-9 Mail for Android In-Reply-To: References: <20210112195842.252946-1-xypron.glpk@gmx.de> <20210112195842.252946-4-xypron.glpk@gmx.de> <7304AC06-9D2D-4F24-8066-F9CF854F7334@gmx.de> Message-ID: <9491CEF0-F9F2-4DED-833D-3DE3F2670B53@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Z9rsv5d22a3j3oftxMuqGELpcnNfY0jGqAi8A5Sfwi4MWF8s0OV Jghwc2penaqRyz9Gqt2BY3Tb39G2WMttGsIPfQU7xNQoYk7njZ/CbJoBzzDe9vv5vGqIUdC gpYBhST0hvZNWgtnNwwmaxPLun94aUeCR2JDLZlClpFhYPJiLAvvCRfQ03peXReixpkqjrR DiJuOYNkdRE3c27rHCj0w== X-UI-Out-Filterresults: notjunk:1;V03:K0:10b7w97UgdE=:+xt4iyR+8+aoP+xwSlMXTd wgrmmsmDG9DVnt6cnX9B4Zqeix/HiLimTTOdOd2Ydv5rngT/AkRJrRJvHNBZZ+escNybk0E72 nby1+pQ6x7rKbrZhHWWtrrChsaDYh7oYW1DR/l3K/z1LHo0+pqxoHVORh9YhE/6EtY6YcW639 4H4WSdg4Z4/9AtOfwVpBpuSxlc1XgjYpEHGgfIsv/6lD5ktE7nwTPuKAN7zQIbcQXmYWu5ZZn cm+yE7S6adrOBMd26Qx0c3wfAmCtdMprqWb303kbduwpXlKLCcn862DhrcrNNu7EniCaN/xAP Q8tQIlUiNHZD3CXqYulTPI/m6qQkFcJH1SpQyHIhnUoRlLwUdL3Da4VM/i5RO7XvZyqg/uuLz RxjrVssngeeJOVXUGdWFL7aQmVp9vfI3ZaOEvk8mojFNzpPRw7DH/gsrRO8aZMjsf/pSerrWN vDxYPWf6ZsgwiNtuZO63XYomEnc2FAKuINaXuyh2z/y0YGL36JzOg5oB0BcU0lnsVS5ql2/iI fZ6+gKkK7+i6v4L1V6LmL1ax0ZiMFWTFocLpstcqUFIXpAXD/iO9iHfIc7+ZnzUDMlU17/9XB NWS5O4LKb5fsDid7M1c6nSQPKhaxWRmY2l4CYKk3hjdssDkIw0BK5o4Tu/HXlVhyOqobZLEmM rqchApL4v7oJwiwtBIfLPC7+gb1//txmLfnmSBcfoXcO27IZjLTosDU1+rny8Eyqx/xWguKo8 x2hk3obCQWR/CWJi965uGlnl4OsRlWxb1tQIy27ap+EBEWu0qldrwdxfmi6lQwreKlCza1UYa k20Jj/pMw89bZcLQlG/qbly3OPDY9f1bZ+N7ogTs5wxcJT6C3Dp44upOUa8yp6oAFSl2DaTxT np6a/er1SlJiKBHbd+rdA1ltEK37bOttawnjPmsZwf/q9ytiq1PigP/5AzBaVsWAPFzMAVm6f z55TszdG7pHoVR2Upb+xCAPHIZclBVDZFsRpyZfHN4WawUls0VwS/ut2JmlC3lBKhOz8oruoV sBiuuXdO2RoWWS6XJD1xtxUc+IKZcUcd1vKhNMVGY60Gmbq79dH3d/3dc5V9gKda06L73wzwC 0qpHApiWbszLGk= 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 Am 4=2E April 2022 07:40:16 MESZ schrieb Kyle Evans : >On Mon, Apr 4, 2022 at 12:09 AM Heinrich Schuchardt wrote: >> >> Am 3=2E 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=2E This has led to errors when the fdt had been loade= d from >> >> another partition after the EFI binary=2E >> >> >> >> Before setting the boot device from a loaded file check if it is a P= E-COFF >> >> image or a FIT image=2E >> >> >> >> For a PE-COFF image remember address and size, boot device and path= =2E >> >> >> >> For a FIT image remember boot device and path=2E >> >> >> >> If the PE-COFF image is overwritten by loading another file, forget = it=2E >> >> >> >> Do not allow to start an image via bootefi which is not the last loa= ded >> >> PE-COFF image=2E >> >> >> > >> >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=2Eefi) already in memory when U-Boot starts and it's unclear th= at >> >> Could you, please, describe your use case in some more detail=2E >> >> Why can't you load loader=2Eefi from the ESP? >> > >I'm explicitly trying to override the loader=2Eefi from ESP, because >it's broken and I can't (easily) keep switching it out=2E This is on >Apple's M1, so I can happily inject the new loader=2Eefi from m1n1 (much >like the JTAG use-case mentioned in this file) for testing new >iterations=2E You could use the loady command to load the EFI binary via the UART=2E Thi= s should work with an unpatched U-Boot v2022=2E04-rc5=2E > >> >I can come up with some other way to boot it that doesn't involve a >> >lot of backflips=2E >> >My specific suggestion, which I can formally post to the list if you >> >don't immediately object, is this: >> >https://people=2Efreebsd=2Eorg/~kevans/uboot=2Epatch >> > >> >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= =2E >> Please, send your patch for review to the mailing list and me=2E Best regards Heinrich > >Right now it's used because efi_run_image() wants the buffer size to >construct the memory-based device path=2E I'm not familiar enough with >U-Boot to know if there's a sensible API for grabbing the size from >this PE image in memory=2E