This is the most up-to-date patch on a board I have been struggling with
for over a month now I am posting this patch for both discussion and
inclusion.
The good part is we get to linux. The bad part is that linux gets bored
of waiting for the IRQs. The IRQs do not seem to work, at least, they
partially do not work.
This board is on loan from a friend, and I will have to give it back in
a few days. If I can't get it to work, I'd at least like my work to be
available for the next person who may want to get this model running.
The first obvious sign of something going wrong is the keyboard not
responding in SeaBIOS. Later, linux tells us:
"..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 0) ...
...... works."
message from linux.
This indicates to me that linux is setting up the timer as IRQ0 through
the i8259A, through the IOAPIC pin 0 as ExtInt, and to the LAPIC lint0
as ExtInt.
The mfg BIOS sets it up through the IOAPIC pin2, and it works.
We later see the i8259 IMR= fffa, which means IRQ0 (timer) and
IRQ2(cascade) are unmasked.
In the mfg BIOS, the IMR = fffb, which means that only IRQ2 is unmasked,
so the timer should be set up through the IOAPIC pin 2.
Under coreboot, linux finally says
ata3: lost interrupt (Status 0x58)
and dies.
Well, maybe it's just the IOAPIC acting up, so let's put a "noapic" in
the kernel arguments and see what happens. IRQs still do not work and
linux stops at the same error message.
The fact that the IOAPIC is accepting IRQ0 from the PIC means that the
IOAPIC should at least work as a VirtualWire, but the fact that
interrupts still do not work in "noapic" mode indicates the opposite. Is
it the IOAPIC acting up, or the i8259?
Maybe I'm looking at the problem from the wrong perspective. I'd
appreciate any suggestions or hints to get this board corebooting.
I'm also attaching the boot log from both coreboot and the mfg BIOS for
a more complete reference.
Alex