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 0DC6CC433EF for ; Tue, 12 Oct 2021 23:40:41 +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 3B1B760E94 for ; Tue, 12 Oct 2021 23:40:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3B1B760E94 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 A378C83513; Wed, 13 Oct 2021 01:40:37 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="tMqMKifH"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4913C834C5; Wed, 13 Oct 2021 01:40:36 +0200 (CEST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 83D72834C5 for ; Wed, 13 Oct 2021 01:40:32 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x830.google.com with SMTP id i1so988738qtr.6 for ; Tue, 12 Oct 2021 16:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KI7xJEdNXrQfqHwlp7IdQdVemm5KDff8EAO1DpPVzfo=; b=tMqMKifHvL9l5/GIS92GmvzehWKg2qYdREbwzrudOxPaGzSVvgtAPcqm9tbg3arRcD 1c1+VtL8vNEMHjxzGriioDt8I8lewctDXfAnv13o5E+5erN5q5XBhftMvm+84rnLpzH0 yzyHupzrBPmFBcczRX7lCcs1aqh0ZJAyriyuo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KI7xJEdNXrQfqHwlp7IdQdVemm5KDff8EAO1DpPVzfo=; b=uH8uDseYbIpAifUr+GIfchNY7/+TcFJMFqrZJJwO0xzTBkMDglQZ+smnDG37jQzqTh k1+NW1Xt+ik8XS4fF3vyclYCDFGo0A12keuY0biGbnmVj5VSSz903bMCvnWmKkvXKrDA iPsAuvt2mS65NjKH5L4yg0VGGEljybEBoUBZZ/jUcMIbWH7FXm6XxSNxKXJ1faHb7X3K 7kNrLwkY0bQTpBPH1WiWpqJmfL48jeGUXlHaw6q0M5HIRyp/eqHwD7Y+qt3CH6EnyfmB 9UfWGv3GcTU17w611bhU2hDSXP5GzDU3fSRuSSwMvzedYUCFM35zEQe7jdjbWpYovnpQ 79Aw== X-Gm-Message-State: AOAM532IFrWNj12Stz3Mr/IpGpjYcTFBG8OCzABhnRPCwkcBQjSeRSSg 5BZLx3ZZPuRyoJBPB4hmz5iTDQ== X-Google-Smtp-Source: ABdhPJxZei4KfiuRwbeVGP9mu/Nr2SkvF5RrKSkUF9Qv5yKsSu6FoorGrBSyFPGYbPUFdOmeAPm9hA== X-Received: by 2002:a05:622a:1741:: with SMTP id l1mr26493508qtk.318.1634082031318; Tue, 12 Oct 2021 16:40:31 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-e98d-c49f-f596-1fb5.res6.spectrum.com. [2603:6081:7b01:cbda:e98d:c49f:f596:1fb5]) by smtp.gmail.com with ESMTPSA id 187sm7080494qkk.2.2021.10.12.16.40.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 16:40:30 -0700 (PDT) Date: Tue, 12 Oct 2021 19:40:28 -0400 From: Tom Rini To: Simon Glass Cc: AKASHI Takahiro , Heinrich Schuchardt , Alex Graf , Ilias Apalodimas , U-Boot Mailing List Subject: Re: [RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model Message-ID: <20211012234028.GI7964@bill-the-cat> References: <20211001050228.55183-1-takahiro.akashi@linaro.org> <20211012150023.GY7964@bill-the-cat> <20211012211343.GH7964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5/WRjDpoVSxzWgzy" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --5/WRjDpoVSxzWgzy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2021 at 05:37:45PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Tue, 12 Oct 2021 at 15:13, Tom Rini wrote: > > > > On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 12 Oct 2021 at 09:00, Tom Rini wrote: > > > > > > > > On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote: > > > > > Hi Takahiro, > > > > > > > > > > On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro > > > > > wrote: > > > > > > > > > > > > The purpose of this RPC is to reignite the discussion about how= UEFI > > > > > > subystem would best be integrated into U-Boot device model. > > > > > > In the past, I poposed a couple of patch series, the latest one= [1], > > > > > > while Heinrich revealed his idea[2], and the approach taken her= e is > > > > > > something between them, with a focus on block device handlings. > > > > > > > > > > > > # The code is a PoC and not well tested yet. > > > > > > > > > > > > Disks in UEFI world: > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > In general in UEFI world, accessing to any device is performed = through > > > > > > a 'protocol' interface which are installed to (or associated wi= th) the device's > > > > > > UEFI handle (or an opaque pointer to UEFI object data). Protoco= ls are > > > > > > implemented by either the UEFI system itself or UEFI drivers. > > > > > > > > > > > > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL = (efi_disk > > > > > > hereafter). Currently, every efi_disk may have one of two origi= ns: > > > > > > a.U-Boot's block devices or related partitions > > > > > > (lib/efi_loader/efi_disk.c) > > > > > > b.UEFI objects which are implemented as a block device by UEFI = drivers. > > > > > > (lib/efi_driver/efi_block_device.c) > > > > > > > > > > > > All the efi_diskss as (a) will be enumelated and created only o= nce at UEFI > > > > > > subsystem initialization (efi_disk_register()), which is trigge= red by > > > > > > first executing one of UEFI-related U-Boot commands, like "boot= efi", > > > > > > "setenv -e" or "efidebug". > > > > > > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_d= esc(->ops) > > > > > > in the corresponding udevice(UCLASS_BLK). > > > > > > > > > > > > On the other hand, efi_disk as (b) will be created each time UE= FI boot > > > > > > services' connect_controller() is executed in UEFI app which, a= s a (device) > > > > > > controller, gives the method to access the device's data, > > > > > > ie. EFI_BLOCK_IO_PROTOCOL. > > > > > > > > > > > > >>> more details >>> > > > > > > Internally, connect_controller() search for UEFI driver that ca= n support > > > > > > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in thi= s case, > > > > > > then calls the driver's 'bind' interface, which eventually inst= alls > > > > > > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object. > > > > > > 'efi_block' driver also create a corresponding udevice(UCLASS_B= LK) for > > > > > > * creating additional partitions efi_disk's, and > > > > > > * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) = on it. > > > > > > <<< <<< > > > > > > > > > > > > Issues: > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > > 1. While an efi_disk represents a device equally for either a w= hole disk > > > > > > or a partition in UEFI world, the device model treats only a= whole > > > > > > disk as a real block device or udevice(UCLASS_BLK). > > > > > > > > > > > > 2. efi_disk holds and makes use of "blk_desc" data even though = blk_desc > > > > > > in plat_data is supposed to be private and not to be accesse= d outside > > > > > > the device model. > > > > > > # This issue, though, exists for all the implmenetation of U= -Boot > > > > > > # file systems as well. > > > > > > > > > > Yes, this was a migration convenience and we should be able to un= pick it now. > > > > > > > > > > However we still have SPL_BLK so need to consider whether we can = drop that. > > > > > > > > To be clear here, in that I can hand-wave my way to seeing a use ca= se > > > > for lib/efi_loader/ under SPL, it would not be in a world where we = also > > > > still would be supporting the non-DM infrastructure, and is also no= t a > > > > near-term goal. > > > > > > OK good. Perhaps we should add a migration method for SPL_BLK? It > > > would be good to know where we are in terms of the size stuff. I don't > > > see a lot of boards rushing to use of-platdata, though. > > > > What do you mean? Since we have platforms that need to support 12 or 16 > > KiB of space for SPL, we're not going to enforce SPL_DM. But those > > platforms can / do need to boot from MMC (SD card I think usually). > > > > In terms of platforms that could, but don't, enable SPL_BLK, that's just > > the platforms that disable SPL_BLK today as it defaults to enabled when > > possible. >=20 > Well I wonder if we can use of-platdata and DM then perhaps some of > these will fit. The OMAP platform I sent patches for was close to > complete, I think, and I believe that was one of the tightest. > Actually I cannot remember what board that was... >=20 > The overhead is perhaps 7KB though, so maybe not suitable for 16KB. It's only disabled on the vboot config, on am335x platforms. Honestly, I would suggest a separate thread and ask the board maintainers in question why specifically it's off. I know for am335x_boneblack_vboot_defconfig it's inadvertent, it could be turned on no problem I suspect. --=20 Tom --5/WRjDpoVSxzWgzy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFmHOYACgkQFHw5/5Y0 tyx57Av9Ehr19ljlTO371cDiMeP9pvPGnaqXpkvOQec1m2xCuc4/Vrl59WCJPAjT z/XMxT9/xh75P5VYlebp+mkPfbC/Z0KaDj2GMp51q1cMc7CNJzKgaRI7qnZZnNtd kVKMauxgdvRg2iGPBgnGNlElQIY6esQfhm3r1YBJTr0a6ob6qwzQretNR8wnJUTM WYIKyghEkjaaMzaTAFv/LWSAxMUy/v2GW8rV+xbLVYOy41Z4I6KKr99XcxjxC7eK ZT+3GMe0bOlAGGW4alZfnX/3F7SFJowCvB1h6g77Ej75EKIAyZ8ERf/GdxJ4cfT9 IF/2R6DstrGW+W0Bi2d2nqX/5cYpsiMHVS/Ff4K8TrnBNhs2OaI3n1Y19PlnZhCd gh9v2tUI6OIFZuXikxiLq3TV0gg9mmIzQSGR6ibyGYaX/7pCBTdStppE5T1DOQ20 9ctyTK9oag0IeEzeF8QKrDvyv08X4or150QJrd00bW93CahNPSEnYEoUWcfritMK 5rUgeY7o =vX6K -----END PGP SIGNATURE----- --5/WRjDpoVSxzWgzy--