[U-Boot] [ANNOUNCE] Kconfig support

[Heiko Schocher]

Hello Ladislav

Ladislav Michl wrote:
> On Wed, Apr 22, 2009 at 01:12:07AM +0200, Wolfgang Denk wrote:
>>> One of these boards is the Auerswald Innokom, a board Robert once
>>> ported. We probably still have it somewhere @Pengutronix, but nobody in
>>> the world has any interest in running a top of tree U-Boot on it. Still
>>> it is in the tree and by policy it has to be supported for all eternity.
>> Feel free to submit patches to remove it from the tree if you care.
>>
>> On the other hand - how much effort was  actually  spent  on  keeping
>> this  board  alive?  Obviously  not  much, because so far nobody com-
>> plained about it. Actually that's the whole idea about having a board
>> in mainline. If you look at the changes  that  were  applied  to  the
>> related  files,  it's  all stuff that was done 99% automatically with
>> some scripts - and I don't really care if these  are  applied  to  20
>> boards or to 200.
>>
>> I fail to understand what you are trying to tell us.
> 
> May I? Last time I looked at mainline U-Boot about year ago, sending few
> patches and it was working for me. Since then some changes (only minor ones
> from design pespective) were applied (some of them automatically with some
> scripts) and since then my board support was broken. It cannot boot neither
> from network - network code uses get_timer and I bet _no_ OMAP based will get
> IP address from my DHCP server sitting behind ancient hub - (still true and so
> far no comments except from Dirk) nor from NAND (already fixed). And once
> AT91RM9200 landed on my table I needed to patch other AT91RM9200 based boards
> just because they suffered the same problems I meet. Obviously noone noticed
> for years. Thats from my perspective too much breakage such a "cosmetic"
> changes. And what if we try to do any fundamental one?
> 
> Based on this experience I wouldn't expect much of those 200 boards to work
> properly. Or was it only my bad luck? To sum this up: wide majority of boards
> is just sitting in tree, without any interest. It compiles so it must be good,
> right? Switching v1 into maintenance mode only makes sense as well, it is just

What else should a maintainer do? He have not all boards to try the
new code! You can just look at Coding Style, clean compile and maybe
he see, that this Code couldn;t work ...

To look, that a board works with actual code is at least the job
from the boardmaintainers, and if they notice that some code no
longer works, they have to post patches which fixes that... whats
wrong with that?

> matter of decision. And you obviously decide to incrementaly fix v1. So there
> really is nothing to discuss.
> 
> Now given the fact that most board support consist of config file
> and few lines of board specific glue code, the idea of doing major
> architectural changes in v2 and migrating board support there doesn't
> look completely wrong, does it? Of course, if v1 "just works" for simple
> designs there is no need to throw it away, but I perfectly understand
> Sergey Kubushyn despair trying to support more devices of the same kind.

I can speak here only for the i2c subsystem. Sergey posted patches which
where from the design "nearly" perfect, but this doesn;t gone in main-
line because missing CodingStyle fixes, Patches in not a "good Style"
and so on ... and there were 2-3 minimal points we couldn;t arrange :-(
And someday he went away, because his time was over (no more money
for it) ... :-( This way open source did not work! We cannot plonk
some patches (which change design) to the mailinglist and ignore
all comments, and if they not go in mainline blackguard actual code!

And so we stand here ... (I try to forward this design in my freetime,
but this is a rare resource ...)

So I opened 2 branches in u-boot-i2c.git to compare the 2 "suggestions"
for the multibus approach in the i2c subsystem, so we have a real base
for discussion.

But no one seems to have interest in this :-(

And I have hope, that this multibus design can be adapted for other
subsystems too ... but somebody have to do this work, and if this
is in v1, he has to do this for all boards!

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany