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 <tr...@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 <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? > > > > Well, for a hypothetical v6 you would not include it, sure. > > > > > > 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. > > > > 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-...@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? > > > > 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. -- Tom
signature.asc
Description: PGP signature
