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

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

[Marc Singer]

Yipee!  It boots.

I have a few questions.

  1) Daniel, do you think that the 'fs' overrides in mem_init are
     necessary when ds == fs?
  2) How would you expect to override mem_init on another x86 board?
     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). 
  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?

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

[Daniel Engström]

On 2003.05.23 21:00 Marc Singer wrote:
> Yipee!  It boots.
Very good, now there are three of us.


>   1) Daniel, do you think that the 'fs' overrides in mem_init are
>      necessary when ds == fs?
No, that's a left-over from AMDs 16bit code kit which need to use segment 
overrides.

>   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

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.

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

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

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

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

[Wolfgang Denk]

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

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

[Marc Singer]

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.

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

[Wolfgang Denk]

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.

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

[Marc Singer]

On Tue, May 27, 2003 at 08:34:14AM +0200, Wolfgang Denk wrote:
> 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.

There is none.

> 2) If there is no such memory, you can probably lock some  parts  (or
>    all of) the cache and (mis-) use this as memory.

This may be possible, but it seems to me to be a lot of work just so
we can 'call' the routine that performs the SDRAM controller setup.

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

Then how about making this single function a configuration definition
and fixing the lib_i386 to use that constant.

  include/configs/thisboard

#define MEM_INIT mem_init_sc520

  lib-i386/board.c

...
MEM_INIT()
... 

> Fine. So I found another supporter to back me when I strive for small
> footprint.

%^)

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

[Wolfgang Denk]

Dear Marc,

in message <20030527173633.GA7367@buici.com> you wrote:
> 
> > 2) If there is no such memory, you can probably lock some  parts  (or
> >    all of) the cache and (mis-) use this as memory.
> 
> This may be possible, but it seems to me to be a lot of work just so
> we can 'call' the routine that performs the SDRAM controller setup.

There is little choice. If you want to use C, you will have to  stick
to  the  ABI,  and  you  will  have to provide a working stack. For a
stack, you need some memory.

> Then how about making this single function a configuration definition
> and fixing the lib_i386 to use that constant.
> 
>   include/configs/thisboard
> 
> #define MEM_INIT mem_init_sc520
> 
>   lib-i386/board.c
> 
> ...
#ifdef MEM_INIT
> MEM_INIT()
#endif
> ... 

OK with me.


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
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

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

[Marc Singer]

On Tue, May 27, 2003 at 10:08:12PM +0200, Wolfgang Denk wrote:
> Dear Marc,
> 
> in message <20030527173633.GA7367@buici.com> you wrote:
> > 
> > > 2) If there is no such memory, you can probably lock some  parts  (or
> > >    all of) the cache and (mis-) use this as memory.
> > 
> > This may be possible, but it seems to me to be a lot of work just so
> > we can 'call' the routine that performs the SDRAM controller setup.
> 
> There is little choice. If you want to use C, you will have to  stick
> to  the  ABI,  and  you  will  have to provide a working stack. For a
> stack, you need some memory.

Hey, I want a stack as much as the next guy.

> > Then how about making this single function a configuration definition
> > and fixing the lib_i386 to use that constant.
> > 
> >   include/configs/thisboard
> > 
> > #define MEM_INIT mem_init_sc520
> > 
> >   lib-i386/board.c
> > 
> > ...
> #ifdef MEM_INIT
> > MEM_INIT()
> #endif
> > ... 
> 
> OK with me.

Excellent.  That's what I'll do.

Thanks.