On Mon, May 12, 2014 at 12:13 PM, Peter Stuge peter@stuge.se wrote:
Why shouldn't coreboot do legacy initialization? What is the reason to be *less* compatible than possible?
The main question I had was whether enabling this set of interrupts could negatively impact other payloads. The goal of linuxbios and coreboot was always to do as little as possible, not act like a BIOS.
Simple example: if we enable all these interrupts, and a non-kolibrios payload boots, is there a chance that a broadcast packet could be picked up by the NIC and interrupt the non-kolibrios payload? Is there anything in there that is a one-way initialization that might make it harder for for _MP_, ACPI, MSI, or MSI-X?
I just want to hear that the answer is "no". I have yet to hear it. It's a pretty simple question.
And the question remains: why is it kolibrios can't just read the $PIR and/or _MP_ like everything else has somehow managed to do for 15 years? Why are we doing these config writes in coreboot when the OS should do them? And why are we doing this for *one* OS?
Especially given this grotesque example:
The NIC bus number is hard-coded at the moment. This needs fixing if the NIC bus number can change.
Are you seriously telling me you want coreboot to hardware the bus number for a NIC? That's a terrible idea.
In general, we've tended not to set up too much interrupt hardware for a simple reason: we do have lots of payloads, and the odds are very good if you do too much setup - you're wasting time - you're doing the wrong thing for the payload - it may confuse the payload you eventually boot.
So, I'd like to hear the answer to my first question.
Finally, we actually always tried from the beginning to no setup up IRQs. The emphasis was on creating the tables that let the payload do the right thing.
Communicating IRQ info to the kernel is what we've done; actually configuring the PIC is a violation of the early design goals.
ron