From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Singer Date: Mon, 26 May 2003 16:08:36 -0700 Subject: [U-Boot-Users] New x86 board booted...now the hard part In-Reply-To: <20030526194904.1A85CC6162@atlas.denx.de> References: <20030526190904.GA7964@buici.com> <20030526194904.1A85CC6162@atlas.denx.de> Message-ID: <20030526230836.GA2501@buici.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.