[U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000

[Detlev Zundel <dzu@denx.de>]

Hi Dirk,

>> That being said, I think it
>> would make sense to put the devkit8000 in either board/devkit8000/ or
>> board/embedinfo/devkit8000 now as that is the "correct" place for it.
>
> Well, I just can't see what the advantage of this "correct" place 
> might be. So from the rule point of view, it might make sense, but 
> maybe we should adapt the rule, then?
>
> Looking at the TI stuff, it seems to me that a lot of (small? 
> different?) companies are using the same SoCs and doing boards with 
> these. Most of the U-Boot code is similar, then. But these companies 
> are doing only one or two boards. So it makes more sense to group 
> these boards based on the SoC (vendor), instead of the board vendor or 
> even worse the board name.

Well actually (I think) we agreed on doing the board/vendor scheme.  For
example look at board/amcc - there are all the AMCC evalboards basically
each one with a different SoC.  Turning this around into board/<soc>
would throw pieces all over the places, which is definitely not what we
want.

Let's look at it from this perspective - on a board level there is
really more adhesion between two different cpu boards from one vendor
than between two same cpu boards from different vendors.  Just take the
AMCC boards - they all have the same feel to them, so this is the
natural way to group the boards.

Even more, sharing of stuff should be done outside of board/ - if it
applies to all omap3, common stuff should be in cpu/arm_cortexa8/omap3
and *not at all* below board/.

Finding boards with the same architecture was always very easy by
grepping the include/config/* files.  We do not need a representation of
this fact below board/.

Although I think that these arguments carry some value, I know that
one can come up with - basically arbitrarily many other arguments.  But
still, we had this discussion already and I do not see that anything
fundamental has changed since the last time around, so please let's not
got into bike-shed painting right now ;)

Cheers
  Detlev

-- 
["From 2.4 to 2.6 to 2.7" discussing release numbering of the Linux kernel]
Let the bike-shed-painting begin.
                                     -- Linus Torvalds 
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de