Hi Andriy,
First, the hardware that I am talking about: it's a typical consumer system with a Family 10h AMD processor, SB700 southbridge and 780G northbridge: http://www.gigabyte.com/products/product-page.aspx?pid=3004#sp
What superIO is it?
What I want to achieve is to get an interrupt generated by a SuperIO chip (external to the chipset) delivered to a CPU as a NMI.
You could set a bit which enables NMI when IOCHKCK# is asserted. But, I guess the SuperIO wont generate it for you - unless you have own gadget.
So, the first thing I tried is simply to set the NMI delivery mode for the pin. Unfortunately, that does not work, the system gets reset as soon as the interrupt is generated. So, my first question is: can that be made to work at all?
Did you set vector to 0x0 ? Maybe it did not like the rest of the fields?
So, I decided to not give up and to try to use the legacy interrupt mode to get what I want. I think that that's how Linux NMI watchdog driver used to work. So, I programmed LINT0 and LINT1 for NMI delivery mode (on all cores, all two of them), enabled legacy PIC (I guess that it's built into the chipset) and made sure that the interrupt is unmasked. But absolutely nothing happened when the interrupt is generated. From this I concluded that the PIC is not connected to the CPUs.
The PIC is "connected" to CPU via LINT0 if set to extINT. Or through the entry in IOAPIC.
I think that this is an interesting discovery: PIC's configuration affects how the IO-APIC communicates to the Local APICs.
This has to do about Hypertransportspecification. Please have a look to
Table 103. x86 Interrupt Request Packet Format (HT spec version 1.1) There is this MT3 explained.
I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg 62h of device 20 function 0 in SB7x0 caught my eye. Namely, K8_INTR, MT3_Set and MT3_Auto bits. They all are about K8 INTR [NMI] message. On my system the register is set to 0x24, that is K8_INTR is set, but MT3_Set and MT3_Auto are not...
So, this just helps to generate right format to HT bus... maybe the CPU is confused... and you will need to change it. Now it should be more clear what the MT3 means.
In the coreboot source code I see that the register is set up with exactly the same value in src/southbridge/amd/sb700/early_setup.c. And, for what it's worth, bit 5 (0x20 mask) is documented as "reserved".
Could be that it is something unrelated - Maybe leftover from SB600, where the bit is documented. It has to do something with SMI on USB.
I hope that this was not a boring read.
Nope, it is was quite interesting. Why you need to trigger NMI by superIO? Maybe there is other solution. I think at least some silicon revisions of SB700 had some magic bit which was triggering NMI if written.
You can perhaps generate NMI using MSI/MSI-X or HPET (i tried with this)
Thanks Rudolf