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

[gvb.uboot]

Harald Welte wrote:
> On Mon, Jan 21, 2008 at 10:07:07AM -0500, Jerry Van Baren wrote:
> 
>> Openmoko has not been an active participant on the u-boot list.  
> 
> Mh, please check your list archives.  I see 22 postings over the last
> year.  Not many, but also !=- 'not been active'.

Good to know, thanks for correcting me.  I've watched openmoko in the 
past and thought about buying one but don't have enough time in my life 
right now.  :-(

>> They  took a snapshot of u-boot and then did their own patching, but
>> did not  feed the patches back to u-boot.  
> 
> This is also not entirely true
> 
> 1) we are constantly merging our patchset with mainline u-boot, at least
>    once per week.
> 
> 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.

:-(

>> The result is a fork.  IIRC, there has  been talk about unforking
>> openmoko, but that has not happened yet.
> 
> I'd be very happy to do so.  However, there are several reasons why this
> is extremely difficult
> 
> 1) the s3c24xx chipset family support in u-boot is minimal and outdated.
>    It only covers the s3c2400 and s3c2410, and even those only partially
>    In order to make it support the s3c2410, s3c2440, s3c2442, I had to
>    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
>    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
>    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

I spend most my time in PowerPC world, so I'm pretty clueless WRT 
ARM-based chips.  According to
   <http://www.denx.de/wiki/UBoot/Custodians>
Peter Pearse is the ARM custodian, so he most likely would be the one to 
pester.

I would speculate the lack of comments on your patches (2 above) and the 
lack of anyone else(?) working with that chipset are related.

> 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 

/me == clueless

> 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

:-(

>> The bottom line is that we know little or nothing about openmoko's  
>> u-boot build methodology.  You need to ask openmoko developers (openmoko  
>> lists).
>>   <http://lists.openmoko.org/mailman/listinfo/>
> 
> This is entirely true.  Usually those questions are raised on the (now
> defunct) openmoko-uboot list, that has been superseded by
> openmoko-kernel.

Well, at least I got one thing right.  :-/

Best regards,
gvb