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

[Peter Tyser <ptyser@xes-inc.com>]

Hi Dirk,

> > 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 don't think most end users care much about which boards correlate to
which platform - they care about where the board they are currently
working with is located in the U-Boot tree.  From this perspective, I
think board/<vendor> makes sense.  Eg I'm working on an X-ES board, I'll
look in board/xes, I'm working on a Freescale reference platform, I look
in board/freescale.

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

I think its a matter of opinion.  Some companies support many different
cpu architectures.  I like having our X-ES-specific code in 1 location,
board/xes.  X-ES boards can then easily share common code too, eg
board/xes/common/.  Where would vendor-specific code that was used on
multiple boards be located if the board/<vendor> layout is not used?
The alternative is something like:

board/freescale/mpc85xx/xpedite5370/
board/freescale/mpc86xx/xpedite5170/
board/amcc/ppc44x/xpedite1000/
<somewhere else?>/xes-common/

This seems more disorganized than board/xes to me.

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

I think this breaks down (or at least is less appealing) when a board
vendor supports a number of different cpus and has some code that is
shared between their boards.

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

I can see that angle, but I can see other angles too.  I'd lean towards
the current layout (technically how the PPC boards are currently
organized), but if you had a good solution for us vendors that support a
number of different CPUs and have some common vendor code, it'd be
interesting to discuss.

Best,
Peter