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

Wolfgang Denk wd at denx.de
Tue May 27 08:34:14 CEST 2003


Dear Marc,

in message <20030526230836.GA2501 at buici.com> you wrote:
> 
> 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.

This is a common problem. You need some working memory for an initial
stack.

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

I see. The usual problem.

So far there are two approaches in U-Boot to solve this problem:

1) Some devices provide on-chip memory which  can  be  used  to  hold
   initial  data  and  stack,  like the dual-ported RAM on MPC8xx and
   some other processors; depending on your hardware there  might  be
   other similar resources. Just a few kB are sufficient.

2) If there is no such memory, you can probably lock some  parts  (or
   all of) the cache and (mis-) use this as memory.

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

Please do not add board specific definitions to the Makefiles.

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

Right. If necessary, "drivers/serial.c" should be fixed to  work  for
x86, too.

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

Fine. So I found another supporter to back me when I strive for small
footprint.

Well, actually this means that you might have to omit features.  Once
you  got  network  support  working,  you  can probably throw out the
serial download support and things like that...

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

See the CFG_CMD_* def's in include/cmd_confdefs.h - all  of  this  is
configurable.

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
No user-servicable parts inside. Refer to qualified service personnel.




More information about the U-Boot mailing list