[U-Boot] [PATCH 3/4] efikamx: update to Efika MX Smarttop and Smartbook boards

[Marek Vasut]

Dear Matt Sealey,

> On Sat, Aug 18, 2012 at 5:26 PM, Marek Vasut <marex at denx.de> wrote:
> > Dear Matt Sealey,
> > 
> >> On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic <sbabic at denx.de> wrote:
> >> > On 17/08/2012 20:19, Matt Sealey wrote:
> >> > 
> >> > Anyway, who will maintain the efikas in future ? Marek, do you hold
> >> > it, or Matt will take this job ?
> >> 
> >> I'll do it but I doubt I'm going to be around as much as Marek. What
> >> I'm a little fearful of is having patches try and hit the Efika stuff
> >> and me not having much time that day to review, they either stagnate
> >> or get accepted anyway breaking something.
> > 
> > So your commercial QA has to arrive at the RC stage and fix it if needed
> > ... every around 3-4 months.
> 
> That is in fact the plan.
> 
> If we can get TO2 support back in at that time, we will do it, but for
> now it cannot just go in broken. We cannot test the mux code on these
> boards if they don't boot...
> 
> > I think you need to understand that FOSS is a cooperative effort. It is
> > not any commercial crap which you roll out and throw away when it made
> > enough money. We will not stop hacking on mx51 only because it might
> > break your platform, that's not how it works.
> 
> The problem here is that we don't make any money from MX51 anymore;
> there are no Efika MX systems to sell, stock is basically depleted. So
> this work is an offshoot of some other code. If, on the other hand,
> you want to cooperate and test it on TO2 and report your results and
> tell us what is broken, that would be fine, but we can't expend time
> and effort fixing something which represents barely a percentage point
> of customers; if you don't have a TO2, then you can't help, and you
> can't complain if you can't run it let alone test it.
> 
> > To put it into more "commercial" terms, we are not paid to support your
> > platform, on the other hand, we already gave you the source code. So to
> > restore the balance, you help us keeping it working well by investing in
> > QA. Everyone's happy.
> > 
> > Besides, if you want to deploy less potent version, you can always
> > configure your u-boot in such way and deploy it to customer, noone can
> > prevent you from that. But since there is support for certain additional
> > hardware in upstream already, I'd object to remove it.
> 
> That is the way we're doing it, but we can't in good conscience deploy
> a non-neutered version with such heavy cleanups that we cannot
> guarantee booted in the first place let alone with our changes.
> Modifying the IOMUX setup method did not fix booting, but we cannot
> tell if it worked properly in the first place. Number of users of TO2
> Efika MX boards r1.1 and r1.2 is so low, it's hard to imagine these
> people giving a rat's ass about whether mainline works on it or not
> (especially since there's no mainline Linux support for these boards
> as it stands - even with the old U-Boot we shipped on the boards that
> works, the kernel is less than reliable for various reasons).
> 
> > See how the mx28 stuff is being developed to see what I mean. Me, Fabio,
> > Otavio and many others are adjusting each others boards and it works
> > very well.
> 
> I would like to see you justify again updating code that supports a
> board that hasn't actually booted mainline U-Boot in several months,
> if not years, with a code change that cannot be tested.
> 
> Once it's gone through testing and we work out for sure why U-Boot
> simply does not run on a cpu-revision 51025 i.MX processor on the r1.1
> and r1.2 boards in any version, before my changes or after, we will
> patch back in confirmed and working support, but we shouldn't be told
> we have to maintain broken code just so it sticks around. You have
> git, you can see the changes made to remove the code (it's literally
> all of 3 lines extra to add it back in, it is mainly the second SD
> card slot definition and CD/WP pins). It is not like the information
> is lost in time.
> 
> I just don't see the point in making sure we update every line of code
> that exists, if that code simply never gets run, or never has the
> opportunity to run due to other problems.
> 
> This is a dead product, we simply want to make sure that SOME mainline
> support is both reliable and usable. The work directly influences the
> design of new products and existing products which are not in
> mainline; to get MX53 stuff in there or MX6 design stuff in there,
> common IOMUX setup, common GPIO, other common things which are
> otherwise awful to define and add to designs. If we evaluate the
> software development will take too much time and money it may be cut
> from the design. If the feature makes the board less user-friendly as
> a result, it will definitely never make it into a prototype.
> 
> Right now, we're trying to lay a good foundation for MX53 and MX6
> designs we currently sell. Supporting the MX51 models is purely laying
> that good foundation to make sure that the effort we expend later on
> actual shipping products can be tested across the entire line where
> common code and configuration can and should exist. Unfortunately
> i.MX51 TO2 designs exist in the world in some number, but fortunately
> the number of people running them who require U-Boot to build and run
> on their boards is a big fat zero. If there are no users, the code can
> go.. if there is a user for it later, it can be re-evaluated by
> someone out there.
> 
> Would it make a difference if I was the maintainer? Yes, because you
> would be automatically overridden in asking to keep TO2 code in there
> because as maintainer I would not be willing to maintain such code. It
> doesn't matter in that position if YOU think it MIGHT be useful for
> someone else, as the a) designers b) vendors c) support network for
> this hardware, we have decided flat out, Efika MX r1.1 and r1.2 boards
> are not worth supporting in this patch and should definitely not leave
> code around which could be mistakenly run, or possibly just exist to
> confuse the configuration of the board.
> 
> Crashing before even reaching the relocation code is not
> user-friendly. As it stands, removing the TO2 support to reduce the
> amount of testing we have to do (in the sense that it cannot be tested
> while the bug exists) and then adding it back in once that testing is
> actually completed, while providing the vast majority of users working
> code in the meantime, is more important right now, making that common
> code work.

Can you concentrate the information that completely sunk in the text above? 
What's your point? In a _few_ sentences please. Mailing list is not highschool, 
you don't get graded for writing an essay. Besides, you waste both yours and 
mine time.

Best regards,
Marek Vasut