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

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

[Wolfgang Denk]

Hello Custodians,

please note that I have applied Peter Tyser's "Reorganize directory
structure" patch series. This results in a massive change of the
directory structure.

Please make sure to sync your repsitories ASAP.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A mouse is an elephant built by the Japanese.

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

[Ben Warren]

Hi Wolfgang,

On 4/13/2010 2:23 AM, Wolfgang Denk wrote:
> Hello Custodians,
>
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.
>
> Please make sure to sync your repsitories ASAP.
>
>    
Please excuse my ignorance, but what's the best way to do this?  
git-merge with the main branch?
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
>    
regards,
Ben

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

[Stefano Babic]

Ben Warren wrote:
> Hi Wolfgang,
> 
> On 4/13/2010 2:23 AM, Wolfgang Denk wrote:
>> Hello Custodians,
>>
>> please note that I have applied Peter Tyser's "Reorganize directory
>> structure" patch series. This results in a massive change of the
>> directory structure.
>>
>> Please make sure to sync your repsitories ASAP.
>>
>>    
> Please excuse my ignorance, but what's the best way to do this? 
> git-merge with the main branch?

Hi Ben,

I do not know if there is a preferred or best way to do it, but in my
case a simple git-rebase with the main branch did the job ;).

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

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

[Ben Warren]

Hi Stefano,

On 4/13/2010 10:28 AM, Stefano Babic wrote:
> Ben Warren wrote:
>    
>> Hi Wolfgang,
>>
>> On 4/13/2010 2:23 AM, Wolfgang Denk wrote:
>>      
>>> Hello Custodians,
>>>
>>> please note that I have applied Peter Tyser's "Reorganize directory
>>> structure" patch series. This results in a massive change of the
>>> directory structure.
>>>
>>> Please make sure to sync your repsitories ASAP.
>>>
>>>
>>>        
>> Please excuse my ignorance, but what's the best way to do this?
>> git-merge with the main branch?
>>      
> Hi Ben,
>
> I do not know if there is a preferred or best way to do it, but in my
> case a simple git-rebase with the main branch did the job ;).
>
> Stefano
>
>    
Thanks.  I guess git-rebase would be better since that will put my net 
repo changes at the top.

regards,
Ben

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

[Wolfgang Denk]

Dear Ben Warren,

In message <4BC4AA08.1060608@gmail.com> you wrote:
> 
> > I do not know if there is a preferred or best way to do it, but in my
> > case a simple git-rebase with the main branch did the job ;).
...
> Thanks.  I guess git-rebase would be better since that will put my net 
> repo changes at the top.

Normally we try to avoid rebasing the custodian repositories, at least
their master branches which are being pulled from by many users.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Backed up the system lately?

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

[Remy Bohmer]

Hi,

2010/4/13 Wolfgang Denk <wd@denx.de>:
> Dear Ben Warren,
>
> In message <4BC4AA08.1060608@gmail.com> you wrote:
>>
>> > I do not know if there is a preferred or best way to do it, but in my
>> > case a simple git-rebase with the main branch did the job ;).
> ...
>> Thanks. ?I guess git-rebase would be better since that will put my net
>> repo changes at the top.
>
> Normally we try to avoid rebasing the custodian repositories, at least
> their master branches which are being pulled from by many users.

