What exactly does Proc32 do to port 0x92 during a shutdown sequence? My
PC104 system hangs after the countdown gets to zero around 50% of the time.
I’m informed this is due to the state of some internal line controlling the
flash memory. However, when I write a program to set the reset bit of port
0x92 it reboots 100% of the time. So I’m a little confused…
Julian Thornhill
we hit that port based on info from ibm/ps2 …
here’s the code path. there are several options…
here’s what the reboot code does…
fast_reset (-b2 to Proc) is the one that uses 0x92
/*-
reboot:
There are several ways to make a PC reboot; 3 are tried here.
fast_reset() – introduced in IBM PS/2 series; this appears to
be in most desktop machines, and some embedded.
Port 0x92 has a reset bit; the machine is reset on the rising
edge of bit 0. In early machines (PS/2 model 80), IBM advised
lowering bit 0 after raising it to mean “really reboot”; in
later ones removed this, but suggested the sequence only works
when the machine is in HALT with interrupts disabled. If it
doesn’t work we can’t recover.
kbd_reset() – the AT’s have a magic command, 0xfe to reset the
machine from the keyboard controller. Unfortunately, we have
to depend on the state of the keyboard controller.
The reset tries another sequence, command 0xd1 which allows the
keyboard controllers output bits to be modified directly.
The sequence produces a square wave on the reset line.
shutdown() – the processor is set into shutdown state by
cascading fault handlers. We invalidate the interrupt descriptor
table then invoke a trap. The trap faults, which faults, which
… AT’s monitor the processor state; if it is found in shutdown,
it is reset by the keyboard.
Before any of these are tried; interrupt 0xf5 is invoked. This
allows some external reset mechanism to be invoked.
*/
static
fast_reset()
{
unsigned x;
x = inb(0x92);
outb(0x92,x&~1); /* ensure is 0 /
usec_nap(2);
outb(0x92,x|1); / transition == reset */
usec_nap(2);
}
PC104 system hangs after the countdown gets to zero around 50% of the time.
I’m informed this is due to the state of some internal line controlling the
flash memory. However, when I write a program to set the reset bit of port
0x92 it reboots 100% of the time. So I’m a little confused…Julian Thornhill
–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579
- use int0xf5 so you are called before the regular handler (make a
software int handler)
How exactly do I code and install such a handler? I’ve had a look at resetf3
in usr/free, and bodged it to make it work for int 0xf5, but I feel there
ought to be a more elegant way. I’ve used qnx_hint_attach() for hardware
interrupts, but I guess this is not appropriate for software interrupts?
thanks
Julian Thornhill
at one point there was a movement to make the following work…
qnx_hint_attach( 0x200|0xf5, handler… )
but i would stick with hitting the idt directly if you take over 0xf5 as
per the nmi-example code.
Julian Thornhill <jth@ion.le.ac.uk> wrote:
- use int0xf5 so you are called before the regular handler (make a
software int handler)
How exactly do I code and install such a handler? I’ve had a look at resetf3
in usr/free, and bodged it to make it work for int 0xf5, but I feel there
ought to be a more elegant way. I’ve used qnx_hint_attach() for hardware
interrupts, but I guess this is not appropriate for software interrupts?thanks
Julian Thornhill
–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579