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

[Harald Welte]

On Tue, Jan 22, 2008 at 10:32:53AM +0100, Haavard Skinnemoen 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.
> 
> [...]
> 
> > 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.
> 
> Hey, is that the thanks I get for actually commenting at your mmc
> driver? I don't recall rejecting anything, nor do I have the power to
> do so.

well, sorry.  But since there were no other significant comments, it was
sort of the most important/influential one.

> I did suggest that you move the MMC protocol definitions to a common
> header file. That's not a huge task, but you could have said "no, I
> don't want to do that right now. Maybe later." and it would have been
> perfectly fine. Instead, you said "will do so in the next version of
> the patch." But no next version of the patch ever showed up, despite
> quite a few comments from others as well.

well, obiously I try to implement the suggestions of the people on this
list, even if it means significant additional delays.  There is no point
in submitting the same stuff without implementing the comments from the
review.

> But IMO _suggesting_ that you do it is completely different.

Well, then I say 'thanks for the suggestion'.  In fact, I guess nobody
would ever object to the fact that 'yes, a common layer would be
better'.

> Btw, I find the "lack of hardware" argument a bit disturbing. Doing
> some cleanups really shouldn't require anyone to have access to all the
> affected hardware 

Well, the big issue is that most of those cleanups are deep down in the
low-level head.S/start.S initialization, affecting the ordering of how
PLL's are initialized, the resume-from-ram code paths, etc.

Thos can be very tricky, and especially with the level of documentation
that Samsung provides about chipset bugs (close to zero), it can be very
easy to break something on one chip without noticing.  They have done
things along the lines of re-defining the meaning of the same bits in
the same registers from 'pull-up' to 'pull-down' :)

> -- IMO much of the responsibility for testing that nothing breaks on
> real hardware lies on the custodians and other users that actually
> have access to the affected boards. 

> But a few cross toolchains are definitely required to verify that it
> actually compiles on a handful of configurations before submitting.

This would basically mean I had to know which toolchains other users of
boards using the existing 24xx support are using.

So far, there is
smdk2400
trab
mpl/vcma9
sbc2410x
smdk2410

Now for some of those products, there might be vendor-provided
toolchains that many people use.  For others, there isn't, and even if
there is, quite a number of people use their own stuff, or whatever
configuration of OpenEmbedded, or OpenWRT, or even something else.

Is there somewhere a list of the toolchains that the code has to compile
against, including pointers on where to obtain them?

And while we're at it,

I have working (and want to add) support for:
qt2410
smdk2440
neo1973/gta01
neo1973/gta02

In the future, I could potentially work on support for:
some TomTom GO models (they're all 2410/244x based)
smdk2443
smdk6400

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