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

[Marc Singer]

On Mon, May 26, 2003 at 08:35:20AM +0200, Daniel Engstr?m wrote:
> On 2003.05.23 21:00 Marc Singer wrote:
> >Yipee!  It boots.
> Very good, now there are three of us.

BTW, I'm waiting on help from the manufacturer WRT flash programming
before I work to get Linux booting.  They've got a PLD in the way of
writing to flash.

> >  2) How would you expect to override mem_init on another x86 board?
> Conditional compilation of sc520_asm.S it is, after all, sc520-specific.
> The defines in sc520_asm.S and sc520.c are not there yet, but they should
> look like most othe U-boot code:
> 
> #ifdef CONFIG_SC520
> 
> .....
> 
> #endif

So, this means adding a constant to the include/configs file for my
board.  Right?

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

> >     It seems to me that we'd be better off with a BSP entry point for
> >     RAM initialization that calls the appropriate library
> >     function(s).
> 
> mem_init is the BSP entry point for RAM initialization. Calling library 
> functions
> before mem_init is done is not advisabe.

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.

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

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

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

> >  3) We ought to be able to share serial driver code between x86 and
> >     the risc processors as long as we abstract port accesses the
> >     way that the Linux kernel does.  Has this been discussed?
> 
> 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.

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

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

Cheers.