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

[Marc Singer <elf@buici.com>]

On Mon, Jul 07, 2003 at 04:20:41PM +0200, Wolfgang Denk wrote:
> In message <20030707002607.GA4106@buici.com> you wrote:
> > I'm porting u-boot to the Sharp KEV7A400 development board.  The CPU
> > has an ARM9 core with some Sharp and some ARM cells.  The existing
> > ARM920T cpu code has quite a bit of Samsung specific code in it.  So,
> > the question is this: how do we best handle development like this?
> 
> If this really becomes a problem I think we  might  create  processor
> specific  sub-directories  below  the CPU/* directory, i.e. something
> like
> 
>   	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>

> 
> >   2) There are some board-specific driver choices, e.g. serial driver,
> >      that sometimes appear in the CPU directory.  Perhaps these
> >      choices are best made in the board directory instead.
> 
> 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.

> Please name the files if you disagree.
> 
> >   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.

Cheers.