From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Fri, 21 Aug 2009 17:41:19 +0200 Subject: [U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000 In-Reply-To: References: <1250786842-9134-1-git-send-email-frederik@kriewitz.eu> <1250787736.2789.23.camel@localhost.localdomain> <4A8D87AC.5070008@googlemail.com> <4A8E9A71.7010103@googlemail.com> <1250865294.18341.1953.camel@localhost.localdomain> <4A8EB875.30309@googlemail.com> Message-ID: <4A8EC01F.7040307@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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/ > 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 OMAP3 based board (e.g. Beagle) has no adhesion with a 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