Turns out it's the same thread.
On Fri, Dec 01, 2006 at 11:15:16PM +0100, Segher Boessenkool wrote:
I don't think that the PCI initial setup for USB debug is going to be impossible
It is possible, sure -- *per board*. Anything generic would require a huge amount of code (and data).
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.
For the EHCI PCI init I guess we will have to wait for experience and improve when we see problems, all I can come up with is that the early EHCI finder could use common PCI functions, which it probably already does.
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? Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all?
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.
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 - 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.
//Peter