[U-Boot-Users] New x86 board booted...now the hard part

[Marc Singer]

On Mon, May 26, 2003 at 09:48:59PM +0200, Wolfgang Denk wrote:
> Hello,
> 
> in message <20030526190904.GA7964 at buici.com> you wrote:
> > 
> > > #ifdef CONFIG_SC520
> > > 
> > > .....
> > > 
> > > #endif
> > 
> > So, this means adding a constant to the include/configs file for my
> > board.  Right?
> 
> Actually it means a board-specific header file in include/configs/

OK.  Right.  That's where I started.

> > Here is more specifically what I mean.  The present 386 code calls
> > mem_init which is a library function.  If I want to do something other
> > than mem_init, presently an Elan specific call, I need to ifdef on the
> > 386 code or replace mem_init by linking another function with the same
> > name.  I haven't verified that this works with the current Makefiles.
> 
> Have a look at the other architectures. The idea is to  have  a  list
> (or several list) of "init_*" functions; then just create an array of
> function  pointers which can be executed in sequence. Basicly you can
> put the initialization for this array in a board specific header file
> for maximum customization. [Think of the initialization  sequence  as
> some kind of FORTH word.]

That's what already exists in the lib_i386/board.c file.  The part I
am writing about preceeds C code.  This SDRAM controller must be
initialized in a chip-specific manner before we jump to C.

> > Conceptually, this is more clear than an ifdef since it concentrates
> > the board specific changes to a single directory.  However, I
> > recognize that this is problematic since we don't have memory for more
> > than one return address.
> 
> Oops? "memory for more than one return address"? Can't parse that...

Like the arm call instruction, ldr IIRC, we store the return address
in a register before jumping to a subroutine.  Should we make a call
within the subroutine, we would need some place to store that address.
At the point in time we are discussing, there is no RAM.

> > At a minimum, I think it would be helpful to rename mem_init to
> > mem_init_sc520 so that it is clearly a chip specific function.
> > Perhaps we'd be better off defining the name of the memory
> > initialization function in the config file.  That way, we avoid an
> > annoying series of ifdef's in the start code.
> > 
> >   #define MEM_INIT_FUNCTION mem_init_sc520
> > or
> >   #define MEM_INIT_FUNCTION mem_init_440bx
> 
> Name it mem_init, and implement mem_init() in a source file whichgets
> compiled only for sc520 boards.

Presently, this mem_init function is part of the lib_i386 library.
Are you OK with IFDEF's in lib_i386/Makefile?  Or, would you rather
this be put into the BSP directory somehow?

> _Generic_ hardware support like a driver  for  a  16550  UART  should
> exist only once, and in the drivers/ directory. And actually there is
> already a "drivers/serial.c" file which implements a 16550 driver.

Ah.  Then the serial driver (for the 16550) in the i386 directory
ought to be removed.

> > BTW, one of the things that concerns me is that the present 386 build
> > is about 1K shy of 128MiB.  There is some code I'd like to add, but
> 
> 128 MB ??? What the .... are you doing there? I guess this is a typo,
> and you mean KB instead? So is 128 kB a limit of some kind on x86?

Oh, my.  Yes, I meant 128KiB.  And yes, most x86 boards only provide
for 128KiB for the BIOS and, therefore, for u-boot.  Sometimes there
are opportunities to use more space, but that isn't guaranteed.

> See u-boot.map - this gives a good overview which objects  contribute
> significantly to the memory footprint.

I've looked through it.  It is difficult to tell (yet) whether or not
all of these pieces are needed.

> 
> Best regards,
> 
> Wolfgang Denk

Cheers.