The low-level specifics of "init enough PCI to reach EHCI" and "init the DRAM controller" obviously differ between boards.
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.
For the EHCI PCI init I guess we will have to wait for experience and improve when we see problems,
Yes -- it helps to think about the problem before coding it, and to discuss the problems, though. Which we did. Let's move on now :-)
Perhaps we could do better with RAM init though.
Would a RAM init API make sense?
How different is SDRAM, DDR and DDR2 init on one controller compared to another?
Very different.
Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all?
Well the signals on the actual DIMM bus end up being very similar; the registers to set, and what they do, vary wildly.
If so, it would be nice to encode these init sequences into lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to implement.
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.
This is especially nice if there are many high-level steps. It will also help new ports and new porters a great deal since it wont be neccessary to learn all about RAM init before a new port -
To successfully (and correctly!) program any memory controller, you really have to know both how the supported memory types work, and how the specific memory controller works. In detail.
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, or some pseudo code; or we can just point to some port and say "this one is really good"). We shouldn't make the framework too stringent as boards/systems really do vary *wildly*.
Segher