[LinuxBIOS] Generic framework for early PCI and RAM init?

Peter Stuge stuge-linuxbios at cdy.org
Sun Dec 3 19:28:05 CET 2006

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

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

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.


More information about the coreboot mailing list