Dear Matt Sealey, > On Sat, Aug 18, 2012 at 5:26 PM, Marek Vasut <ma...@denx.de> wrote: > > Dear Matt Sealey, > > > >> On Sat, Aug 18, 2012 at 10:50 AM, Stefano Babic <sba...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
