Hi Tom, On Mon, 10 Mar 2025 at 09:53, Tom Rini <tr...@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-...@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? > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-...@chromium.org/ > > This is fine. > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-...@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. > 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. > > 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. > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-...@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-...@chromium.org/ > > This is fine, but only relevant once migration happens. > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-...@chromium.org/ > > If Andre is fine with this, this is fine. > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-...@chromium.org/ > > This is a generic bugfix. I will take this to next today. > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-...@chromium.org/ > > If Andre is fine with this, this is fine. Well, is he? I thought he was. Can you check? Regards, Simon
