Jeff Garzik <[EMAIL PROTECTED]> writes:

> "Eric W. Biederman" wrote:
> > "Larry G. Linde" <[EMAIL PROTECTED]> writes:
> > > The pci enumeration is complete now.
> > I'm not certain what the differences are here.
> 
> I doubt that either one gets PCI setup 100% correct...
> 
> Speaking of PCI, it would be nice that, if the linuxbios implementor
> knows the PCI bus speed, that number gets passed to the Linux kernel. 
> In cases where PCI bus speed >33Mhz, this will make a difference.

Generally you can query the northbridge for that information,
but if you cannot linuxBIOS needs to provide it.

> > > The irq routing table gets passed to the kernel now.
> > LinuxBIOS also does this.
> > 
> > > Keyboard stuff.
> > > Lots of irq setup stuff
> > 
> > This is the only really big area of difference, but it is something
> > that we probably should have the option of doing in linuxBIOS so
> > it doesn't hurt.
> 
> IMHO this should be done in the firmware console piece, not in the
> linuxbios bootstrap piece.

There are 4 things that happen with devices:
1. Enumeration (So you can find it).
2. Resource Allocation (So you can program it)
3. Device Initialization (So you can use it)
4. Device Untilization (Actually using a device)

What happens and where reponsiblities lie is an interesting question.
What is clear is that in conjunction with the bootloader and the operation
system all of these things needs to happen.

Some of them must happen in linuxBIOS or things simply won't work,
some of them must happen during ram initialization or you can't turn
on ram.  For the rest at a minimum linuxBIOS must provide for them all
to happen.  Think ACPI here as that is the best general interface I 
have seen for this to happen.  I would like to avoid the interpreter
and make a ``light'' ACPI that is totally table driven but the idea
remains.

Since I currently don't know of a good open source implementation,
of the general hardware setup problem, achieving 1&2 on all devices.
As part of the linuxBIOS effort we need to implement something.  And
eventually the linux kernel needs to be updated.

As I see it what we need are a set of tables that act as a blue print
for the motherboard.  Giving how devices are connected.  This gives
the necessary information to setup irq lines and do many other
interesting things.

Since we must implement general device resource allocation, I would
like to keep the initial implementation within linuxBIOS proper.  Once
we understand what is needed we can move the code out to other places
where it belongs.  And simply not do it withing linuxBIOS.  But
we shouldn't do this until we understand the problem.

The tricky part of general resource allocation, and enumeration is
that you must initialize, and utilize some devices to enumerate
or allocate resources for others.  IRQ routing is a good example
you must setup the interrupt controller to allocate irq resources
to devices.

Creating a general solution to the problem is tricky, but it
is what we need to cleanup the mess in hardwaremain.c.

The basic loop needs to look something like:
while(unallocated_devices > 0) {
        unallocated_devices -= allocate_resources()
        initialize_resource_controllers()
        unallocated_devices += enumerate_devices()
}

With a pre-seeded list of devices on the mainboard this should be
enough to enumerate and allocate resources on every device in a PC
except where we don't have appropriate drivers for resource
controllers.  And the truly nice thing about this is that it very
neatly handles all of the extremely nasty ordering problems you can
get into.  Ron brushed this with his superio code but superio's are
most certainly not the whole situation.

Thoughts?

Eric

Reply via email to