[U-Boot] [STATUS] Heads-up: Reorganize directory structure
Alessandro Rubini
rubini-list at gnudd.com
Fri Apr 16 08:58:42 CEST 2010
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
More information about the U-Boot
mailing list