Early NMI handling...

[Solar]

A quote from the Intel manuals, Vol. 3, chapter 9.7.2 "NMI Interrupt Handling":

The NMI interrupt is always enabled (except when multiple NMIs are nested). If the IDT and the NMI interrupt handler need to be loaded into RAM, there will be a period of time following hardware reset wen an NMI interrupt cannot be handled. During this time, hardware must provide a mechanism to prevent an NMI interrupt from halting code execution until the IDT and the necessary NMI handler software is loaded. Here are two examples of how NMIs can be handled during the initial states of processor initialization:

* A simple IDT and NMI interrupt handler can be provided in EPROM. This allows an NMI interrupt to be handled immediately after reset initialization.

* The system hardware can provide a mechanism to enable and disable NMIs by passing the NMI# signal through an AND gate controlled by a flag in an I/O port. Hardware can clear the flag when the processor is reset, and software can set the flag when it is ready to handle NMI interrupts.

OK, so this is BIOS / chipset / motherboard voodoo. I understand why Intel doesn't actually tell the BIOS manufacturers how to do their work, in their CPU manuals, but...

...I still don't have a clue what actually happens if a NMI hits during early startup. I don't like to take chances ("won't happen too often...") so I am asking for experience, additional info links, whatever...

???

[Pype.Clicker]

afaik, NMI are only available in debugging platforms ...

[Tim]

Put some hardware on the motherboard and disable NMIs at power on. Have the BIOS enable NMIs when it's ready to handler them.

[Solar]

...but since I'm writing an OS, not creating some hardware, the latter is not an option.

My question was more like, how do the existing boards handle it?

From your responses, I learn that, in your project(s), you assumed that no NMIs would trigger during early startup, and that it worked so far?

[Pype.Clicker]

actually, it did worked. there is also a way to "mask" NMI before they reach the PIC using 0x7x ports, iirc.

[Whatever5k]

Right, Pype:

Code: Select all

#define ENABLE_NMI 0x00
#define DISABLE_NMI 0x80

inline void enable_nmi(void)
{
  out(0x70, ENABLE_NMI);
  in(0x71);
}

inline void disable_nmi(void)
{
  out(0x70, DISABLE_NMI);
  in(0x71);
}

[Pype.Clicker]

this sounds like the realtime clock is actually responsible for controlling the NMI line (through the mentionned AND gate
If this is the case, it is likely that the rtc takes care of keeping the NMI masked at system boot up, until the BIOS defines an NMI handler and installs a realmode handler for NMI.

iirc, NMI is exception #02 (isn't it ?), or interrupt 2 in realmode. This means that all you have to take care is that a NMI handler is ready in your IDT at the time you issue the lidt [...] command. As interrupts are always taken on an instruction limit, i guess it should handle any case properly (provided that the BIOS did its job too)

[Solar]

That somewhat settles my worries. Thanks for the info!

[Slasher]

its better to read port 0x70 and then OR the byte with 0x80 (128) to enable NMI or if you want to disasble it And the byte with 0x7F (127)
because port 0x70 and 0x71 control other things
and then write the result into port 0x71. This way you will only be changing the bit you really want and not the whole register.