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

Marc Singer
2003-05-26T23:08:36Z

On Mon, May 26, 2003 at 09:48:59PM +0200, Wolfgang Denk wrote:
> Hello,
>
> in message <20030526190904.GA7964@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.