ron minnich [mailto:rminnich@gmail.com] wrote:
]So, how would these changes affect other payloads? ] ]ron
The patch adds programming and one reporting mechanism for PIC mode PCI interrupt routing for the ASRock E350M1 board only. Without the patch, PIC mode PCI interrupt routing is not programmed and not reported. There are several ways an OS can find PIC mode interrupt routing for PCI devices: 1) $PIR table 2) ACPI 3) PCI config space interrupt line registers This change adds reporting method 3. Reporting methods 1 and 2 are incomplete or unimplemented for this board.
This patch programs PIC mode PCI interrupt routing to match the OEM BIOS. Without the patch, PIC mode PCI interrupt routing is unprogrammed. The changes affect an OS or other code that uses PCI interrupts in PIC mode. APIC mode is unaffected.
From what I can remember, older mainstream operating
systems normally use the ACPI method to find PIC mode interrupt routing. They might fall back to $PIR or even the config space line register method I suppose. I see some coreboot boards support the ACPI method of reporting (and modifying) PIC mode PCI interrupts. However I don't see this this code in E350M1 project. As a result, an OS such as Windows 2000 may or may not see improvement with this patch. I didn't try it. Linux still supports PIC mode PCI interrupt routing through grub options. I did not test that either. It seems interest in PIC mode interrupts has waned since multicore processors have become popular. A limitation of PIC mode interrupts is that all PCI interrupts are handled by the BSP core and cannot be routed to AP cores.
I know of one application that uses PIC mode PCI interrupts and finds them from the config space line register. It is the interrupt test portion of the Broadcom b57diag utility.
For operating systems, Windows dropped PIC mode starting with XP x64 edition if I remember correctly. XP 32-bit defaults to APIC mode, but can be switched to PIC mode during installation. After XP, all PIC mode is gone. For linux, PIC mode is still supported, but the default was switched to APIC mode several years ago. I believe there was a time with 32-bit Linux used PIC mode but 64-bit used APIC mode. This is from memory so I could be a little off.
Thanks, Scott
Thanks, that's a great explanation. Generally, we've tried to avoid too much hardware setup in coreboot; that's the job of the kernel. I'm not really happy that we're doing all this PIC setup for one OS, written in assembly. It's been quite some time since I've had to use PIC mode at all.
Why can't the Kolibrios just use modern standards? And why all this effort for an OS written in assembly anyway?
Unix v6 kernels were the same size as Kolibrios. They were written in C. That was 40 years ago. It's bizarre, to say the least, to be booting a kernel written in assembly from firmware written in C.
Hence, I find it hard to believe that we want this patch. But I'm wrong a lot, so if I am here too, just let me know.
ron