[U-Boot-Users] How to patch u-boot?

[Wolfgang Denk]

Dear Harald,

in message <20080121193613.GW706 at prithivi.gnumonks.org> you wrote:
> 
> 2) 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.

> 1) 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.

> 2) 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... 

> 3) 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Totally illogical, there was no chance.
	-- Spock, "The Galileo Seven", stardate 2822.3