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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
