From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Mon, 22 Jul 2019 21:07:40 +0200 Subject: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches() In-Reply-To: <20190722190238.GF20116@bill-the-cat> References: <20190719182545.15662-1-xypron.glpk@gmx.de> <50513fe3-91c6-437a-6d44-d95bfe719cb7@gmx.de> <88ccd476-ab70-178f-5e50-f503435ba379@gmx.de> <20190722133638.GC20116@bill-the-cat> <4312609b-7175-64f8-1c74-8061a6392ea3@gmx.de> <20190722190238.GF20116@bill-the-cat> Message-ID: <3648110a-5c3c-ec4b-8259-1c93b1339424@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 7/22/19 9:02 PM, Tom Rini wrote: > On Mon, Jul 22, 2019 at 08:51:41PM +0200, Heinrich Schuchardt wrote: >> On 7/22/19 3:36 PM, Tom Rini wrote: >>> 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. >> >> The current behavior contradicts the UEFI spec. Our target is to >> implement a UEFI compliant firmware. > > Our target is to be both compliant and functional, and functional wins. > >> If OpenBSD does not change their broken boot loader will we never >> correct U-Boot? That would not make sense to me. > > I'm sorry, I don't see the connection. It's not "GRUB won't change to > be compliant" it's "GRUB changed things but it's going to take a long > while for that to be deployed out". > >> Old distros tend not to to update their U-Boot release. E.g. Debian >> Stretch is still on U-Boot v2016.11. So why would you care about its EOL? > > Because I want to make it really hard for people to end up in a "does > not boot now" mode. > >> I could agree if you suggested that we should re-enable the workaround >> until the major distros use a compatible GRUB in their stable release >> like Debian Buster does. >> >> Let's be proactive and analyze if anything is missing in Fedora Rawhide >> GRUB. If yes, we should contact the maintainer and clarify which >> adjustments are possible until the Fedora 31 release. > > I don't want it to be "just latest stable has it". I want it to be > "supported releases have it". RHEL distros are supported for 10 years. Are you serious? Best regards Heinrich > > Why? It's the user-friendly behavior. You will find people that > upgrade their U-Boot because they're trying something but still have an > older distro. Or people that are bringing up a new board and testing it > out with an older distro. >