Funny...
The wiki (http://www.denx.de/wiki/U-Boot/CustodianGitTrees) tells the
opposite...

<quote>
#  Keep the uboot branch in sync with the master u-boot repository by
pulling it.
$ git checkout uboot
$ git pull git://git.denx.de/u-boot.git
# Rebase the master, testing and any "work in progress" branches to
the uboot to move work in progress changes "after" the uboot branch
(which should always reflect the One Repo to Rule Them All).
$ git checkout master
$ git rebase uboot
$ git checkout testing
$ git rebase uboot
</quote>

What am I missing here?

Kind regards,

Remy

> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Backed up the system lately?
>

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

[Wolfgang Denk]

Dear Remy Bohmer,

In message <u2w3efb10971004131332o428b7c60v380610f3fa8aa11c@mail.gmail.com> you wrote:
> 
> Funny...
> The wiki (http://www.denx.de/wiki/U-Boot/CustodianGitTrees) tells the
> opposite...

Ouch.

> What am I missing here?

This is somewbody else's working style, not mine.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Name one thing windows is better than unix in?
                                          Making money for Microsoft?
         -- Randal L. Schwartz in <8cvi5t4c3t.fsf@gadget.cscaper.com>

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

[Wolfgang Denk]

Dear Ben Warren,

In message <4BC4A09D.20201@gmail.com> you wrote:
> 
> > Please make sure to sync your repsitories ASAP.
> >    
> Please excuse my ignorance, but what's the best way to do this?  
> git-merge with the main branch?

Yes, or - which, assuming your main branch is current, is equivalent -
pull from the master branch of the mainline repo.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890@netlabs.com>

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

[Remy Bohmer]

Hi,

2010/4/13 Wolfgang Denk <wd@denx.de>:
> Hello Custodians,
>
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.
>
> Please make sure to sync your repsitories ASAP.

FYI: u-boot-usb has been synched.
Thanks.

Kind regards,

Remy

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

[Jerry Van baren]

Dear Wolfgang,

On 4/13/2010 5:23 AM, Wolfgang Denk wrote:
> Hello Custodians,
>
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.
>
> Please make sure to sync your repsitories ASAP.
>
> Thanks.
> Best regards,
> Wolfgang Denk

The "libfdt" u-boot-fdt has been updated.  There was nothing pending, so 
this was trivial.

Best regards,
gvb

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

[Michal Simek]

Wolfgang Denk wrote:
> Hello Custodians,
> 
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.
> 
> Please make sure to sync your repsitories ASAP.

Do you have any plan to move board dirs to arch folder too?

Regards,
Michal



> 
> Thanks.
> 
> Best regards,
> 
> Wolfgang Denk
> 


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

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

[Wolfgang Denk]

[cc: list trimmed as this is not that urgent any more]


Dear Michal Simek,

In message <4BC6BAD2.8040908@monstr.eu> you wrote:
>
> > please note that I have applied Peter Tyser's "Reorganize directory
> > structure" patch series. This results in a massive change of the
> > directory structure.
> > 
> > Please make sure to sync your repsitories ASAP.
> 
> Do you have any plan to move board dirs to arch folder too?

Speaking for myself: I have no such plans.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What's the sound a name makes when it's dropped?

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

[Peter Tyser]

> > > please note that I have applied Peter Tyser's "Reorganize directory
> > > structure" patch series. This results in a massive change of the
> > > directory structure.
> > > 
> > > Please make sure to sync your repsitories ASAP.
> > 
> > Do you have any plan to move board dirs to arch folder too?
> 
> Speaking for myself: I have no such plans.

A closely related topic was discussed here:
www.mail-archive.com/u-boot at lists.denx.de/msg20367.html

The conclusion was that grouping boards by vendor as opposed to CPU type
made sense so that the vendor's boards could share code and provide a
common "feel" across their supported platforms.  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.

Best,
Peter

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

[Wolfgang Denk]

Dear Peter Tyser,

In message <1271343853.6519.6.camel@localhost.localdomain> you wrote:
> 
> A closely related topic was discussed here:
> www.mail-archive.com/u-boot at lists.denx.de/msg20367.html
> 
> The conclusion was that grouping boards by vendor as opposed to CPU type
> made sense so that the vendor's boards could share code and provide a
> common "feel" across their supported platforms.  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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.

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

[Alessandro Rubini]

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.

Here a pair of arguments...

Most boards are very similar to the original evaluation kit.  For
example, within Nomadik, code for the Calao USB-S8815 is not much
different from code for the NHK8815 evaluation board. But Wolfgang
refused my patch as the files are very similar; I asked how to
proceed, with no reply so far.  Note that both board/calao and
board/st exist (board/st only has 1 board, though).

Similarly, I'm working on a dave-tech.eu board series based on
ep9302-ep9315.  board/edb93xx exists but "edb" is the evaluation
board; mine should be board/dave/zefeer (board/dave already exists),
though very similar to edb93xx code.

Hope these are arguments WD would consider. Moreover, vendors switch
names often, cpu families do it rarely.

/alessandro

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

[Peter Tyser]

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.
> 
> Here a pair of arguments...
> 
> Most boards are very similar to the original evaluation kit.  For
> example, within Nomadik, code for the Calao USB-S8815 is not much
> different from code for the NHK8815 evaluation board. But Wolfgang
> refused my patch as the files are very similar; I asked how to
> proceed, with no reply so far.  Note that both board/calao and
> board/st exist (board/st only has 1 board, though).
> 
> Similarly, I'm working on a dave-tech.eu board series based on
> ep9302-ep9315.  board/edb93xx exists but "edb" is the evaluation
> board; mine should be board/dave/zefeer (board/dave already exists),
> though very similar to edb93xx code.
> 
> Hope these are arguments WD would consider. Moreover, vendors switch
> names often, cpu families do it rarely.

I don't follow either argument, or the name-switching argument...  How
does putting boards in their appropriate CPU directory make your coding
any easier?  And why does vendors switching names make a difference?

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

Putting boards in CPU directories would result in something like:

arch/
  $ARCH/
    cpu/
      $CPU/
        board/
          $BOARDA
          $BOARDB

So the contents of $BOARDA directory are nearly identical whether its
located in board/... or arch/..., right?  I thought we were only talking
about organizational changes.  Are you talking about combining multiple
vendor's code into 1 file, as well as restructuring directories?  Maybe
an explanation of what you're envisioning would help.

Best,
Peter

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

[Alessandro Rubini]

>> Most boards are very similar to the original evaluation kit.  For
>> example, [...]

>> Similarly, I'm working on a dave-tech.eu board series based on
>> ep9302-ep9315.  [...]

> I don't follow either argument, or the name-switching argument...

Well, the name-switching is half a joke (but the philips 21xx is now nxp,
motorola went freescale and so on).

> How does putting boards in their appropriate CPU directory make
> your coding any easier?

Because if all boars with the same SoC are in the same directory they
can share source files. In my example, st/nhk8815 and calao/usb-s8815
had several files replicated -- so Wolfgang rejected the patch.  But
in a vendor-based structure I won't merge in a single board dir boards
from two different vendors. Same will happen for dave/zefeer where a
lot is in commong with edb93xx.

That's what the kernel is doing, actually. In arch-pxa, arch-at91 and
other directories at the same level I have board file and some files
that are used by several boards.  Some are SoC wide, so would fit in
cpu/ within u-boot, but some not (although, my fault, I'm not digging
for filenames to show).  I think there already is some replication in
u-boot currently, but I haven't stats right now.

On the other hand, having boards as subdirs of the same parent doesn't
automatically make replication go away, but at least may avoid new
replication in future boards

thanks for your patience
/alessandro

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

[Peter Tyser]

Hi Alessandro,

<snip>

> > How does putting boards in their appropriate CPU directory make
> > your coding any easier?
> 
> Because if all boars with the same SoC are in the same directory they
> can share source files.

But boards don't need to be in the same directory to share the same
source files.  You could pull out common code to arch/arm/cpu/* or
arch/arm/lib right now if you wanted, but that is the case whether the
board directories were in board/... or arch/....

> In my example, st/nhk8815 and calao/usb-s8815
> had several files replicated -- so Wolfgang rejected the patch.  But
> in a vendor-based structure I won't merge in a single board dir boards
> from two different vendors. Same will happen for dave/zefeer where a
> lot is in commong with edb93xx.

Could you give a specific example of how you'd like to final
directory/file structure to look like?  eg where would the code common
to the nhk8815 and usb-s8815 be located?  What would the file(s) be
named?  And how would the issue of vendors like Freescale which support
multiple architectures and share code between them be supported?

<snip>

> thanks for your patience

Likewise:)

Peter

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

[Graeme Russ]

On Fri, Apr 16, 2010 at 1:58 AM, Peter Tyser <ptyser@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

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

[Alessandro Rubini]

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] [STATUS] Heads-up: Reorganize directory structure

[Wolfgang Denk]

Dear Alessandro Rubini,

In message <20100416065842.GA21982@morgana.gnudd.com> you wrote:
> 
> > 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,

The Atmel code is a particularly bad example - I never understood why
each of these boards needs it's own copy of "led.c" or "partition.c".

We should not use bad examples as reference, I think.

> In theory you are correct. In practice, such platform independent
> material is using drivers/ .

This is not always true. There are examples for shared code across
different CPU families and even architectures. IIRC, board/keymile/
contains common code that is used on ARM and on PowerPC systems.
And board/tqc/tqm8xx/load_sernum_ethaddr.c is also used in
board/tqc/tqm8260/ - this code predates the creation of vendor
directories by many years, but it could/should be moved to a (to be
created) board/tqc/common directory.

All these examples do not belong into drivers, nor into any arch/cpu
directory.

> If there really was vendor-specific cross-platform code, I agree
> something like you suggest is best.

There is. See examples above.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"May your future be limited only by your dreams."
- Christa McAuliffe

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

[Wolfgang Denk]

Dear Graeme Russ,

In message <m2md66caabb1004151942s6ac4f444nac22bdccd128da6f@mail.gmail.com> you wrote:
>
> And then there is also
> 
> board/
>   $BOARDC
>   $BOARDD
> 
> I've never liked code existing on multiple depths like this. Maybe we move
> towards:

But we're just about adding exactly such multi-depth structures to
the CPU directory (see recent discussion about "ARM: reorganize
Cortex directory").

If you don't like this you should raise your voice in that thread.

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

I see not much benefit in artificially distributing the misc boards
into several directories. 

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

That makes even less sense to me. Such could would usually be highly
board specific. [There are of course lots of bad examples, where
generic code gets copied & pasted from one board directory to the next
one and so on, but factoring out such common code is a task that is
orthogonal to this discussion, i. e. it could be done in the existing
directory structure (or any other) as well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A morsel of genuine history is a  thing  so  rare  as  to  be  always
valuable.                                          - Thomas Jefferson

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

[Graeme Russ]

On Fri, Apr 16, 2010 at 5:41 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <m2md66caabb1004151942s6ac4f444nac22bdccd128da6f@mail.gmail.com> you wrote:
>>
>> And then there is also
>>
>> board/
>>   $BOARDC
>>   $BOARDD
>>
>> I've never liked code existing on multiple depths like this. Maybe we move
>> towards:
>
> But we're just about adding exactly such multi-depth structures to
> the CPU directory (see recent discussion about "ARM: reorganize
> Cortex directory").

Hmmm, but this move makes sense unlike the current board/ structure
(or lack thereof). In the ARM Cortex case, only cortex 8 code will
exist under arch/arm/cpu/cortex/a8. At the moment, nearly every
arch has a representative one level below board/

One could go as far as board/$ARCH/$VENDER with a board/$ARCH/generic
failover, but that means if a vendor wants to share code between
different arch's they are a little hamstrung. Going down this path
might lead one to think $ARCH/$BOARD/$VENDOR/ with $ARCH/$BOARD/generic
but this is a completely illogical place to look for a vendors board
because you should not need to know what CPU/SOC a vendor is using
for their board, just the vendor and board ID should be enough.

>
> If you don't like this you should raise your voice in that thread.
>
>> board/
>>   $VENDOR
>>     include/
>>     lib/
>>     $BOARDA/
>>     $BOARDB/
>>   $<cpu>_generic/
>>     $BOARDC/
>>     $BOARDD/
>
> I see not much benefit in artificially distributing the misc boards
> into several directories.

The problem with the current structure is that there is no way of
knowing which $BOARD in board/ uses a particular CPU or SOC. Therefore
when one goes looking for examples of how to implement their brand
spanking new super-duper board using SOC 'x' which does not exist under
a $VENDOR/ dir they have to 'go fish'. By moving all boards which use
the same CPU or SOC under a common folder, looking for an example board
is much easier. Maybe $[cpu, soc]-generic/ might be better

>
>> Any code that would otherwise live under $<cpu>_generic/[include, lib]
>> should (by definition) be moved to arch/$<cpu>/[include, lib]
>
> That makes even less sense to me. Such could would usually be highly
> board specific. [There are of course lots of bad examples, where

Board specific code would always live under $[cpu, soc]-generic/$BOARD

> generic code gets copied & pasted from one board directory to the next
> one and so on, but factoring out such common code is a task that is
> orthogonal to this discussion, i. e. it could be done in the existing
> directory structure (or any other) as well.

Exactly - Any code that exists under multiple existing $BOARDx dirs
which is only duplicated 'by bad example' and is, in reality, CPU or SOC
specific should be moved into the appropriate arch/ dir. Once the
/board/$[cpu, soc]-generic/$BOARD move has been been done, identifying
the duplicate code will be that much easier


Regards,

Graeme

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

[Wolfgang Denk]

Dear Graeme Russ,

In message <r2sd66caabb1004160445t8832c707w8ac6c7b903e1fd34@mail.gmail.com> you wrote:
>
> The problem with the current structure is that there is no way of
> knowing which $BOARD in board/ uses a particular CPU or SOC. Therefore

So look it up in the Makefile, or in MAKEALL - what's exactly the
problem?

> Exactly - Any code that exists under multiple existing $BOARDx dirs
> which is only duplicated 'by bad example' and is, in reality, CPU or SOC
> specific should be moved into the appropriate arch/ dir. Once the
> /board/$[cpu, soc]-generic/$BOARD move has been been done, identifying
> the duplicate code will be that much easier

Identification of such code has never been a real problem. The
problem is that it needs somebody to come up with patches to clean up
the mess. I doubt that the number of volunteers will significantly
grow just by reorganizing the directory structure.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Well, the way I see it, logic is only a way of being ignorant by num-
bers.                                 - Terry Pratchett, _Small Gods_

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

[Wolfgang Denk]

Dear Alessandro,

In message <20100415153127.GA628@morgana.gnudd.com> you wrote:
> > 
> > My gut feeling is that I like the existing board/ approach better, but
> > I'm open to arguments.
> 
> Here a pair of arguments...
> 
> Most boards are very similar to the original evaluation kit.  For

Some boards are different, others arent. I would not dare to say which
group is bigger.  In most cases the eval kit is something you don't
really want to replicate in your own design if you know what you are
doing.

> example, within Nomadik, code for the Calao USB-S8815 is not much
> different from code for the NHK8815 evaluation board. But Wolfgang
> refused my patch as the files are very similar; I asked how to
> proceed, with no reply so far.  Note that both board/calao and
> board/st exist (board/st only has 1 board, though).

Sorry if you are waiting for a reply  guess I missed that. But what
could I say in such a situation? That it makes sense to factor out
common code, of course.

> Similarly, I'm working on a dave-tech.eu board series based on
> ep9302-ep9315.  board/edb93xx exists but "edb" is the evaluation
> board; mine should be board/dave/zefeer (board/dave already exists),
> though very similar to edb93xx code.

I'm afraid I don't understand what you want to tell me, what the
problem actually is, or why it would be solved by moving to beoards
into arch/cpu/ ?

> Hope these are arguments WD would consider. Moreover, vendors switch
> names often, cpu families do it rarely.

Once a name was chosen, it is permanent. I haven't seen any
significant number of name changes in the whole history of PPCBoot and
U-Boot. And I don't see how this is relevant to the location in board/
or arch/cpu/ ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!

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

[Graeme Russ]

Wolfgang Denk wrote:
> Hello Custodians,
> 
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.

Just to let you know, the fix up for my i386 patch series was trivial:

#!/bin/bash

for file in ./*.patch
do
        mv "${file}" "${file}".old

        sed -e 's/lib_i386/arch\/i386\/lib/g' \
            -e 's/include\/asm-i386/arch\/i386\/include\/asm/g' \
            -e 's/cpu\/i386/arch\/i386\/cpu/g' < "${file}".old > "${file}"
done

With a minor tweak due to 'Change directory-specific CFLAGS to use full
path' patch. i386 built clean first go.

I ended up doing a complete system upgrade after SNAFU'ing my system
with a uname i686 -> i486 hack for building my target root fs :(

Will post revised patch set soon

Thanks Peter - loving the new layout

Regards,

Graeme