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