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

[Harald Welte]

Dear Wolfgang,

thanks for your prompt feedback.

On Tue, Jan 22, 2008 at 10:18:39AM +0100, Wolfgang Denk 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.

I know the problem, both specifically and general to FOSS projects, as I
have worked in many of them ;)  So I know it isn't personally, but then
also I personally don't think that my patches are more important than
anyone elses...

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

yes and no.  

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

I agree that at least the core s3c24xx stuff should go mainline, no
question about that.

> Pther users of such processors will not use U-Boot *because* support
> for these chips is "minimal and outdated".

that's true.  btw: Samsung is now shipping some (old, outdated) fork of
u-boot with their later smdk2443 and smdk6400 boards.  Obviously the
code is neither clean nor suitable for submission, nor was it ever even
submitted :(

But 2443 and 6400 are beyond what openmoko has done so far anyway, so
this is not competing.

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

yes. I was thinking of 'people who develop new products and are looking
for a bootloader'.  The 2400 is discontinued for quite some time...

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

I'm serious about this, yes.  

At least for 2410/2440/2442, I have quite extensive experience after all
the hacking at OpenMoko.  I'm familiar with the smdk2410, qt2410,
smdk2440, qt2440, neo1973_gta01 (s3c2410), neo1973_gta02 (s3c2442b) and
hxd8 (s3c2440) boards, and I can contribute board support for all those
to u-boot.  I'm also in contact with what Ben Dooks (Linux s3c24xx
maintainer) is doing on the mainline kernel side.

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

yes, of course.  But you need somebody who is voluntarily committed to
doing a generic sd/mmc stack for u-boot.  It's no use to try to
push/force  people who have only the time to write a host controlelr
driver into doing it ;)

Ok.  Give me a bit of time, and I'll do another round of
s3c24xx/openmoko/neo1973 related patch submissions.

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