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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
