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 22921C433F5 for ; Mon, 14 Mar 2022 13:05:18 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C307D83BC0; Mon, 14 Mar 2022 14:05:16 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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="osUU0FKp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8616883BDE; Mon, 14 Mar 2022 14:05:14 +0100 (CET) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 AEB5E839A0 for ; Mon, 14 Mar 2022 14:05:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x829.google.com with SMTP id t7so2427865qta.10 for ; Mon, 14 Mar 2022 06:05:05 -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=tDVZU9c5OgncQOL3xzSJ4DLRcVWztuRGjYOQY3cLY1A=; b=osUU0FKpeaEsCj7df0h6qXfN/nF+VnkF/WfxY5LAwyv+ExZtXK6UeMWCb1dnhqnYl3 iWhCjXqRVuL1vuRtHrdDWzhwV4vBl7Akk+5LfSmeJ+oBRaBfp41af3LvszzI3ZLEQ7FS pu0JoclK0Ih5y27RnDBdogAVHAD5/6uFD/P8E= 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=tDVZU9c5OgncQOL3xzSJ4DLRcVWztuRGjYOQY3cLY1A=; b=p2fuefREJ34DgDBa/6YBObvoBgtIDi6M7qhEQK3uA9M/fZ+WkHKFaC++KYk8i3rfNp MbhyoCcPMviultlkDvVThsgijqLgSt7fKxwTe/t+rkCmyAZbdjVgtihYYNwT3ljz9jMw hU+6iQArFVV743NXEE7Oeg3Bdbv3P4tN4ksHbF4hVWMglv8X9368DsCKgqhMIKseI0xJ CTp6YsZB8lo+g1gfiElkq5m5cP2wmTssgUhqd93YhYF+olRAXtpsm4kp0jCwhOXXzsaO A426j+VU51N7s+KhrwcX2w/9TKOO/uaIy+0Fg70RXDs6ZXvBCXJqjsq1LC9ADwrNcp/k OnQQ== X-Gm-Message-State: AOAM531mUudPylhH+j1qOnPG0NW8CWOniL3+IL6+PvHe2iaBd5z70Ayf wrvb19Bi0OGaXkiwfMZRMRbhyjkKJc25EKpQ X-Google-Smtp-Source: ABdhPJz4djJkvWVv3swS5aFF/l9ElN7GDBR4CFnzgetsa0BYIiLjO6WJLsbHl+vJF5iwdUxe/d+Dig== X-Received: by 2002:ac8:7c4f:0:b0:2e1:a763:da87 with SMTP id o15-20020ac87c4f000000b002e1a763da87mr18168358qtv.478.1647262675860; Mon, 14 Mar 2022 05:57:55 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id t1-20020a05620a0b0100b0067d3ac00982sm7363155qkg.57.2022.03.14.05.57.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 05:57:54 -0700 (PDT) Date: Mon, 14 Mar 2022 08:57:53 -0400 From: Tom Rini To: Soeren Moch Cc: Simon Glass , AKASHI Takahiro , Masami Hiramatsu , U-Boot Mailing List , Lukasz Majewski , Peng Fan , Bin Meng , Jaehoon Chung , Stefan Roese , Ilias Apalodimas , Heinrich Schuchardt Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model Message-ID: <20220314125753.GG9986@bill-the-cat> References: <20220309001314.GQ5020@bill-the-cat> <20220309030035.GR5020@bill-the-cat> <20220309142550.GS5020@bill-the-cat> <7cc062d7-0426-9ca3-482a-720e7b168d5e@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TU+u6i6jrDPzmlWF" Content-Disposition: inline In-Reply-To: <7cc062d7-0426-9ca3-482a-720e7b168d5e@web.de> X-Clacks-Overhead: GNU Terry Pratchett 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 --TU+u6i6jrDPzmlWF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2022 at 09:27:40AM +0100, Soeren Moch wrote: > Hi Simon, >=20 > On 12.03.22 06:02, Simon Glass wrote: > > Hi Soeren, > >=20 > > On Fri, 11 Mar 2022 at 15:43, Soeren Moch wrote: > >=20 > >=20 > >=20 > > On 09.03.22 16:33, Simon Glass wrote: > > > > Hi Tom, > > > >=20 > > > > 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, > > > > > >=20 > > > > > > On Tue, 8 Mar 2022 at 20:00, Tom Rini wrot= e: > > > > > > > On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > >=20 > > > > > > > > On Tue, 8 Mar 2022 at 17:13, Tom Rini = wrote: > > > > > > > > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wro= te: > > > > > > > > > > Hi Soeren, > > > > > > > > > >=20 > > > > > > > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch = wrote: > > > > > > > > > > >=20 > > > > > > > > > > > On 08.03.22 17:56, Simon Glass wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > >=20 > > > > > > > > > > > > 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 list of its > > > > > > > > > > > > > > disk objects dynamically at runtime based on bl= ock device's probing. > > > > > > > > > > > > > > (See "issues" below.) > > > > > > > > > > > > > >=20 > > > > > > > > > > > > > > [1]https://github.com/t-akashi/u-boot/tree/efi/= dm_disk > > > > > > > > > > > > > This series together with Simon's series breaks m= ultiple boards due to > > > > > > > > > > > > > size constraints: > > > > > > > > > > > > >=20 > > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-e= fi/-/pipelines/11197 > > > > > > > > > > > > >=20 > > > > > > > > > > > > > Please, investigate how to work around this issue. > > > > > > > > > > > > tbs2910 - perhaps we should just drop this board? I= t doesn't use > > > > > > > > > > > > DM_SERIAL and still uses OF_EMBED > > > > > > > > > > > Are we again at the same point? You are breaking work= ing boards with > > > > > > > > > > > (for these boards) useless additions, and all you com= e up with is > > > > > > > > > > > "remove this board". Of course without adding the boa= rd maintainer. > > > > > > > > > > I'm just expressing reasonable frustration that this bo= ard 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 abou= t this board > > > > > > > > > > than the maintainer? > > > I cannot see what is is reasonable here. > > >=20 > > > I care about this board, what you can simply see by the fact that I e= ven > > > picked this thread from the mailing list while you "forgot" to cc me. > > This is the patch I sent: > >=20 > > [PATCH 2/5] tbs2910: Disable ext4 write > >=20 > > It shows that you are on cc. What are you referring to? > I'm referring to the exact same email thread that I answered in, which > btw. is still this exact same thread for this answer. Why should I refer > to the totally different email thread you cited here? > > > OF_EMBED and DM_SERIAL are not at all related to EFI or size constrai= nts. > > >=20 > > > 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 s= ize > > > without guarding config options? Why is it my fault that nobody infor= med > > > me that there is again a size problem? > > Your board is up against the limit and this causes problems. Please > > take a look and see how you can add some margin. Takahiro's series > > does add size and this is unavoidable. See my series of today for some > > fixes for the SPL size, but for U-Boot proper we have to accept the > > growth. > As it stands here this is just your opinion. Why exactly is this > unavoidable? > >=20 > > > > > > > > > Please keep in mind Simon that we've had zero releases wi= th the > > > > > > > > > DM_SERIAL migration warning being posted, v2022.04 will b= e the first > > > > > > > > > one. > > > > > > > > Yes, understood :-) For OF_EMBED though...? > > > > > > > No deadline and 50 boards. > > > > > > Er, there has been a build message about that since the beginni= ng, 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 wo= uld be > > > > > a good idea to start a different thread and see what / how the pl= atforms > > > > > can be migrated away. > > > For tbs2910 this is just a workaround for a strange property of the i= mx > > > build system. OF_SEPARATE created a broken u-boot.imx when I tried la= st > > > time. > > OK, that is worth digging in to. > Probably. I'm happy to test whatever someone comes up with. > >=20 > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > For those of us who take on larger refactors etc., we end u= p spending > > > > > > > > a lot of our time on these few platforms. I'm not picking o= n tbs2910in > > > > > > > > in particular. > > > > > > > Well, the flip side of the problem here is that there's a num= ber of > > > > > > > platforms with real constraints to them and it keeps being "c= an we drop > > > > > > > this yet?" without CC'ing the board maintainer on the series = that once > > > > > > > again pushes a given platform to the limit. I would expect n= o size > > > > > > > growth to tbs2910 for the topic of this series since it disab= les > > > > > > > EFI_LOADER entirely, so why is it a problem? > > > > > > The partition changes are going to add some size anyway, I expe= ct. I > > > > > > have not actually analysed it though. Perhaps we can just disab= le a > > > > > > filesystem? > > > OK, you did not even analyse where the problem comes from. But disabl= ing > > > user visible functionality on my board is the natural solution to tha= t? > > > Strange. > > As above, please create some space so people can continue to develop. > > There are refactors and features updates which require more code > > space. It is somewhat rare, but it happens perhaps every year. > It has always been u-boot policy that additional new features should not > break existing boards, usually by disabling these new features in defconf= ig. > It is also not new that there are boards with size constraints. >=20 > If someone causes regressions, then I at least expect that this is > thoroughly analysed. > > > > > 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 kilo= bytes. > > > > > It really shouldn't push things over the line. > > > > >=20 > > > > > 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. Th= at > > > > > 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 week= end. > > OK, I suggest getting it several KB under the limit if you can, or > > perhaps even drop the limit. > I already reduced tbs2910 image size several times by substantial > amounts. And this is becoming more and more difficult. The size limit is > real. >=20 > Thanks Tom for the LTO suggestion, this will buy us another round/./ I > sent a patch for that. >=20 > But please, everyone, be careful with additional code size for existing > boards. Additional code size is not unavoidable for disabled new > features. You just did not try hard enough. I just want to emphasize the last point here. We need to make sure we're making platforms better, not just bigger. And to preempt "EFI keeps growing", yes, in reasonably small amounts, implementing a spec (or fixing bugs against a spec) that the semi vendor is telling everyone to make sure their hardware is compliant with. And I check all of the growth for everyone, all of the time, for everything. --=20 Tom --TU+u6i6jrDPzmlWF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmIvO9AACgkQFHw5/5Y0 tyx3vgv/Rpu3uGp9Oi5wf42sEK3Nm0jXdBvg3jGqjrxFe7iDSIWvzOb73yLWypQu 2dCArNTvv/NbduBA5za6Rmcz+puWdv8XEs32GgEl7l+cmyYJ+gDm7tnOEvvAbm8g q8AdR/de5+0btZb4nvfOc47R5zkpLkpDzOriK7kNNwEFmL1x5L6v163hJ5RhcsIU p670LnBHjZFNHDystLGG4kSUDpiAcOKcw2DUsUhnJZzjqtlaYyTpRJXmftcpx/B6 fNt9UJ06lF9W/o5gQMXR1KVDRfASXFXGlgmRFSj8AzakDXtfdKOR0ADACNbyOR3u iDsnJVu+dDP3Bhv0a1EoOitqflz2ICt0r7RKvR7eax3RrW4ydfx3029xhTBBENbv MPzDktL6ROXi/t35tR9VUKA+5PAx/nUZ3bybc84yTC3x9ugSUKd4gjj9sAwwOs7U UM/2an7WvtdAb6llgJxlknfuf+KiCpZDpe6tKNEVehSFjw2WyPiFaanJka8Fm6cz xP8PuN0J =JHzS -----END PGP SIGNATURE----- --TU+u6i6jrDPzmlWF--