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

[Marc Singer]

On Mon, Jul 07, 2003 at 06:33:32PM +0200, Wolfgang Denk wrote:
> 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.

Now, I'm confused as to how this would work.  

In the CPU directory, there is a Makefile and several source files.
The Makefile staticly builds the sources and links a library.  This
library includes the primary entry point for u-boot.

If we want to have a sub-cpu directory, either we implement something
in the Makefile that selects source files or we use a goofy #ifdef
over the whole contents of a source file--tough for me not to
editorialize.

What I'd like to see is something much more flexible.  I'd like to let
the board directory & Makefile control the whole build.  In it, we
select the libraries and object file to link in order to get the
services we need.  This would allow, for example, a serial_lh7a400.c,
serial_ns16550.c, and so on to coexist where only one is compiled and
linked.

In another example, it seems that we don't share as much of the flash
code as we could.  Since most flash programming is always the same, we
could have a driver that is passed descriptive parameters for the
flash device and then handles all of the details.  And, here is where
the jump table comes in: my board has two kinds of flash.  With jump
tables, I can use both drivers without using function name tricks.

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

It seems to me that there is already some of this going on.  In
drivers/serial.c, there are calls to the NS16650_ routines.  Perhaps
there's some middle ground that makes sense.

Chiefly, I'm interested in making this all simpler.  I think that the
whole-file #ifdefs are not the best method for selecting code.  The
Linux kernel configuration stuff works well in selecting object files
for linking.

  obj-$(CONFIG_SERIAL_16550) += serial_16550.o
  obj-$(CONFIG_SERIAL_LH7A400) += serial_lh7a400.o

This way, we only compile and link the files necessary for each
configuration option.  It means that we can eliminate redundant code
(e.g. serial.c as well as serial-ns16550.c) as well as putting more
code into central locations.

That's for the serial driver.

There are other drivers, however, for which we may need more than one.
For example, I have two kinds of flash on my board.  I'd like to be
able to choose from a common set of flash drivers.  In this case, jump
tables make it possible to link more than one driver of the same type,
letting the board specific code handle board-specific setup.

BTW, I don't think that jump-table relocation should be a problem as
long as the file is linked to the target (post-relocation) load
address.  Still, I agree that for the serial driver there is no reason
for the dynamic dispatch afforded by a jump table.

Cheers.