[U-Boot] [ANNOUNCE] Kconfig support

[Ladislav Michl]

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
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.
In other words, incrementaly changing v1 to be at least close to v2
(from design perspective) would take order of magnitude more man power
than doing it from scratch (and hey, pengutronix guys already did it for
us!), but for those who love slow and painfull paths, there is nothing
really wrong with this approach.

Anyway, this discussion is probably pointless without knowing what are
long term goals of U-Boot (hint: Do we ever consider supporting anything
like Sergey described in thread "Multiple device support - none at all?"?
Yes, I know there were some hints how to hack it "somehow", but I doubt
neither authors of such hint consider them nice solution)

Best regards,
	ladis