[PROPOSAL] enhanced table dumping

Eric W. Biederman ebiederman at lnxi.com
Tue Jan 18 09:44:00 CET 2005


Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [050118 12:51]:
> > I agree that there is an issue particularly with respect to
> > interrupts.  A lot of this has waited until we have the time to
> > do this properly.  
> 
> I agree. However I also think we are coming close to the point were
> the existing infrastructure is fine enough to handle distributed table 
> generation sanely.

Agreed.
 
> > > Autocreation of those tables should belong to the driver code of each
> > > supported device. 
> > 
> > No.  The devices should have no idea about the format of the data
> > we present to the user.  We should push all of the information into
> > the device tree so we can derive it from there.
> 
> This is certainly true. But it will require some extra layer to be
> introduced that is completely missing at the moment. Representation of
> IOAPICs in the device tree are completely missing at the moment for
> example. We will also need quite some extra information from the config
> files.

A small amount or we just get the devices to populate the IOAPICs.  
When the IOAPICs happen to be a pci device we already represent them.
When the path to an IOAPIC is something else we don't.  Devices
with well known programming interfaces need a little extra care
so we can report their well known resources properly.
 
> > No.  A write_tables method is bad.  We need to enhance the dynamic
> > device tree with irq information.  And possible with something like
> > pci class so we can recognize devices with well know software programming
> > interfaces.
> 
> ACPI has things like IRQ override entries in it's MADT. There are quite
> some other pretty exceptional situations of working around hardware
> layout and kernel design allowed by the specification. I am not sure how
> we want to associate information like this with a certain device. Is it
> part of the "mainboard" device then? I am scared that we have to invent 
> a proper representation of things like this, just to be able to convert
> it to acpi later on while in the end ACPI tables are simple to produce
> and on non-x86 the hardware and linux kernel is less broken.

Maybe.  Let's handle the sane cases and see where that puts us.  With
respect to irq handling we need enough information to route the interrupts
before Linux loads.  With the pirq and other interrupt routing tables
simply standing in the background.

> > > This would also allow to extend the generic information provided by the
> > > bridges, by adding such functionality to the mainboard specific code, so
> > > we won't end up with something that is worse than now in any case.
> > 
> > I think allowing additional work to be done at a per port level
> > is a valid critique.  I would prefer we leave it until we find an
> > actual need however.
> 
> This might be now, even though I am probably able to work around by
> factorizing the ACPI code seperating the table creator functions and the
> main function calling those. This one would go to the motherboard
> directory, next to mptable.c and irq_table.c.
> The problem I have is that I designed the ACPI code originally for the
> AMD Solo motherboard, and someone updated it to be useful on the Epia.
> But with every new motherboard there need to be different devices filled
> into the MADT.
> Say "then drop ACPI", but Linux is not able to boot this machine
> properly without ACPI. As sad as it is.

Hmm.  I had not seen that problem.  But the SOLO was always a weird
board.  Is this because linux has/had a bug in it's pirq table parser
and did not recognize the 8111?   Is the problem that we did
not get the fix pushed upstream?

> > > Roughly thinking, table_t could look like:
> > 
> > That is terrible.
>  
> :-)))) Which is why I kept myself from implementing it yet. 
> 
> > For a subset of the idea look at how we generate the cpu information and
> > the memory information directly from the LinuxBIOS table already.
>  
> Can you give me a quick pointer? I am not sure that i am looking at the
> right piece of code.

Sorry I don't have a good example handy.  I just know that for some
parts of the process we already do use the existing tables.  It is not
very sophisticated.

A good starting exercise would be to get the apics and ioapics into
the device tree (which requires not extensions) and simply hard
code the interrupt source information.  That should generate about
half of the interrupt routing table.
 
> > We need an internal format for the information that we can consume and
> > control, and enhance.  The fact that we are passing on that information is
> > secondary.
>  
> I agree, though plugging a good concept between 2 broken ones might be
> hard.

True.  But one small step at a time.  If we are lucky we won't have to
support the really broken ones.  And if not we will have enough momentum
to carry us through.
 
> > For IRQ routing something very like the work done with open firmware
> > is needed.  Open firmware actually cannot represent x86 irq routing
> > as there is it cannot handle a the separate descriptions of apic and
> > non-apic modes.  But otherwise it should be able to handle everything.
> 
> How does it handle APIC modes? If there is an APIC, I don't see any need
> to go non-APIC except for academical interest.

Open firmware reports interrupts as a property of a bus.  And then
those bus lines are hooked somewhere.

So there are two mapping steps.  Device to bus interrupt line.
Bus interrupt line to interrupt sink.  And if we can have multiple
interrupt sinks per bus we may be able to do model everything trivially.

And of course there is a simple default that the bus interrupt lines connect
up to their corresponding bus interrupts lines in the parent bus.

Consuming that and programming the appropriate interrupt routers would also
be interesting.

Eric



More information about the coreboot mailing list