From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 22 Jul 2019 09:36:38 -0400 Subject: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches() In-Reply-To: References: <20190719182545.15662-1-xypron.glpk@gmx.de> <50513fe3-91c6-437a-6d44-d95bfe719cb7@gmx.de> <88ccd476-ab70-178f-5e50-f503435ba379@gmx.de> Message-ID: <20190722133638.GC20116@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sun, Jul 21, 2019 at 10:46:24AM +0100, Peter Robinson wrote: > > >>> On Fri, Jul 19, 2019 at 7:28 PM Heinrich Schuchardt wrote: > > >>>> > > >>>> In GRUB before 2.04 a bug existed which did not allow booting some ARM32 > > >>>> boards if U-Boot did not disable caches, cf. > > >>>> https://lists.linaro.org/pipermail/cross-distro/2019-July/000933.html > > >>>> > > >>>> In ExitBootServices() we were disabling the caches by calling > > >>>> cleanup_before_linux(). This workaround is not needed anymore. > > >>> > > >>> Do we want to remove this straight away? A lot of distributions will > > >>> take time to move to grub 2.04 because it's been a long time between > > >>> grub releases so they'll have quite a patch delta to re-align to the > > >>> new release. Fedora for example will rebase to grub 2.04 in Fedora 32 > > >>> which will start development end of August but won't be released until > > >>> next year. > > >> > > >> As described below this code does not remove any functionality that was > > >> active in U-Boot v2019.04 or v2019.07. > > >> > > >> I can see nothing in https://fedoraproject.org/wiki/Updates_Policy > > >> stopping GRUB 2.04 from being made available for stable Fedora releases. > > > > > > The maintainers believe that it's too intrusive to land now and they > > > want maximum testing time before it gets to stable users, funnily > > > enough people don't like it when their machines cease to boot. > > > > Why should anybody's machines cease to boot? > > > > If Fedora does not role out a new U-Boot they are fine. If Fedora roles > > out a new U-Boot they should role out a matching GRUB and they are fine too. > > > > The venturous who build their own U-Boot should know how to role back > > their system if needed. > > You've clearly never maintained a distribution across 1000s of device > types and 100s of thousands of users. > > We will be shipping Fedora 31 with U-Boot 2019.10 and the current > version of grub that the maintainers wish to support, if that requires > me to revert a number of your changes I will, which will be an > inconvenience and probably take more time than I have spare but I will > survive. I find it strange you fix one OS only to break another. How > will this work for users that want to boot a newly released device > which has recently added U-Boot support to an already released stable > OS? > > If you wish to actively break currently working use cases that's your > prerogative that is your choice but I find breaking currently working > use cases without a reasonable window to migrate dependencies actively > hostile which has tended to not be the way U-Boot has worked in the > past for such things as DM, so breaking a interface to the way OSes > boot IMO is even worse. OK, we have a problem here. A better example than DM would be the various work-arounds we have (or carried for ages) to allow using newer U-Boot with various old and broken kernels. So no, we need to keep this work-around for a long while. What's the EOL date for any Linux distribution that uses this broken grub? The first U-Boot release post that EOL date is when we can drop this particular bit of work-around code. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: