From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Fri, 21 Aug 2009 18:04:01 +0200 Subject: [U-Boot] Rules for board/* directory, was: [PATCH v3] Adding support for DevKit8000 In-Reply-To: <4A8EC01F.7040307@googlemail.com> (Dirk Behme's message of "Fri, 21 Aug 2009 17:41:19 +0200") 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> <4A8EC01F.7040307@googlemail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Dirk, >> 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. I doubt that we can be more flexible with this rule without effectively introducing another rule. After all, that's what you say: "generally we follow rule a, only if it doesn't make sense (which one cannot tell beforehand) and then we follow rule b". Such a "metarule" is not a big help - precisely because one cannot tell beforehand which "sub-rule" is applicable. >> 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. To which I reply - then TI should better shape up their U-Boot support and get the boards in line ;) >> 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? No way. I only say that stuff which boards have in common *additional* to what they share from their architecture *should* be very little. Ideally a board/ directory is *very* light. The heavyweight stuff should be below cpu, drivers, etc. >> 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? It hurts if it stops us from having a single rule. >> 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? A rule is only good if it really helps to organize stuff. So yes, I see an advantage of the latter examples, namely that someone looking into board/ has a single rule which will allow him to find what he is looking for. Cheers Detlev -- I talk to planets baby -- Dave Wyndorf (Monstermagnet) -- 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