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 243D5C433F5 for ; Fri, 11 Mar 2022 22:43:47 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id EB3B883868; Fri, 11 Mar 2022 23:43:44 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=web.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=web.de header.i=@web.de header.b="WPIn2S/f"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 393968390E; Fri, 11 Mar 2022 23:43:42 +0100 (CET) Received: from mout.web.de (mout.web.de [212.227.17.11]) (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 097D9837EF for ; Fri, 11 Mar 2022 23:43:38 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=web.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=smoch@web.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1647038609; bh=M4SJc2KOnAFR3nnrrfD0B6Lrl72AGmeKaZOCGcAlyt4=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=WPIn2S/fvqe4LBK9lC4aXpdP/Q4WxS+II69eFxII3xlVsjfV8Qz2dPvLfu4Oup0ji h3WeuqxTdCSVyxrtC0DWCXzXxaCTvzbGZ2IMG2uW8JWP17s99LXSD+3BNH3jx/napD 6T0cFl9H/GImGaVLg/af2QuNPkAJ+IO/yM6Vpo4w= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [192.168.1.27] ([78.54.3.36]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M2xvy-1nRiaT2adQ-003IiC; Fri, 11 Mar 2022 23:43:29 +0100 Message-ID: Date: Fri, 11 Mar 2022 23:43:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Content-Language: en-GB To: Simon Glass , Tom Rini Cc: AKASHI Takahiro , Masami Hiramatsu , U-Boot Mailing List , Lukasz Majewski , Peng Fan , Bin Meng , Jaehoon Chung , Stefan Roese , Ilias Apalodimas , Heinrich Schuchardt References: <20220308113657.221101-1-takahiro.akashi@linaro.org> <82d88a69-159a-257d-2fcb-b6226bff6fe4@gmx.de> <6465499b-8c7b-daea-1729-628ed9252eea@web.de> <20220309001314.GQ5020@bill-the-cat> <20220309030035.GR5020@bill-the-cat> <20220309142550.GS5020@bill-the-cat> From: Soeren Moch In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:WOLum76MSk/x07PJ4KFaJNP6UiHPjas+5U/0AvqSmLwlibL1esd o2l35js5xeilP+VBESVuZXZOTHo4R8NkJFI6PGIDt3FoYTHENF4IYDyFnnqASNkDKAzyMnT IxCpUxoFrOkB4oLDe50ROSsTyvsUSUyUb0JNfVht53LjVpDmJsged4iPQaADCWXQJ+6fD8B khgszUSdJ3owSiCY6XXJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:6Qg/TQD9cI0=:tMvJk9YpREpLZwMsOwJNSw PNi/IWlYH363rgF70Xifoq5kCNl655L8PO/IWEObXk5X9xGKG52q6udv6qqINEg2kvoV4em1y uHJ7U22WSns7sUDOPD7iBrsXzWJ6DRprABzBau1xGuOqK5WcNjws/QavB15kk2kKn1LKGhScu xOVpop1/KJJqigwrHU9oUIX0xdwJ/lhVxa2f/WyNYtQlByhCA5JdrQw6+2YD7qSAfMzT/SX97 tYN93fLhiFUOUHJdjP6Bbsed6CK6JoXnGwCvilNe5arInR3EH/D+mR9y7GWIk/h05Pwfu5dF2 TYQe4fe6Jp33zY88qDpBohO5P4yYXqGwiG37Z/1qMCR+xAmvIglmaPq6/VqYfzL6TaKvOS6TE DMOspCLZq3ouaeyuyVQiG1Frv0QYrNSZcyWVt4tf2pjB3Glb8QvVEZy6z7eh9Y7I3mN/FB72n P1xEWla2CiiXl8Qn4TADVYOMdkQ8ItQf73rCrfymcnfNuiZrOKFtCjbqpwjST/bZ8sSFvkHIm kcmKdb01k3FvuWq9IA5rGg/NfTa97OG1MKr1DytzvT8SRf3Ph5rHEBM45MyGESCuXMoDlTf+/ a+nDxivsPIW5g9BfiOZuvADHcWceG8jrTh18OKX02QsdkEqDIXibsamEcmLMUGRrmkRyXIulc ikN+9Z9Kx62P4wTepaSBDwZqtdHGZZ36PpNjbtpfNqxD+31a2+cP6S8NAfSnKoXO0P0xjH6d6 85v9ON9pi4d2tCPBJXIT5XvgoSffMSF6kzYu2CItHV+6rMrv+iO5XICabPB1obNpy9+nr5h9U qU8THrvRnhKKaY0IUBsv0iQsuD1J0swm4JZzGbeeqQwZ1Z5XWHbQHVNF6C/paKhcuQwuFsfl/ szCpPdLiTMWRhsBDsDeoGBpAttrX9/2r1CPzY8j6YSulHmIoes2ixyAs7fAosg1zUlEX3MZhb /fpqqvStpbp+ZdEup933SIEfv0k1oflIrGxNdjhTbSMxP4nPkjRSipYTftBgM61J2VtlCeuca IKDm3BofT2JjkGvXh7DvPTHzXatDNJKpiYWqUg4n8mOf56N4YLaWU3YYvk+ZPu0NXRwhuFmlq NXw9iwiK9a8ewo= 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 09.03.22 16:33, Simon Glass wrote: > Hi Tom, > > On Wed, 9 Mar 2022 at 07:25, Tom Rini wrote: >> On Tue, Mar 08, 2022 at 08:10:38PM -0700, Simon Glass wrote: >>> Hi Tom, >>> >>> On Tue, 8 Mar 2022 at 20:00, Tom Rini wrote: >>>> On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote: >>>>> Hi Tom, >>>>> >>>>> On Tue, 8 Mar 2022 at 17:13, Tom Rini wrote: >>>>>> On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote: >>>>>>> Hi Soeren, >>>>>>> >>>>>>> On Tue, 8 Mar 2022 at 12:15, Soeren Moch wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08.03.22 17:56, Simon Glass wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote: >>>>>>>>>> On 3/8/22 12:36, AKASHI Takahiro wrote: >>>>>>>>>>> With this patch set[1] applied, UEFI subsystem maintains a lis= t of its >>>>>>>>>>> disk objects dynamically at runtime based on block device's pr= obing. >>>>>>>>>>> (See "issues" below.) >>>>>>>>>>> >>>>>>>>>>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk >>>>>>>>>> This series together with Simon's series breaks multiple boards= due to >>>>>>>>>> size constraints: >>>>>>>>>> >>>>>>>>>> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines= /11197 >>>>>>>>>> >>>>>>>>>> Please, investigate how to work around this issue. >>>>>>>>> tbs2910 - perhaps we should just drop this board? It doesn't use >>>>>>>>> DM_SERIAL and still uses OF_EMBED >>>>>>>> Are we again at the same point? You are breaking working boards w= ith >>>>>>>> (for these boards) useless additions, and all you come up with is >>>>>>>> "remove this board". Of course without adding the board maintaine= r. >>>>>>> I'm just expressing reasonable frustration that this board uses >>>>>>> OF_EMBED and does not use DM_SERIAL, after all of this time. Why >>>>>>> should the rest of the U-Boot developers care more about this boar= d >>>>>>> than the maintainer? I cannot see what is is reasonable here. I care about this board, what you can simply see by the fact that I even picked this thread from the mailing list while you "forgot" to cc me. OF_EMBED and DM_SERIAL are not at all related to EFI or size constraints. I'm surprised that you can speak for "the rest of the U-Boot developers", and that you want to push your frustration onto tbs2910 developers and users. Why is it my fault that other people add code size without guarding config options? Why is it my fault that nobody informed me that there is again a size problem? >>>>>> Please keep in mind Simon that we've had zero releases with the >>>>>> DM_SERIAL migration warning being posted, v2022.04 will be the firs= t >>>>>> one. >>>>> Yes, understood :-) For OF_EMBED though...? >>>> No deadline and 50 boards. >>> Er, there has been a build message about that since the beginning, so >>> people ignored it. Do we really need to make the build fail for these >>> sorts of things? Perhaps so, but it is a sad situation. >> Yes, in hind-sight, "don't do that" wasn't the right path. It would be >> a good idea to start a different thread and see what / how the platform= s >> can be migrated away. For tbs2910 this is just a workaround for a strange property of the imx build system. OF_SEPARATE created a broken u-boot.imx when I tried last time. > I think there is a use case for it now - e.g. booting Apple M1 which > uses a separate bootloader. IMO a .img or .fit file would be better in > some cases but people seem to be allergic to implementing U-Boot > things in their code bases. We have the same requirement for the EFI > app since UEFI does not implement the U-Boot .img file. > > So if we are going to support this, perhaps we should create a new > option for it. But honestly I am just too weary to consider yet > another migration. We need to finish some, e.g. Kconfig. > >>>>> It was actually quite hard to add a migration message until we added >>>>> the CONFIG_SERIAL base thing and that was a pain to do. >>>>> >>>>> For those of us who take on larger refactors etc., we end up spendin= g >>>>> a lot of our time on these few platforms. I'm not picking on tbs2910= in >>>>> in particular. >>>> Well, the flip side of the problem here is that there's a number of >>>> platforms with real constraints to them and it keeps being "can we dr= op >>>> this yet?" without CC'ing the board maintainer on the series that onc= e >>>> again pushes a given platform to the limit. I would expect no size >>>> growth to tbs2910 for the topic of this series since it disables >>>> EFI_LOADER entirely, so why is it a problem? >>> The partition changes are going to add some size anyway, I expect. I >>> have not actually analysed it though. Perhaps we can just disable a >>> filesystem? OK, you did not even analyse where the problem comes from. But disabling user visible functionality on my board is the natural solution to that? Strange. >> I was a bit too absolutist there, sorry. Yes, a few hundreds of bytes >> here-and-there is probably a non issue. But it shouldn't be kilobytes. >> It really shouldn't push things over the line. >> >> And on the tbs2910 side, Soeren, can you look at enabling LTO for this >> platform? That would likely buy a good bit of space savings. That >> might well be needed to do further DM migrations/etc. I'm not familiar with LTO in U-Boot, but will have a look at the weekend. Regards, Soeren > Regards, > Simon