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

[Dirk Behme]

Peter Tyser wrote:
> Hi Dirk,
> 
> On Fri, 2009-08-21 at 15:00 +0200, Dirk Behme wrote:
>> Frederik Kriewitz wrote:
>>> Jean-Christophe asked me to move it out of the omap3 "vendor" directory:
>>>
>>> On 10:55 Thu 20 Aug     , Frederik Kriewitz wrote:
>>>> On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
>>>> PLAGNIOL-VILLARD<plagnioj at jcrosoft.com> wrote:
>>>>>>  board/omap3/devkit8000/Makefile     |   52 +++++
>>>>>>  board/omap3/devkit8000/config.mk    |   35 ++++
>>>>>>  board/omap3/devkit8000/devkit8000.c |  124 ++++++++++++
>>>>>>  board/omap3/devkit8000/devkit8000.h |  373 +++++++++++++++++++++++++++++++++++
>>>>> no need board are allow in board/omap3
>>>>> please create your own vendor dirent or just put it in board/
>>>> What do you mean with that?
>>> board/devkit8000/devkit8000.h
>>> or board/embedinfo/devkit8000/devkit8000.h
>>>
>>> I'm confused, where am I supposed to use omap3 and where not?
>> Yes, sometimes it can be confusing ;)
>>
>>  From earlier discussions I understood that Jean-Christophe doesn't like
>>
>> board/omap3/
>>
>> I'm not totally sure what he actually wants, but I think something like
>>
>> board/ti/omap3
>> board/ti/omap2
>> board/ti/omap1
>> board/ti/davinci
>>
>> etc. (e.g. like board/atmel).
> 
> My understanding is that the board/ layout should be "/board/<board
> vendor or board name>/...".  So even though the Frederik's board has a
> TI OMAP3 cpu, he shouldn't put it in board/ti or board/omap3 since
> neither TI nor OMAP3 made the DevKit8000.
...
> For example, there are mpc8548, mpc8572, mpc8548, and amcc440-based
> boards in board/xes, but they are all made by the X-ES company.
> 
> Jean-Christophe is saying you should put your board in either:
> board/devkit8000/
> 
> or, if your company (embedinfo?) plans on adding more than just the
> devkit8000, put it in:
> board/embedinfo/devkit8000
> board/embedinto/<future_board_x>

I really dislike this. With OMAP3 this would result in 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.

Same for DaVinci.

After some time, or for somebody not familiar with it, it would be 
really hard to identify that all these are the same platform where 
grouping (and identifying common code) makes sense. It would pollute 
the number of directories in board even more.

> I agree that other boards currently in board/omap3 should be moved to an
> appropriate board/<board vendor or board name> directory in the long
> run, ideally sooner rather than later:)  

I disagree with this.

Having board/<board vendor or board name>

resulting in e.g.

board/embedinfo/devkit8000
board/embedinto/<future_board_x>

would result in a lot of more (unorganized) directories in board/* . I 
can't see any advantage in adding *more* directories into board/*. 
Instead, I see an advantage in having less directories in board/*, 
resulting in more organization/grouping.

Doing something like

board/ti/omap3
board/ti/omap2
board/ti/omap1
board/ti/davinci

would help to make board/* cleaner.

At the moment we have

board/omap3
board/davinci

what I feel is even better (cleaner) than what we would get with 
board/<board vendor or board name>

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

Best regards

Dirk