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

Wolfgang Denk
2003-05-27T06:34:14Z

Dear Marc,

in message <20030526230836.GA2501@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.