El 22/7/19 a las 12:15, Peter Robinson escribió:
On Mon, Jul 22, 2019 at 2:36 PM Tom Rini <tr...@konsulko.com> 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.
Well Fedora 31 would be EOL around Nov/Dec 2020, and while I know the
CentOS team uses the Fedora U-Boot but I believe they boot their
arm-32 instances with extlinux to date. I can't speak for any of the
other distros in this regard.
Well, that is true for CentOS7, but for CentOS8 the plan is to boot
using EFI also.
Peter
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Pablo.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
