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

[Detlev Zundel]

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

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 <vendor == TI> OMAP3 based board (e.g. Beagle) has no adhesion with
> a <vendor == TI> 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