ron minnich [mailto:rminnich@gmail.com] wrote:
]On Tue, May 13, 2014 at 5:29 AM, Peter Stuge peter@stuge.se wrote: ] ]> That's an important question, but I believe the answer is no. ] ]That's all I wanted to know, to start. ] ]So why don't we just get that CL in and see where we go from there. ] ]Thanks all. And sorry if I was too hard on kolibrios. It's totally ]wonderful that they are building a from-the-bottom-up OS that gives ]people a close view of how things really work. ] ]ron
Thank you and everyone for all the ideas and suggestions. Rudolf pointed out that coreboot already has an option for setting up the PCI config space 3C register: CONFIG_PIRQ_ROUTE. This initially looked like the proper way to enable the PIC mode routing code. On the other hand, experiments suggest this might not be the best way to do it.
Testing Ubuntu with the E350M1 OEM BIOS gives these results for the south bridge SATA controller:
grub options: acpi=off noapic debugger: clear SATA controller 3C register before Ubuntu boot. result: ahci 0000:00:11.0: can't find IRQ for PCI INT A; please try using pci=biosirq irq 10: nobody cared (try booting with the "irqpoll" option) Disabling IRQ #10 ata4.00: qc timeout (cmd 0xa1)
grub options: acpi=off noapic debugger: clear SATA controller PIC routing before Ubuntu boot. result: SATA operation is extremely slow. Apparently the SATA ISR is called occasionally due to interrupt sharing.
In PIC mode with acpi=off, the OS can only look at the MPS table or PIR table for interrupt info. These don't tell the OS what interrupt BIOS has assigned. In addition, the tables don't give enough info to allow the OS to program the interrupt itself. So to make Ubuntu work in PIC mode using MPS or PIR tables, both the 3C register and SB routing register must be setup by BIOS.
This leads to an argument that CONFIG_PIRQ_ROUTE shouldn't exist. Instead, the PIC routing and 3C reporting should be done any time the MPS or PIR tables are included.
Thanks, Scott
-
Scott Duplichan