[U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()

[Heinrich Schuchardt]

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 <xypron.glpk at 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".

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.
>