On Thu, Dec 12, 2024 at 07:04:54AM -0700, Simon Glass wrote: > Hi Ilias, > > On Sat, 7 Dec 2024 at 01:18, Ilias Apalodimas [snip] > > Another example is the fdt sutff here > > https://lore.kernel.org/u-boot/20241201144240.1664398-5-...@chromium.org/ > > Tom, Raymond and I spent a lot of our time explaining why we need this > > feature like this and what's the technical reason behind the decision. > > Your commit message basically says "I know better and you should all > > listen to my almighty ideas and btw this breaks 3 special ancient > > platforms, so I am reverting this". > > This is a deflection at best. WIth OF_BLOBLIST, you can just enable > that option and get what you want. You can even make it the default in > U-Boot. The issue is that you don't want to have the option. But > without the ability to turn the option off, my special, ancient > platforms, that no one cares about except me, break. > > > Now I don't know who Kevin and BoB > > are and I wish them luck, but that's hardly a readable commit message > > or will mean anything in a year from now. > > chromebook_kevin and chromebook_bob are a rk3399-based Chromebooks > > Again, the commit message is not a core issue. If you found yourself > in a reflective mood, you might want to consider how I feel about 5-6 > platforms which I care about a lot, being permanently broken in Tom's > tree.
Having just this morning figured out the problem with those chromebooks (because they're available in CI, so thank you for that work), I think this is also a good example of one of the problems. My recollection of the threads from last year does not include you mentioning that on these three platforms the issue is that you put the fixed bloblist address in DRAM *and* that SPL initializes DRAM here (not TPL, not TF-A) that's the concern. My recollection of the threads is you had very different technical reasons for wanting what you proposed and those technical reasons had technical objections. I've posted https://patchwork.ozlabs.org/project/uboot/list/?series=436459&state=* now and that fixes those three platforms. And we could have done that a year ago if you had explained the problem on those platforms. I would have asked why not putting the bloblist in IRAM instead, at that point, and you may have had an answer, but that would have still left coral to sort out. And how is this part of the problem? You cannot suggest architectural designs without explaining the technical details of what and why you want something. We all spent countless hours arguing about some feature of bloblist design which zero platforms actually need. > > The way I read this commit message is that you show zero respect for > > the effort all of the other people put into code explaining and > > documenting the feature, your 'justification' has no technical > > background whatsoever and then you come back complaining that people > > don't appreciate your efforts. > > Obviously you are entitled to your opinions, but I don't agree, sorry. > I doubt anyone is particularly interested in my thoughts on this, so > I'll refrain from commenting further. > > Just to confirm, nothing in your email appears to address any of my > concerns. If it was intended to, please point out what I missed. No, this is another example of the problems. You've been given feedback here, which is that your communication skills are a problem, and your response is to say you don't agree. -- Tom
signature.asc
Description: PGP signature
