[coreboot] proposed patch, notsigned off, comments welcome.

[Peter Stuge]

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