From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marc Singer <elf@buici.com>
Date: Tue, 27 May 2003 10:36:33 -0700
Subject: [U-Boot-Users] New x86 board booted...now the hard part
In-Reply-To: <20030527063419.F1D3CC6162@atlas.denx.de>
References: <20030526230836.GA2501@buici.com> <20030527063419.F1D3CC6162@atlas.denx.de>
Message-ID: <20030527173633.GA7367@buici.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

%^)