Hi Tom, On Fri, 4 Apr 2025 at 03:27, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 3 Apr 2025 at 11:35, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <tr...@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 <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. > > > > > > > > No, it's just that we disagree on the path forward. > > > > > > Then why did you bring up FEL? That's the part of the migration which is > > > NOT a problem, I keep being reminded when I ask. > > > > FEL needs to get priority, that's all. It was a problem until I > > adjusted the priority. > > And there's been zero objection to this. So why are you mentioning it > here, in the discussion on why the migration is blocked. I know I had > been unsure, but I asked, and people answered, and I accepted the > answer. > > > > > > > > > > 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. > > > > > > > > There's no point, though, since it doesn't provide the bootstd > > > > migration. > > > > > > Are you saying there's no point in generally improving things if it > > > doesn't also involve one of your particular projects? > > > > The series is called 'bootstd: sunxi: Migrate to standard boot'. If > > you'd like to apply just the patches from that series which don't > > migrate sunxi to standard boot, please go ahead. > > I'm not the sunxi custodian. General sunxi changes would go through that > tree. And then a repeat of everything I've said about how bundling > unrelated changes hurts everyone. > > > > > > - 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. > > > > > > > > It isn't actually a fundamental problem at all. We shouldn't even be > > > > discussing this and it is really unfortunate that you continue to > > > > block this effort. > > > > > > > > As to bootmgr, I would be willing to implement a solution here, but it > > > > would involve changes to how bootmgr works under the hood, i.e. to > > > > have it be iterative instead of doing everything at the start. My firm > > > > understanding is that such changes would not be acceptable to > > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI > > > > subsystem. > > > > > > > > So the fallback is the work-around which Heinrich proposed. He is free > > > > to implement that if he likes, but I am not planning to do this myself > > > > as I see it as a short-term measure and it may cause problems for > > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I > > > > suppose they were happier days before everything froze up). > > > > > > > > > - 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. > > > > > > > > Bootstd is designed to replace the distro scripts and the feedback I > > > > have received is that it is good at that. If you have any other > > > > feedback, or any suggestions on people I should contact, I'm happy to > > > > approach them, or they can email the list and cc me. > > > > > > > > But really, it would be a lot easier if you could just apply this > > > > series so we can move on. If I can see even just a glimmer of > > > > compromise here it will help my confidence. > > > > > > Your sunxi series is broken as posted. I am not interested in applying > > > or encouraging more bootstd usage until there's actual work being done > > > to move forward wit bootstd (a thing you want) and EFI (a thing most > > > distributions want). That would be some of the general feedback you've > > > been given and missed or forgotten. > > > > > > This is even setting aside that I can't recall now if you ever started > > > on making non-BOOTSTD_FULL more useful / usable in general because it's > > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in > > > order to be flexible enough for users to decide SD vs eMMC and so on. > > > > You can hold this up for as long as you like, it's your tree. > > And you can do whatever you like in your personal tree, sure. But > there's rules for working in a community project. > > > I'm always happy and willing to discuss and commit to future > > improvements. The pattern I see, well-established now, is that you > > block my current improvements until some other things are done (this > > series, PXE and many others). Or sometimes you see my series, come up > > with a clean-up and block my series until it is based on top of that. > > If you could move away from that pattern and operate in a more > > cooperative manner, we could definitely get a lot more done in your > > tree. > > > > But again, you can hold this up as long as you like. I just feel it > > would be better for the project if you didn't. > > I continue to not accept changes from anyone that knowingly break other > use cases and users. You are not an exception to the rule. Leaving > things broken for now and improving them later is not an option in > mainline.
If that is your justification for blocking progress then it won't work in this case. There is nothing actually broken with my series. Shall I send it again so you can take another look? > > And I ask everyone to fix problems that are exposed when they're doing > something else. Sometimes, when it comes to Kconfig symbols I'll end up > doing the cleanup because it's tricky to get things right for 1300 > platforms. Yes, I know how you feel. Regards, Simon
