[LinuxBIOS] Generic framework for early PCI and RAM init?
uwe at hermann-uwe.de
Mon Dec 4 03:39:59 CET 2006
On Mon, Dec 04, 2006 at 02:01:21AM +0100, Segher Boessenkool wrote:
> > Both these tasks will however share at least some code between
> > boards. It would be nice if we could re-use code instead of having
> > duplicates.
> An API that the memory controller code has to implement isn't
> going to work. Having a bunch of helper functions that the
> memory controller code can call as it wishes, is a good plan
Yes, I agree. For example there are lots of very similar functions
in current raminit.c implementations which deal mostly only with SPD
registers and don't even access any controller registers. Those are
perfect candidates to go into lib/spd or something.
But yes, we must make sure that we do not hard-code anything which might
work differently on more exotic systems...
> > only how
> > to do a certain task (eg. set CAS latency) on the given chipset,
> > which may be easier to find in the data sheet, or from vendor
> > support. Such an (internal) interface might make it easier for
> > chipset vendors to support LinuxBIOS too.
> It sure would help porting to have many nice helper hooks, and
> to have a clear overview what a new port should look like (a
Yeah, that would be a nice addition for the wiki.
As for an API/flowchart, I currently only know of this very tiny "API"
In auto.c (per-mainboard) you call
* sdram_initialize(sizeof(cpu)/sizeof(cpu), cpu);
This, in turn, calls three functions which must be implemented
by any raminit.c AFAIK:
Something similar, and more elaborate, for other types of RAM would be
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the coreboot