[coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[ron minnich]

On Mon, May 12, 2014 at 12:13 PM, Peter Stuge <peter at 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