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