Graeme, I reply to your messages since it gives somehow more information. I'm now not really convinced that reorganizing board directories would be a big step forward, although I still think it would be better. Si, I'm not arguing strongly, just bringing a point of view.
Peter, Wolfgang, I'll try to do my homework and show how nhk8815/usb-s8815 would better share files when under cpu/, but I'm not sure to be able to complete it before a week or so. Graeme Russ: > Almost - it is more like > > board/ > $VENDOR/ > include/ > common/ > lib(?)/ > <etc..>/ > $BOARDA/ > $BOARDB/ > > I really like this structure, particularly if the code under > $VENDOR/[common, include, lib] is arch independent. Yes, that would be good, if it was a common case. However, arch-independent code is usually under drivers. See at91 and avr32 for example: no common code under board/atmel/ . Even boards/freescale, which has three architectures, has only MPC stuff in common/ (no arm or coldfire files, checked by extracting the CONFIG_ symbols from Makefile and grepping for them in include/configs) > If a vendor develops a new board using a different CPU or SOC they > can easily re-use all their pre-existing platform independent code > for the new board. In theory you are correct. In practice, such platform independent material is using drivers/ . > And then there is also > > board/ > $BOARDC > $BOARDD > > I've never liked code existing on multiple depths like this. Agreed. > Maybe we move towards: > > board/ > $VENDOR > include/ > lib/ > $BOARDA/ > $BOARDB/ > $<cpu>_generic/ > $BOARDC/ > $BOARDD/ That's an option. But "$<cpu>_generic" is inferior to "cpu-$<cpu>". At least listing will all "cpu-" directories nearby. If there really was vendor-specific cross-platform code, I agree something like you suggest is best. /alessandro _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
