On Wed, Mar 05, 2025 at 07:19:25AM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 4 Mar 2025 at 08:29, Tom Rini <tr...@konsulko.com> wrote: > > > > 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. > > Yes, but they are important too. One of the problems I see with U-Boot > is that not enough people are willing to do refactoring and code > maintenance on the required scale.
Again, how much "refactoring" is needed of everything. > > > 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. > > We've been through this quite a bit and I believe we have a shared > understanding of why it is hard for me to 'finish' things in your > tree. I don't think we do. Because from my point of view you're as interested in finishing up the details and working through the migrations as you are on moving to the next thing. > > > > > 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. > > My point is that I am trying to keep U-Boot in a position to solve the > major problems I see with boot firmware, largely because I don't see > much else out there. I can't do that with 2-3 big changes a year, not > even close. Then maybe you need to fork off and make Simon-Boot. Or maybe you need to take leadership of the project as a whole. Because I do not see what you want as sustainable for the project. > > > > > 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. > > OK, so we'll just wait another few releases? Until someone, which could be you even, has the time to verify things, yes. Easily. Happily. > > > > > 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. > > Andre did the testing which is how he found the bootmgr/FEL problem. > FEL is handled correctly in my series. So FEL is OK afterall, good. > For bootmgr, there are two patches in my series so you can choose > which one you want. And the answer there was neither, both are wrong. We instead finally hit a more fundamental problem. Which you don't want to solve. And Heinrich has said he'll post RFC on, but hasn't had time. > > > 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? > > So just take the patch which disables bootmgr from sunxi? Who was in favour of that idea again? > > > 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. > > Well I was a bit put out seeing the series rejected on v3 due to an > out-of-tree thing I wasn't aware of. Yes, you need to figure out how to get a better handle on your emails since you shouldn't have been unaware then. > > > 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. > > The correct way to handle bootmgr is (probably?) to have it use > bootstd to scan for stuff. But as you know, I can't get patches into > the EFI subsystem, so it's moot. Since you insist on starting with several "tidy up" series that have been rejected before starting on the problem at hand, yes, that's true. > > > > 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. > > There is no problem with the framework. Please just follow my notes > above and apply the patches. Specifically these ones: That it doesn't work nicely with EFI boot manager IS a problem with the framework. > 733876246aa sunxi: Add a bootmeth for FEL > ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi > (leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make > efi_mgr bootmeth work for non-sandbox setups" > 90d88509ebd sunxi: Move to bootstd > e0a16425620 sunxi: Drop old distro boot variables > da69a979ec7 env: Provide a work-around for unquoting fdtfile > 7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to > text environment > > I'm tired of hearing that there is something wrong with bootstd here, > so please stop saying that. Well, from my point of view there is a problem. Because your "tidy up" isn't working with what mainstream OS distributions want. So it's not a 1:1 replacement for what we have today that does work. > > > > 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. > > I believe that is getting better with the increased focus on testing, > something which I have been pushing for years. I'm referring to the breadth of testing, not the depth of testing. More tests are good. More boards being tested is more important. Your lab is good, yes, but it's not like HW vendors haven't been testing already and for a long time. And your feedback on their feedback (needing to be able to use a they-push-out model) wasn't positive. -- Tom
signature.asc
Description: PGP signature
