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! -- Andriy Gapon -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
