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.