Dear Matt Sealey,
On Sat, Aug 18, 2012 at 5:26 PM, Marek Vasut marex@denx.de wrote:
Dear Matt Sealey,
On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic sbabic@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