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

Segher Boessenkool segher at kernel.crashing.org
Mon Dec 4 02:01:21 CET 2006

> 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,

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

> 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*.


More information about the coreboot mailing list