New x86 board booted...now the hard part

U-Boot-Users Marc Singer 3 participants 9 messages May 23, 2003 – May 27, 2003

lore

Share & tools

lore

Marc Singer

author

2003-05-23 19:00 UTC #0 lore raw

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?

Daniel Engström

2003-05-26 06:35 UTC #1 lore raw

Quoted 1 line · On 2003.05.23 21:00 Marc Singer wrote:

Yipee! It boots.

Very good, now there are three of us.

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 3 lines

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

Marc Singer

author

2003-05-26 19:09 UTC #2 lore raw

Quoted 3 lines · Daniel Engstr?m

Quoted 1 line · 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.

Quoted 10 lines

Quoted 1 line
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?

Quoted 2 lines

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.

Quoted 7 lines

Quoted 3 lines
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 ...

Quoted 10 lines

Quoted 3 lines
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.

Wolfgang Denk

2003-05-26 19:48 UTC #3 lore raw

Hello,

Quoted 9 lines · in message <[email protected]> you wrote:

Quoted 6 lines
#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/

Quoted 4 lines

Quoted 2 lines
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.

Quoted 5 lines

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

Quoted 2 lines

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

Quoted 4 lines

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

Quoted 9 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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

Signature · 5 lines

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

Marc Singer

author

2003-05-26 23:08 UTC #4 lore raw

Quoted 6 lines · Wolfgang Denk

Hello,
Quoted 3 lines · in message <[email protected]> you wrote:
Quoted 3 lines
#ifdef CONFIG_SC520

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
.....
#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.

Quoted 6 lines

Quoted 5 lines
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.

Quoted 6 lines

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.

Quoted 6 lines

Quoted 4 lines
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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 6 lines

Quoted 3 lines
#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?

Quoted 3 lines

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

Quoted 5 lines

Quoted 2 lines
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.

Quoted 2 lines

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.

Quoted 4 lines

Best regards,
Wolfgang Denk

Cheers.

Wolfgang Denk

2003-05-27 06:34 UTC #5 lore raw

Dear Marc,

Quoted 4 lines · in message <[email protected]> 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.

Quoted 6 lines

Quoted 1 line
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
_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.

Quoted 3 lines

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

Quoted 2 lines

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

Signature · 3 lines

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.

Marc Singer

author

2003-05-27 17:36 UTC #6 lore raw

Quoted 8 lines · Wolfgang Denk

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.

Quoted 2 lines

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.

Quoted 9 lines

Quoted 7 lines
Quoted 3 lines
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()
...

Quoted 2 lines

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

%^)

Wolfgang Denk

2003-05-27 20:08 UTC #7 lore raw

Dear Marc,

Quoted 6 lines · in message <[email protected]> you wrote:

Quoted 3 lines
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.

Quoted 10 lines

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

Quoted 1 line

MEM_INIT()

#endif

Quoted 1 line

...

OK with me.

Best regards,

Wolfgang Denk

Signature · 4 lines

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

Marc Singer

author

2003-05-27 20:30 UTC #8 lore raw

Quoted 7 lines · Wolfgang Denk

Dear Marc,
Quoted 4 lines · in message <[email protected]> you wrote:
Quoted 3 lines
2) If there is no such memory, you can probably lock some parts (or all of) the cache and (mis-) use this as memory.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 9 lines

Quoted 9 lines
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

Quoted 7 lines

Quoted 1 line
...
#ifdef MEM_INIT
Quoted 1 line
MEM_INIT()
#endif
Quoted 1 line
...
OK with me.

Excellent. That's what I'll do.

Thanks.