On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote: > Hi Tom, > > (I changed the subject as 'change' sounds like change for change's sake)
Frankly, you have a lot of "tidy up" patches where nothing was functionally wrong. > On Mon, 24 Feb 2025 at 16:23, Tom Rini <tr...@konsulko.com> wrote: > > > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > (I think you chopped off too much context, so I've added it below) > > > > That's fine. But I omitted it because it's also true for any other DM > > migration, and bootstd more fully and adding more classes of devices for > > bootmeths and I honestly think you have a half dozen big things that are > > in various states of being merged and enabled and perhaps even more that > > didn't get much past sandbox being enabled. > > Yes I often have new ideas and start things. And my point is they need to be finished. > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote: > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > [snip] > > > > > > [unsnip] > > > > > > > > > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. > > > > > > > > How do > > > > > > > > you imagine we could retire the legacy image? > > > > > > > > > > > > > > Partly by focusing on one thing and not 5 things at a time. > > > > > > > bootstd is > > > > > > > stuck on reworking efi bootmanager integration, and LED is > > > > > > > waiting for > > > > > > > someone to confirm that really, finally, we have all of the old > > > > > > > use > > > > > > > cases supported in the new code. > > > > > > > > > > > > > > But more importantly, do we really have anyone not using > > > > > > > u-boot.img? I > > > > > > > don't know. > > > [unsnip end] > > > > > > > > > If we did one of these sorts of things at a time, we would only get > > > > > > 2-3 things done each year! > > > > > > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year > > > > > sounds great to me. Rather than not finishing a dozen things? > > > > > > > > As this is a huge thread already, I'm splitting this part out. > > > > > > > > I would seriously frame slowing down and having just one big change > > > > being in progress at a time, until it's done, as a good thing, not a bad > > > > thing. We're a small community with limited bandwidth. > > > > > > I can't see how that would work. > > > > Well, what we have today is clearly not working well enough for you. And > > "just land my changes" is still not an option for mainline. > > You really haven't addressed my point here. Then I don't see your point, or fundamentally disagree with it. > > > I just looked at LED[1] originally sent almost 5 months ago and the > > > latest version is marked 'changes requested'. I don't know of any > > > changes I can make. Are you hoping that [sorry forgot who it was] will > > > get around to digging the only affected device out of his drawer and > > > try to get the activity-LED going? It might take a while. > > > > Yes, and as a reminder it's only been 6 or 7 months since mainline had > > all of the required functionality, maybe. And what *you* could do to > > speed things along is implement the functionality on any of the boards > > at your disposal. Anything with a LED today would be fine for this. > > Oh well. I would have thought that Christian's series was enough there? Might be. Waiting for someone to have time to confirm functionality. Which you had previously agreed was a good idea, I thought. > > > The sunxi one[2] was sent over 6 months ago and the latest version is > > > also marked 'changes requested'. You could apply that series with > > > either the bootmgr revert or the patch that drops bootmgr for sunxi. > > > Then Heinrich can come along with his patch on top of that. > > > > The sunxi one is blocked because it needs to be rebased on top of the > > fix I did for BLK stuff and then yes you also could have done the > > "bootstd uses bootmanager" idea that you've both agreed is a step in the > > right direction. Because it's actually a generic issue with bootmgr + > > bootstd that only became more evident as more platforms moved > > towards using it. > > So can you clearly explain what is blocking sunxi?r In no particular order: - Testing. - Fixing the problems with efi boot manager, which is a global "use bootstd more" problem, not sunxi And maybe: - Handle FEL correctly. I'd have to re-read everything again to see if that was resolved right, or not. > Does it just need a rebase? Not just a rebase. > Which patches should be included and which not? Once the efi boot manager part is fixed, just the parts required for it? > Also we > normally expect patches sent first to have priority. No we don't. There might be some general advice / rules of thumb but it's far from some sort of absolute rule. Things are merged when they work and are correct. > Here you have > apparently applied your BLK stuff and then want me to rework on top of > it? Yes, I applied the "handle BLK correctly" part that I tried to explain to you how to fix a few times, and you either didn't understand or didn't care. I'm leaning more towards "didn't care" now and thought we should break things a little bit first and fix them later. > I agreed to the bootmanager work-around but I'm certainly not going to > write it. I would rather make bootmgr more iterative, if that is > possible. Then more bootstd migrations are likely blocked until it can handle efi boot manager correctly, which you don't want to do. > > Which is why I had spent so much time trying to get > > you to migrate more SoCs to bootstd because it's your feature. > > So take the sunxi patches and then I'll do the next one? On the one > hand you complain that there are too many balls in the air and on the > other you stop the balls from landing. It just doesn't 'compute' for > me, sorry. Yes, I'm sorry you're having trouble following my requests. Again, I wanted more bootstd migration not for its own sake, but to expose problems with the framework and for you to then fix those problems. > > So yes, I think things would be in a better place if we tried to get > > *less* big things done at once and didn't pick up another big thing > > until the last was really done. > > You should address my point above. Are you trying to limit me to 3-4 > large series a year? You personally? No. The whole project? Yes, one big feature that's complete and works every 3 months for a project with limited resources sounds amazing. U-Boot isn't a toy personal project, it's something used in production on real devices and needs to move at a sustainable pace with minimal regressions. -- Tom
signature.asc
Description: PGP signature
