On 08/10/2016 20:35, Rudolf Marek wrote:
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?
On that system it's ITE IT8718F. On the other system that I tested (see my other post) it's IT8721F.
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.
Yes. Also, to answer another of your questions, I want to have an interrupt generated by the SuperIO's watchdog timer be delivered as an NMI.
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?
I double-checked, all the bits seem to be correct as only the NMI mode bit has to be set, all other have to be or can be zeroes: 0x0000000000000400 (using 64-bit format for two 32-bit registers of the redirection table entry).
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.
Well, I was talking about the physical level (or something close to it). Anyway, as it turned out I was wrong and the PIC is actually connected both to the LINT0 pin of the CPU and pin 0 of the I/O APIC.
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.
Thank you for the pointer! I will have a look.
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.
I will try to map those to the HT protocol details.
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.
Okay.
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.
As I wrote above, I want to create another variant of an "NMI watchdog". Watchdog timers in ITE SuperIOs are able to either reset a system or to generate an interrupt. I want to use the latter option to get the NMI.
You can perhaps generate NMI using MSI/MSI-X or HPET (i tried with this)
Actually, I tried that with SB700 and SB850 HPETs. I configured a timer for an FSB (=MSI, I guess) interrupt mode and set the delivery mode in the same fashion as I would for an MSI interrupt. The results were exactly the same as what I am getting when setting IO-APIC redirection mode to NMI. If you were able to get this stuff to work on a similar hardware, then I would appreciate your advice.
Thank you very much!