[U-Boot-Users] Manufacturer specific code in a bothersome place

[Wolfgang Denk]

In message <20030707152907.GA2816 at buici.com> you wrote:
>
> >   	cpu/arm920t/s3c24x0/
> >   	cpu/arm920t/other_1/
> >   	cpu/arm920t/other_2/
> > 	...
> > 
> > What do you think?
> 
> OK.  Does this mean that the configuration line in Makefile says:
> 
>  ... arm arm920t/<subcpu> <boardname>

Probably not. Maybe we can solve this  by  a  #define  in  the  board
config file.

> > There should be no _board_-specific drivers in  CPU  directories.  We
> > had  this discussion before, and all such cases that I'm aware of are
> > really _processor_-specific drivers.
> 
> Perhaps I am misspeaking.  These serial drivers are chip specific.
> ARM920T, however, is *not* a chip.  The serial driver in the ARM920T
> directory is specific to the Samsung implementation.

Understood, and agreed. Should be cleaned up once we implement such a
change.

> > >   3) Drivers, such as serial, could be made to export a function
> > >      table.  This would allow driver selection by choosing which file
> > >      to compile and link.
> > 
> > Isn't this how it works right now?
> 
> The serial driver for the samsung chip exports serial_getc(void) and
> like routines.  It could export more generic routines using a jump
> table.  I think this is the same thing that happened with the x86
> port.

Which advantage do we get from an  additional  level  of  indirection
when the functions are known (getc, tstc, putc, puts) anyway? IMHO it
just  adds additional complexity (needs manual relocation) and wastes
memory.

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
How many NASA managers does it take to screw in a lightbulb?  "That's
a known problem... don't worry about it."