weighing in

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 18 Feb 2003, steven james wrote:
> 
> > A question there, we are still going to want early serial output. It's
> > ugly, but could special cases like that go into preram init? That does
> > look like a step back to what we have now, but it may be hard to help in
> > corner cases, and would allow for a neat and clean init for most chipsets.
> 
> yes, but I think the way we do it now is ok. You always need this strange 
> early stuff to get going. 

There are and always will be 2 specials cases.
- Ram initialization
- Console initialization.

Both of those will always need to be handled early in strange special ways.

The goal is to cleanup all of the rest of the code as much as
possible.  Especially at the point of making the code more reuseable.

Right now I have a larger number of initialization functions being
called from mainboard_fixup.  Those are the real functions that need
to be tackled.  The superio model comes close to handling those cases
cleanly.  The big issue with superio code is that we use one structure
for all possible static values, that is silly.

Another issue is irq allocation.  Currently if a card is plugged in
with a pci bridge on it we have broken pirq, and mptables.  So those
tables need to be generated a little more dynamically then we do now.

For each device if we have a linked list of structures listing
configuration information, we should have a clean model.   A linked
list may be overkill but it allows fairly generic things like irq
routing to be attached, which the device driver does not need to
process.  An alternative would be to have parallel trees of
information.

In addition as this settles out we want to export the entire
device tree in the LinuxBIOS table so the OS can do something with it,
if it feels like it.

Eric