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. > > Yes.
Yes. > 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 > though. 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 > flowchart Yeah, that would be a nice addition for the wiki. As for an API/flowchart, I currently only know of this very tiny "API" from src/sdram/generic_sdram.c: In auto.c (per-mainboard) you call * sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu); This, in turn, calls three functions which must be implemented by any raminit.c AFAIK: * sdram_set_registers() * sdram_set_spd_registers() * sdram_enable() Something similar, and more elaborate, for other types of RAM would be nice. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
signature.asc
Description: Digital signature
-- linuxbios mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
