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

[Wolfgang Denk]

In message <20030707184116.GA26444 at buici.com> you wrote:
>
> > 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.  

Like allthe other source files are woking at the moment.

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

It's not exactly beautiful, but it's simple, and it works.

> What I'd like to see is something much more flexible.  I'd like to let

You pay a price for such flexibility.

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

There have been several discussions about things like this, or better
config tools, etc.

I need to see a working example  before  I  can  comment  on  such  a
suggestion.


> 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

Again, flexibility does not come for free. If  you  try  t  make  the
flash  driver  compile-time  configurable, it may easily end up being
unreadable. If you configure at run-time you  will  pay  with  memory
footprint.

We all know that automatic detection can be implemented, and where to
find existing  code  which  could  be  reused.  This  is  theory.  In
practice,  we're better off by just cloning and adapting an existing,
highly specialized driver. YMMV.

Again: I'll be happy to accept a better solution, but  it  must  meet
two requirements:

* It shall work on all existing boards.
* It shall not have a bigger memory footprint.

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

No tricks are needed. There are boards with two kinds of flash.  This
works fine as is.

> 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

I see, another round of config tool discussion. But this time  buttom
up :-)

> This way, we only compile and link the files necessary for each
> configuration option.  It means that we can eliminate redundant code
...
> 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

Feel free to submit a tested patch. I need to  see  working  code  to
have something I can criticize ;-)

> 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

No, it doesn't work that way. U-Boot is always  linked  to  the  pre-
relocation address in flash. The post-relocation address is not known
at compile time, as it may depend on things like RAM size.


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
This is a story about sex and drugs and Music with Rocks In.  Well...
...one out of three ain't bad.  Actually, it's only thirty-three per-
cent, but it could be worse.          - Terry Pratchett, _Soul Music_