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

[Wolfgang Denk]

In message <1090254334.10357.53.camel at blarg.somerset.sps.mot.com> you wrote:
>
> > > I am proposing introducing the board/mpc85xx directory,
> > 
> > Rejected.
> 
> Uh, ok?

Definitely rejected.

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

Either the code is board specific, and belongs to a board  directory,
or  it  is generic for many boards using the same CPU, then it is CPU
specific and belongs to the cpu directory.

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

I don't see a need for this.

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

This is a topic which comes up every now and then.  See  the  archive
for the rules that any new code must fulfill.

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

We have been doing this all  the  time  in  U-Boot,  and  in  PPCboot
before.

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

So far, we have a split in "cpu" and "board". This works more or less
well  in  most  cases,  except  for  ARM,  where  the  Linux   kernel
traditionally  splits  in architecture, processor and board. But this
is not what you mean.

I don;t really understand whatit is you are asking for. What are "new
systems that  have  a  variety  of  shared  CPU  families  and  board
families"?  And  why don't they fit into the existing "cpu" / "board"
setup?

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

Don't do it, then. Again, I don't see the problem:  "board/<vendor>/"
has been used for exactly this purpose for a long time.

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

I would not like to make any changes (yet) as I don't see the problem
(yet) that needs to be fixed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Marriage is the triumph  of  imagination  over  intelligence.  Second
marriage is the triumph of hope over experience.