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

[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.

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.