[LinuxBIOS] Adding IGEL-316 mainboard

Juergen Beisert juergen127 at kreuzholzen.de
Mon May 14 09:39:57 CEST 2007


On Saturday 12 May 2007 18:39, Uwe Hermann wrote:
> On Sat, May 12, 2007 at 05:29:59PM +0200, Juergen Beisert wrote:
> > On Saturday 12 May 2007 14:21, Stefan Reinauer wrote:
> > > * Juergen Beisert <juergen127 at kreuzholzen.de> [070511 23:11]:
> > > > Hi,
> > > >
> > > > attached the patch to add basic support for the mainboard in a so
> > > > called IGEL-316 graphical terminal. I'm not sure who the original
> > > > manufacturer of this mainboard is. It is labeled with "WINNET100 VER:
> > > > 1.1 (30-3130000-110)"
> > >
> > > Please dont put raminit into the mainboard specific code. It belongs to
> > > the northbridge code instead. Please implement this generic.

Yes it belongs to the northbridge, but the data it need to setup the SDRAM in 
a correct manner belongs to the board.

> > But how? Without access to the SPD EEPROM content, I need some way to
> > define board specific what kind of SDRAM is in use. And we need a way to
> > consider some board/layout specific things (delay values, load and so
> > on). To setup the SDRAM controller in a correct way we need all this
> > info. And this info is not generic!
>
> I think we can use the 'fake SPD' technique here, or am I wrong? See
> fakespd.c here for an examples (the code was removed, but is still in
> svn history):
>
> http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/m
>ainboard/amd/quartet/fakespd.c?rev=2545

It seems to find a generic way to configure the SDRAM in a Geode bases system 
is nearly impossible. At last we need some information about

- the physical behaviour of the mainboard (line load, line length for delay
  calculation, max possible SDRAM clock, jitter and so on)
- the type of connected SDRAM modules (soldered, SO-DIMM, DIMM -> line
  load/length!)
- the type of the SDRAM devices (timing requirements)

Maybe we are able to detect the SPD EEPROM on *some* boards. But never on all 
boards. There are too many individual incarnations how you can connect the 
I2C lines to your CPU (thanks to popconserve for the reference schematics!).
Mainboard's physical behaviour (I believe) you never can autodetect.
So we might need a filestructure you can try to autodetect things, or to 
hardcode most or all of the required settings. And then call ram_init with 
this data. Any idea? The faked-SPD alone does not help.

Juergen




More information about the coreboot mailing list