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

Wolfgang Denk
2003-05-26T19:48:59Z

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/

> > I think it is cleaner to do this kind of things in the makefile, but
> > it is not how the U-boot amkefiles are done.
>
> Best to get along with the team.

There are too many board / CPU dependend paramters to set, so I
decided to put this all in one header file per board.

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

> An alternative is to have the 386 code call mem_init as it resides in
> the BSP (board) directory and let that code decide where to go next.

Create a board specific init sequence, then.

For example, for PowerPC we have in "lib_ppc/board.c":

...
init_fnc_t *init_sequence[] = {
...
get_clocks,
init_timebase,
dpram_init,
env_init,
init_baudrate,
serial_init,
...
};

Assume this is just the default configuration (actually the code is
not that clean, but tis is what I have in mind):

Make this:

...
init_fnc_t *init_sequence[] = {
#ifdef CFG_INIT_SEQUENCE
CFG_INIT_SEQUENCE,
#else
...list of default init functions...
#endif
};

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

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

> Actually, I'd really like to explicitly name things that are part of
> the BSP with a BSP prefix. That way, successive programmers will know
> where to look for them.
>
> #define BSP_MEM_INIT ...

Please avoid such #define's when possible.

> > Sure, we should be able to share. No, I have not investigated how
> > that would be done. When I started the 386-port, I looked in a few
> > directories under cpu/* for what cpu/i386 should contain. All
> > CPU-subdirs I checked contined a serial driver, so I borrowed a
> > 16550 version (from the 405GP i think) and included it slightly
> > modified in cpu/i386.

This is NOT what you should do.

> Interesting. I'll post a message to the list to see if Mr. Denk is
> interested in this.

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

It is obvious that things like the serial driver for a 8xx SMC / SCC
port is highly hardware dependend so it actually makes sense to keep
this in a CPU specific directory.

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

> there is little chance I'll be able to write it in 1K. Have you
> looked at the composition of the loader to determine where the memory
> is spent?

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

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
Women are more easily and more deeply terrified ... generating more
sheer horror than the male of the species.
-- Spock, "Wolf in the Fold", stardate 3615.4