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 > >>>>>><xypron.g...@gmx.de> 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". 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. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
