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

[Wolfgang Denk]

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/

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