On Sun, May 11, 2008 at 09:51:10PM -0700, ron minnich wrote:
At the very least, explain how the confusing thicket of LX interrupts is wired up,
So decode the mapping and input condition MSRs.
In the limit, we ought to be able to run this tool on a working system, compare it to a non-working system, and see what's different.
A small number (4 or 6) of MSRs really have all the information that is needed. Just dump them.
I don't actually see a difference from my end between an IRQ (Interrupt request in old-speak) and a PCI INT (interrupt request in old speak) but if you want to rename things, have at it.
INTA etc are the names of the signals on the PCB and in the socket.
A card yanking (e.g.) INTA should lead to a CPU interrupt. But which IRQ this interrupt comes in on, depends on which 5536 GPIO ball that PCI INTA signal from the socket has been routed to, and what those MSRs have been set to.
Code attached, do your worst!
Will have a look.
I will rename them too but at present I'm a lot more concerned with tracking down whatever is set up wrong on the alix1c. Something is just flat out wrong! We need to find it and I'm running out of time with the Berlin show looming.
Oh but I'm not sure we have any PCI cards anyway. I don't, at least.
You have to talk to VRs because VSA talks VRs, and when you Do Certain Things, VSA gets involved. So I am not inclined to ignore the VRs.
My point is that VRs are only a translation mechanism and a proven black box. VRs should not cause the problem, and in this case it is far better to avoid software translation since there is enough hardware translation already to cause confusion.
Better look at the MSRs directly, see what is up, fix it, and then VSA should work as usual.
Here's the latest version of the program together with alix1c output.
input enable 0f7af085 invert 0xcf7e3081 irqmap from vr is 0xd0c0700 4d1:4d0 0e00 Filter events: 0/00 1/00 2/00 3/00 4/00 5/00 6/00 7/00 IRQ A, GPIO pin 0 Input Enabled and Inverted IRQ B, GPIO pin 7 Input Enabled and Inverted IRQ C, GPIO pin 12 Input Enabled and Inverted IRQ D, GPIO pin 13 Input Enabled and Inverted
This looks much more correct than the last one.
So notice that it appears when coreboot sets the VRs for INTAB and INTCD, VSA is setting up the GPIOs as enabled and inverted. Useful to know.
Yeah, I mentioned this after going through VSA.
Next steps are to see how the 22/23 registers are set up, and, with luck, trace it all the way through and maybe even find the problem. For now, however, the 3v PCI slot INTs are not working at all, as far as I can tell.
I will try to test. Maybe I can find a 3v wifi card.
They're almost acting edge-triggered. I think it's an artifact of sharing PCI INTs with the USB
USB is 5536-internal and does not cause interrupts in the same way that the actual (external) PCI bus does. 5536 modules interrupt on PIC Unrestricted Y inputs, while PCI INTA..INTD come in on PIC Unrestricted Z inputs. They have individual mappings.
-- the ethernet, which is attached in the same way (with the same wire!) as the PCI slot, works just fine. It's very odd.
Have you tested/asked Pascal if/how INTA..INTD are swizzled on the 1c?
//Peter