[U-Boot] [STATUS] Heads-up: Reorganize directory structure

Graeme Russ graeme.russ at gmail.com
Fri Apr 16 04:42:24 CEST 2010


On Fri, Apr 16, 2010 at 1:58 AM, Peter Tyser <ptyser at xes-inc.com> wrote:
> Hi Alessandro,
>
> On Thu, 2010-04-15 at 17:31 +0200, Alessandro Rubini wrote:
>> I can see how it'd be
>> >> nice to split up boards into CPU directories, but we'd have to discuss
>> >> some of the warts, like where vendor-specific code would be located if
>> >> we went down that path.
>> >
>> > Right. I can see arguments pro and con each of the approaches, and I
>> > must admit that I have no telling argument for either.
>> >
>> > My gut feeling is that I like the existing board/ approach better, but
>> > I'm open to arguments.
>>

>
> My understanding is that currently we have:
> board/
>  $VENDOR/
>    $BOARDA
>    $BOARDB
>

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. 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.

Maybe we should look at moving CPU & SOC specific code from board/$VENDOR
into arch/ which will probably consolidate a lot of common code loitering
around in the various board directories.

And then there is also

board/
  $BOARDC
  $BOARDD

I've never liked code existing on multiple depths like this. Maybe we move
towards:

board/
  $VENDOR
    include/
    lib/
    $BOARDA/
    $BOARDB/
  $<cpu>_generic/
    $BOARDC/
    $BOARDD/

Any code that would otherwise live under $<cpu>_generic/[include, lib]
should (by definition) be moved to arch/$<cpu>/[include, lib]

Regards,

Graeme


More information about the U-Boot mailing list