On Fri, Aug 21, 2009 at 7:59 PM, Wolfgang Denkwd@denx.de wrote:
In message m24os18a3w.fsf@ohwell.denx.de you wrote:
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.
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.
Correct. That's the cuirrent "official" definiiton, and so far I see no reason to change it.
Ok, is there a official naming convention for the include/configs/*.h files and the *_config targets? Should they be grouped by CPU/SoC and/or vendor (Makefile/MAKEALL)?