[PROPOSAL] enhanced table dumping

Eric W. Biederman ebiederman at lnxi.com
Tue Jan 18 01:26:00 CET 2005


Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> Porting LinuxBIOS to new motherboards has become easier and easier over
> the last period of time. There's almost no need for assembler coding
> anymore, Hypertransport featured systems do a completely automatical
> setup of their non coherent devices. On K8 systems even the coherent
> devices get initialized automatically. But there is still one major
> drawback when it comes to boot an operating system: Passing the
> information.
> 
> No, this is not going to be a discussion about whether this or that
> table is preferred. The problem is simply that for each motherboard
> these tables have to be redone over and over: The pirq table, the mp
> table and the acpi tables.

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.  

> This leads to hand made tables that often contain errors or have to be
> adapted with architectural changes that might have consequences wrt the
> bus numbering for instance.
> 
> * pirq tables do need knowledge that is not provided in the config files
>   yet (wiring)
> 
> * MP tables contain a static "compatibility part" and have to have
>   entries for devices on the bus and their interrupts. This is very
>   similar to the pirq table. But they also need information on available
>   APICs. These could be provided from the device tree. We know we have 
>   an 8131 in there, so we know 2 IOAPICs belong on the list. We also
>   know what busses hang off that 8131, so we can generate most of the
>   interrupt tables.

Yes.
 
> * ACPI tables need information on the Apics as well. Now the ACPI
>   implementation I wrote a longer while ago is completely static and
>   basically only works for systems with a single IOAPIC and not very 
>   well even on those.
> 
> 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.

> The information about the 8131 should come from the 8131 code, the
> information for the 8111 should come from the 8111 code, and so on.

Agreed.  The information should be associated with the device in
the device tree.
 
> The solution could be to enhance the struct device_operations by an
> additional member write_tables(device_t dev, table_t id) which can be
> subsequently called by each of the write_*_tables() functions, adding
> their part to the table. 

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

> Roughly thinking, table_t could look like:

That is terrible.

> Since everything is a device in LinuxBIOS, we could create these tables
> in a nice and ordered manner.
> 
> Comments? Flames? Better ideas? 

For a subset of the idea look at how we generate the cpu information and
the memory information directly from the LinuxBIOS table already.

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.

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.


Eric



More information about the coreboot mailing list