Stefan Reinauer stepan@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