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