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

[Harald Welte]

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'.

> 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

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 

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.

Cheers,
-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone