[U-Boot-Users] Question About New Board Support

[Jon Loeliger]

On Fri, 2004-07-16 at 16:59, Wolfgang Denk wrote:
> This is nothing specific to the Kieback &  Peter  boards.  There  are
> many of those:
> 
> 	board/esd/common
> 	board/mpl/common
> 	board/siemens/common
> 	board/emk/common
> 	board/dave/common
> 	board/Marvell/common
> 	board/altera/common
> 	board/xilinx/common
> 	board/ssv/common
> 	board/kup/common

These are all "kup" boards? :-)  Nah, I know what you mean...

> > Is this "kup" layout currently accepted as "good practice"?
> 
> Looks like it is :-)

OK, cool.


> Whatever makes sense. If you have closely related  boards  (like  all
> built  by  the same manufacturer) using very similar features, so you
> find yourself dumplicating lots of code, then a board/<vendor>/common
> directory is appropriate.

OK.

> Otherwise this is just another board, and files are kept separate and
> independend of other boards.
> 
> > I am proposing introducing the board/mpc85xx directory,
> 
> Rejected.

Uh, ok?

> > initially with support for my two new processors (and board),
> 
> Processor support does not belong into the board directory.

I think you misunderstood me.  The processor support itself
is still in the 85xx directory already.  These are specific
boards being introduced using the 85xx family of processors.

> > and eventually moving the rest of the MPC85xx based boards
> > into this structure.  This would likely include the MPC8540ADS,
> > the MPC8560ADS, the stxgp3 from Dan Malek, and possibly the
> > SBC8560 board as well.
> 
> No, this  doesn't  make  sense  to  me.  Feel  free  to  create  some
> board/freescale/common/  directory and use it for code that is common
> to all or many or even several of  the  Freescale  boards.  The  rest
> shall remain as it is.

But it goes beyond "freescale", perhaps.

I'm not changing the cpu/85xx directory for any of this.

Ultimately, much of this may actually boil down to a refactoring
of the so-called config file for the 5 85[46]0 ADS boards, and
the new ones that I need to release.  In my opinion, the shared
parts need to be factored out of all of these config .h files
into one common .h file for the family.

> If there IS redundand code that it used in  many  board  directories,
> then  it  was  a bad design from the beginning,

Well, at least we agree on that!

>  and should be cleaned up.

And that! :-)

>  We have the common/ directory for such general stuff  (like,  for
> example,  common/memsize.c whince once upon a time used to be part of
> most of the board/<board>.c files).

Understood.  I think what I am frustrated by here is the total
inability to introduce migratory changes directed toward cleaning
up some of the admitted areas that need to be fixed.  As another
example unrelated to this case, others have suggested that we
introduce some better structure around the flash devices, perhaps
even introducing a directory from which a particular device
implementation might be selected for a system via a configuration
mechanism.

In some ways, I'm interested in the same sort of approach where
we can introduce support for various different boards and families
of CPUs and mix and match them into complete systems.

I don't think you are going to ever see a one-patch-fix-it-all
from anyone.  It will take migration to a new scheme in order
to clean this up.  Introduce a change, allow people to see where
it is headed and how they can leverage it, then submit patches
into the new scheme.  That sort of thing.

Me just proposing changes in the blue is stupid.  It annoys us
both and no progress is made.  We need a way to talk about this
that allows for progress in a common, consistent and sane
direction.

I would like to constructively contribute to the process of
advancing this code base while introducing new systems that
have a variety of shared CPU families and board families.
Me just cloning and duplicating code with minor tweaks for
each new system is relatively painless at introduction, but
for maintenance it is deadly.  We have to get beyond that.

I would be interested in knowing where you would like to
make changes and how they might work.

> Best regards,
> 
> Wolfgang Denk

Thanks,
jdl