Dear Harald,
in message 20080121193613.GW706@prithivi.gnumonks.org you wrote:
- I have submitted two rounds of our patches (with about one year in between those two instances), and I have the feeling that the interest in even commenting to those patches was quite low. This is not very encouraging for further submissions.
Please don't mistake missing feedback for missing interest. There *is* interest in your patches, and care will be taken that your patches get processed as they should. Promised.
We do habe an ARM custodian problem that needs to be solved soon, but this affects all ARM contriobutions, not only yours. So please don;t take it personally.
- the s3c24xx chipset family support in u-boot is minimal and outdated.
It's outdated because nobody feeds back patches. This is a chicekn and egg situation, and if you work on this platform it's you who could solve it.
do some extensive re-work. Since there seems to be nobody who cares a lot about that family of chips (most products based on them, even if they run linux, don't use u-boot), I see quite a bit of reluctance to merge those patches. Furthermore, I have zero clue if there still
I am not reluctant. Please go on and post patches. U-Boot will not spread if we don;t use it, or if we don;t make our changes available to the public.
Pther users of such processors will not use U-Boot *because* support for these chips is "minimal and outdated".
is any living person out there who is trying to run u-boot on a s3c2400, and we certainly have no way of testing whether the new code
This is wrong. There is tens of thousands of systems running in the field.
breaks any of the old code. It has actually come to a point where I'd volunteer to maintain the s3c24xx chipset code in u-boot, if anyone was interested in that
You are welcome. Is this a serious offer? I think it might help to solve at least some parts of the ARM dilemma we're in.
- Some of the changes, notably the sd/mmc driver for s3c24xx was rejected by the u-boot list, since it just does what everyone else does: no shared host controller code, just copy+paste the bits that the other sd/mmc controllers do. While I understand that there is a need for a shared sd/mmc code, putting the burden of creating such code on us is just too much. With this kind of requirement you will unlikely to see anyone merge another sd/mmc controller driver into u-boot, since everyone evades creating the generic/common code. This is not pure laziness, but inexperience with the code and lack of access to all the different hardware
Well, someone has to go ahead...
- Some code is really ugly and spread throughout the code, since there is no clean/modular way how to do this inside u-boot. One perfect example is the boot menu code that we added. I don't even bother to submit it, since I'm sure it will be rejected
Maybe in th first version of the patch. But maybe others will add ideas how to make it less ugly and more suitable for integration, and maybe (maybe!) in the end we will have a system which is better for everybody.
Best regards,
Wolfgang Denk