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

[Peter Stuge]

ron minnich 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.

That's an important question, but I believe the answer is no.

If the answer would be yes, how would all the software which we use
as payloads work with a legacy firmware? The ones which aren't
*exclusively* payloads (depthcharge comes to mind as an exception)
were originally running on top of a legacy firmware instead of after
coreboot, and they work.


> The goal of linuxbios and coreboot was always to do as little as
> possible, not act like a BIOS.

I understand your point and I agree with what you mean, but I don't
know if I agree that configuring interrupt routers lies squarely in
the legacy BIOS domain. But we might decide that indeed it does, in
which case we'll have to push PIC configuration into all payloads;
ie. SeaBIOS and libpayload at a very minimum. What about APIC config?
Why would we do one and not the other?

By their very design, they are compatible with each other. This is
why Windows XP can be installed in either "Standard PC" or "ACPI PC"
mode, and work, on machines with a firmware which configures both PIC
and APIC.


> 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?

Hang on - is enabling interrupts equivalent to configuring the
interrupt controller? I know that's not the case at least with the
PIC. I guess neither with the APIC.


> 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 don't think we should include a solution which goes in such a
direction unless it is only very temporary.

The things you mention are all younger than the PIC, so they have
already been designed to live alongside the legacy hardware.


> I just want to hear that the answer is "no". I have yet to hear it.
> It's a pretty simple question.

And it's a good one. I do believe that the answer is "no".


> 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?

It would be interesting to know exactly where it reads the interrupt
number. It might e.g. be calling the PCI BIOS services, and SeaBIOS
might be reading from a register which hasn't been programmed. (I'm
not saying this is the case, it's only one possibility.)


> Why are we doing these config writes in coreboot when the OS
> should do them? And why are we doing this for *one* OS?

I'm not sure that the OS should do them. And maybe more OSes need it,
just that they haven't been tested yet. I would certainly welcome
research into the matter, which is neccessary to build the required
data model for coreboot.


> >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.

No, I'm not telling you that I want that. I'm telling you that
coreboot needs to model hardware init completely and accurately.
It doesn't yet.


> 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

I can't take this too seriously, since it's a matter of a few
register writes.


> - you're doing the wrong thing for the payload
> - it may confuse the payload you eventually boot.

These are essentially the same point. I'm not at all sure that
configuring the PIC can ever be the wrong thing for any piece of
software which runs on a PC derivative.


> Finally, we actually always tried from the beginning to no setup up IRQs.

And boy how much trouble has been caused by that design decision. :\


> The emphasis was on creating the tables that let the payload do the
> right thing.

Which might have been fine, except unfortunately the payloads never
learned to use the tables, and the system doesn't just work<tm>.


> Communicating IRQ info to the kernel is what we've done;

We must of course still.


> actually configuring the PIC is a violation of the early design goals.

I either disagree with it being a violation, or I think the early
design goals were broken in this aspect. I'm not sure which it is
at this point, it could be either!


Thanks

//Peter