Rate of innovation in the project (Was: Re: Rate of change in the project)

Wed Apr 2 11:32:08 CEST 2025

On mar., avril 01, 2025 at 11:18, Tom Rini <trini at konsulko.com> wrote:

> On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
>> Hi Tom,
>> 
>> On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini at konsulko.com> wrote:
>> >
>> > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
>> > > Hi Tom,
>> > >
>> > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini at konsulko.com> wrote:
>> > > >
>> > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
>> > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
>> > > > [snip]
>> > > > > > Again, back to this thread, if you want me to migrate things, consider
>> > > > > > applying the sunxi patches as I have described above. I will then look
>> > > > > > at the next target for bootstd. But while you hold this up, I cannot
>> > > > > > move forward with more bootstd migration. It doesn't seem that much to
>> > > > > > ask.
>> > > > >
>> > > > > I will take another look at what's still relevant. But I believe it's
>> > > > > still blocked on the fact that it changes behavior and breaks users.
>> > > >
>> > > > In details:
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
>> > > >
>> > > > Now that the underlying BLK problem is resolved, this can just be
>> > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
>> > > > when you're supporting a flow that lacks a BLK device entirely. This
>> > > > would be another reminder as to why putting unrelated changes in a
>> > > > series is a problem.
>> > >
>> > > OK, then just don't apply this patch. Problem solved?
>> >
>> > Well, for a hypothetical v6 you would not include it, sure.
>> >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
>> > > >
>> > > > This is fine.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
>> > > >
>> > > > This is not fine. This is also not a sunxi problem. It means that we
>> > > > should drop bootmgr from rockchip, where the conversion has already
>> > > > taken place, and would need to drop it from future conversion too.
>> > > > Neither of which are desirable changes.
>> > >
>> > > Why do you say that? I don't understand how this relates to rockchip
>> > > or why we would need to drop bootmgr from that.
>> >
>> > Then you don't have enough of a grasp of the details of the area you're
>> > trying to solve problems in? Or maybe you need to refresh yourself on
>> > the details of the area you're trying to work in.
>> 
>> Or perhaps there isn't a problem? The sunxi case is special because we
>> have a FEL boothmeth. That isn't present on rockchip, for example.
>
> Again, you seem to have forgotten what the problems with the series
> were.
>
>> > > > This patch in particular is
>> > > > where we have the note:
>> > > >
>> > > > "Yes, the introduction of boot standard changed the boot order and
>> > > > specifically deprioritizing scripts is unexpected."
>> > > >
>> > > > Which should have had more attention than it did.
>> > >
>> > > From memory the scripts are a fallback used when the other things
>> > > don't work, so that was the decision I made at the time.
>> >
>> > The key point being we changed behavior that others depended on, and
>> > didn't document it well and didn't make sure the change would work for
>> > them either.
>> >
>> > > > This is the thread that to me spelled out in details where the
>> > > > conversions are now blocked. We changed behavior and that in turn breaks
>> > > > users that have come to rely on ordering.
>> > >
>> > > I don't know what action to take on that comment. We cannot have 100%
>> > > backwards compatibility with the scripts, which after all weren't even
>> > > documented. But it is very close.
>> >
>> > You need to get feedback from the people you want to migrate from the
>> > scripts and ordering and rely on to something else and see what works
>> > for them.
>> >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
>> > > >
>> > > > Is an alternative to the above which then turned in to a discussion that
>> > > > I would very briefly summarize as "no discussions were had between
>> > > > stakeholders before integrating efi bootmgr with bootstd".
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
>> > > >
>> > > > This is fine, but only relevant once migration happens.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
>> > > >
>> > > > If Andre is fine with this, this is fine.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
>> > > >
>> > > > This is a generic bugfix. I will take this to next today.
>> > > >
>> > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
>> > > >
>> > > > If Andre is fine with this, this is fine.
>> > >
>> > > Well, is he? I thought he was. Can you check?
>> >
>> > You're free to. It's one of the innumerable examples of why when you
>> > group multiple things in a series and there's problems with another part
>> > of the series, unrelated changes get dropped.
>> 
>> It would be easier for me if you could apply the patches as I've suggested.
>> 
>> But if you are willing to apply these patches and just want me to send
>> the series again without the BLK and RFC patches, I can do that.
>> Please let me know either way.
>
> Again, you should:
> - Take the non-bootstd sunxi enhancements, rebase them to next and post
>   for Andre. By themselves. This way they won't get stuck.
> - You should work with Heinrich to come up with something that handles
>   efi bootmanager and bootstd without breaking how our actual project
>   users use us.
>   There's no reason to migrate *more* platforms until we have this
>   fundamental problem sorted out.
> - You should work with any FOSS distributions to get their feedback on
>   what would make their life easier, from a user of U-Boot perspective.
>   bootstd won't be useful if it's not something our users want to use.

I can't speak for other distributions but for Android, it seems that the
direction is to use EFI boot via an excutable that implements the Android
bootflow. This is named GBL, and here are some pointers about it:
- https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/main/gbl/README.md
- https://lpc.events/event/18/contributions/1704/attachments/1550/3231/Android%20Generic%20Boot%20Loader.pdf
- https://baylibre.com/android-bootflow-experiments-with-u-boot-and-gbl/

So in my opinion, at least for Android, bootmeth_android (bootstd) will
be deprecated in favor of EFI boot + GBL.

>
> -- 
> Tom