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

[Dirk Behme <dirk.behme@googlemail.com>]

Hi Detlev,

Detlev Zundel wrote:
> 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.

Yes, I agree that it makes no sense to *completely* change the rule.

Maybe we should just be a little bit more flexible about this rule and 
have look, where something else makes more sense.

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

I could add the opposite example:

A <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with 
a <vendor == TI> DaVinci board.

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

Sounds like you propose to put omap3 *board* common stuff into *cpu* 
directory?

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

But it wouldn't hurt?

> Although I think that these arguments carry some value, I know that
> one can come up with - basically arbitrarily many other arguments.

Yes ;)

> 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 ;)

Could we agree to be more flexible with this rule?

Or, the other way around:

Independent of the rule, do you see any advantage of switching existing

board/omap3/
board/davinci/

into something like

board/DigiKey/beagle (or board/TI/beagle?)
board/gumstix/overo
board/mistral/evm (or board/TI/evm? )
board/xx/pandora
board/zz/zoom1
board/yy/zoom2

etc.?

Except to follow the rule?

Thanks

Dirk