Rebooting machine without using KB controller
Yug3sh
does not work when I plug in a USB keyboard instead of the usual PS2
keyboard that I use.
My current reboot code is:
outp 0x64, 0xFE.
Does anyone have a way to reboot that does not rely on the KB controller and
does not require switching back to real mode?
TIA.
Alexei A. Frounze
You may also try a triple fault. That's not guaranteed to work on all
PCs, but on some does. Other than that there should be something in
the BIOS and ACPI.
Alex
Rod Pemberton
"Yug3sh" <__remove_...@yahoo.com> wrote in message
news:ucBSi.7056$lE2....@newssvr22.news.prodigy.net...
The keyboard and triple fault methods are the oldest methods. Intel
documented the triple fault method with their first cpu's. IBM created the
keyboard method for the PC. Without keyboard and RM, leaves three that I
know about. Alexei already mentioned the first (triple fault - method A
uses lidt instruction - documented by Intel). Although I only have one form
of B), I've seen B) in different forms. Apparently, different motherboards
and chipsets need the two bits of port 0x92 written differently. A) lists
how to disable NMI. C) combinations come from posts from various authors to
comp.lang.asm.x86 on this a while ago.
A) Intel lidt method:
a) disable NMI, (write 0x8D to port 0x70 (privileged), read port 0x71
(privileged) using 'in' and 'out' instructions)
b) disable interrupts ('cli' instruction)
c) lidt a null'd idt (write all 0's to idt and reload with 'lidt'
instruction, Ring 0 privilege)
d) enable interrupts ('sti' instruction)
e) call an interrupt (not using 'into' instruction, 64-bit obsolete)
B) IBM PS/2 fast reset
a) disable NMI
b) disable interrupts
c) write 0x01 to port 0x92 (privileged) (0x03 fails on some
machines...)
C) Intel PCI chipset reset
a) disable NMI
b) disable interrupts
c) write 0x02 to port 0xcf9 (privileged)
d) write 0x06 to port 0xcf9 (privileged)
4b)
mov dx, 0xCF9
mov al, 0x0E
out dx, al
4c)
; more reliable for some chipsets than 4b)
mov dx, 0xCF9
mov al, 0x0A
out dx, al
mov al, 0x0E
out dx, al
Rod Pemberton
Rod Pemberton
"Alexei A. Frounze" <alexf...@gmail.com> wrote in message
news:1192948664....@q3g2000prf.googlegroups.com...
> You may also try a triple fault. That's not guaranteed to work on all
> PCs, but on some does.
Please share. Which ones fail and why? Is the lidt instruction being used
on the failing machines? Are both NMI disable and cli being used?
Rod Pemberton
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:1192948664....@q3g2000prf.googlegroups.com...
>
> > You may also try a triple fault. That's not guaranteed to work on all
> > PCs, but on some does.
>
> Please share. Which ones fail and why? Is the lidt instruction being used
> on the failing machines? Are both NMI disable and cli being used?
>
> Rod Pemberton
I don't remember which. It has been long ago when I researched it and
I also think this has been discussed here and in other groups.
Alex
Wolfgang Kern
"Yug3sh" wrote:
> outp 0x64, 0xFE.
A sure way ? I use the RESET-button on my PC :)
serious now:
set bit0 on port 92h (bit1 == enableA20 on some machines)
asm:
CLI
IN al,92h
OR al,01
OUT 92h,al
INFIN:
jmp short INFIN ;to keep the reset line active until the CPU reacts
;and to avoid any further code execution.
but I have no idea why your keybd-controller method should fail,
except when there is no PS/2 connector present at all.
perhaps you don't wait and do something after your OUTp 64h,FEh ?
You could FARjump with a PM16 selector to the physical address
of the ROM-RESET routine at 000f_fff0h (if paging wont spoil this),
but this wont raise the RESET-pin for all connected hardware then.
Triple faults are an option too.
__
wolfgang
Rod Pemberton
"Mike Gonta" <mike...@gmail.com> wrote in message
news:1192961664....@z24g2000prh.googlegroups.com...
> On Oct 21, 1:13 am, "Yug3sh" <__remove__yug...@yahoo.com> wrote:
>
> > I recently discovered that my reboot code which relies on the KB
controller
> > does not work when I plug in a USB keyboard instead of the usual PS2
> > keyboard that I use.
>
> does not require an actual keyboard for the PC reset or A20 line.
> A simple triple fault method:
>
> lidt [$]
> int3
>
> No need to disable NMI or cli as any interrupt occuring after loading
> the IDT
> with a bogus value will cause a triple fault. The int3 garantees a
> triple fault.
>
>
(Supposedly), NMI needs to be disabled to prevent CMOS corruption upon
reset:
"Periodic Interrupts with the Real Time Clock" by Thiadmer Riemersa
http://www.compuphase.com/int70.txt
And, the cli is used to ensure the NMI in and out instructions aren't
interrupted.
Rod Pemberton
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:ffgddc$dpd$1...@aioe.org...
Actually, if we want to get really pedantic, we'd want to do:
1) disable interrupts with cli
2) disable NMI and set NMI to safe register [out 0x70,0x8d; in 0x71]
(ensure CMOS isn't corrupted)
3) make sure A20 is enabled (ensure all of BIOS is mapped)
4) set the CMOS 0Fh shutdown code to zero for full reset (ensure correct
reboot)
5) set the reset flag at 40:72 to 0 for cold boot (ensure correct reboot)
6) switch to RM (if not in RM), and jmp to FFFF:0000h (ensure any chipset
specific BIOS programming and reset method gets called and cpu in a reliable
state prior to reset)
Can we make this even more hardened and pedantic?
Rod Pemberton
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Yes, we can insert 5b):
5b) set lidt to RM address 0 limit 3ffh since IDT is relocatable on 386
(make sure IDT location is properly set)
Yes, we can add 7) and 8) and maybe 9):
7) zero MSR's 0x174/0x176 CS/IP for SYSENTER/SYSEXIT (???) (not cleared by
older BIOSes)
8) configurable shutdown via PCI Command Register i.e., Special Cycle
Recognition - bit 3 of PCI CR (reset PCI devices)
Yes, we can also list this one for the I/O port reset methods:
A) some MB's require hlt instruction for I/O port reset methods (some
chipsets won't reset cpu without cpu being in halt)
More? ACPI? reset CR0? cache?
Rod Pemberton
Yug3sh
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Thanks for the detailed list of options.
I've give these a try and see how it works out.
Yug3sh
"Mike Gonta" <mike...@gmail.com> wrote in message
news:1192961664....@z24g2000prh.googlegroups.com...
> On Oct 21, 1:13 am, "Yug3sh" <__remove__yug...@yahoo.com> wrote:
>
>> controller
>> does not work when I plug in a USB keyboard instead of the usual PS2
>> keyboard that I use.
>
> does not require an actual keyboard for the PC reset or A20 line.
> A simple triple fault method:
>
> lidt [$]
> int3
>
> No need to disable NMI or cli as any interrupt occuring after loading
> the IDT
> with a bogus value will cause a triple fault. The int3 garantees a
> triple fault.
>
>
>
> look and see - many look but few see
>
Thanks. There might be a problem in the way the chipset (on the board I use)
handles the PS2 KB controller. The reboot worked fine when I had a PS2
keyboard plugged in.
Yug3sh
"Wolfgang Kern" <now...@never.at> wrote in message
news:ffgaen$qv0$1...@newsreader2.utanet.at...
I'm not doing anything after sending the command to the KB controller. I
basically do a "while (1) ;".
Interrupts are enabled though... although, I'm not sure why that would be a
problem. I've never had a
problem rebooting with a PS2 keyboard attached.
It might be related to the way the chipset is emulating a PS2 keyboard with
a USB keyboard plugged in.
Cyril Novikov
> A) Intel lidt method:
> a) disable NMI, (write 0x8D to port 0x70 (privileged), read port 0x71
> (privileged) using 'in' and 'out' instructions)
> b) disable interrupts ('cli' instruction)
> c) lidt a null'd idt (write all 0's to idt and reload with 'lidt'
> instruction, Ring 0 privilege)
> d) enable interrupts ('sti' instruction)
> e) call an interrupt (not using 'into' instruction, 64-bit obsolete)
Does this also reset external devices, or just the CPU?
Rod Pemberton
"Cyril Novikov" <cnov...@mail.remove.this.ru> wrote in message
news:bJXSi.6251$y21....@newssvr19.news.prodigy.net...
From the archived NG posts I've read, the answer is mostly yes and
infrequently no. The information I have is somewhat vague or incomplete.
1) Intel originally documented this method of resetting the cpu for the
286.
2) saw a mention that there is a PC industry specification requiring that
the lidt reset method work... (Sorry, I don't know what it is or if it
exists.)
3) there are documented cases of some MB's which _won't_ reset using the
lidt method (old 286's, 386's, and early 486's)
4) the BIOS FFFF:0h startup routine _should_ reset all the devices in the
system
5) there is much debate that some PCI BIOSes don't reset the PCI devices...
6) the CMOS 0F byte and 40:72 byte may affect what devices are reset
7) no info on how EFI resets
8) lidt used by Freebsd after reset fails keyboard port, PCI port, and PS/2
fast. (I don't see code to reset devices.)
9) lidt used by Linux if reset fails with keyboard port. Depending on a
flag it may try other methods like I listed previously, EFI, or RM FFFF:0h.
(I don't see code to reset devices.)
Rod Pemberton
J de Boyne Pollard
That's the easiest of the lot: One calls the ResetSystem() function,
which is a standard firmware service.
Wolfgang Kern
Cyril Novikov asked:
AFAIK a triple fault will raise signals on the CPU's ERR#-pins, so it
will just depend on the main-board logic if this cause a master-RESET or
even a complete power down, but most chipsets activate the RESET line
for ~6 mS.
Similar behaviour for the HALT instruction, mobiles may enter sleep mode
while most desktops just wait for interrupt or idle slow for power-saving.
__
wolfgang
Rod Pemberton
"J de Boyne Pollard" <j.deboyn...@tesco.net> wrote in message
news:1193076837.1...@i38g2000prf.googlegroups.com...
> RP> 7) no info on how EFI resets
>
> That's the easiest of the lot: One calls the ResetSystem() function,
> which is a standard firmware service.
>
I meant that I didn't see any information from NG posts on reset the
computer as to what reset method EFI uses, not what EFI routine to call.
Does EFI use the keyboard controller, fast PS/2 port, PCI reset, lidt triple
fault, or some custom hardware or software reset for the chipset?
Rod Pemberton
Maxim S. Shatskih
No. Reset of external devices (like the hung CD burner) can only be done using
hardware reset switch.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih
IIRC Windows uses KB controller in its HalReturnToFirmware function even on
ACPI machines, so, it should work.
Maybe your initialization of KB controller is wrong.
Brendan
On Oct 23, 5:57 pm, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:
> > I recently discovered that my reboot code which relies on the KB controller
>
> IIRC Windows uses KB controller in its HalReturnToFirmware function even on
> ACPI machines, so, it should work.
>
> Maybe your initialization of KB controller is wrong.
No - his KB controller reset code doesn't work because his OS doesn't
support USB keyboards.... ;-)
When a USB keyboard is present the BIOS emulates a PS/2 keyboard (for
backward compatability purposes) using SMM. If his code doesn't
support USB keyboards, then it won't disable this "PS/2 keyboard
emulation", and therefore his KB reset code will be talking to the
BIOS's emulated PS/2 controller and not the real PS/2 controller.
Given that his reset code does work when a PS/2 keyboard is present
and doesn't work when a USB keyboard is present, it's safe to guess
that the BIOS's PS/2 keyboard emulation code (in it's SMM handler)
doesn't emulate keyboard reset correctly.
Cheers,
Brendan
J de Boyne Pollard
JdeBP> That's the easiest of the lot: One calls the
JdeBP> ResetSystem() function, which is a standard firmware service.
RP> I meant that I didn't see any information from NG posts
RP> on reset the computer as to what reset method EFI
RP> uses, not what EFI routine to call. Does EFI use the
RP> keyboard controller, fast PS/2 port, PCI reset, lidt triple
RP> fault, or some custom hardware or software reset
RP> for the chipset?
There is no need to care. The firmware's implementation of this
function is entirely private. (The 'I' in "EFI" stands for
"interface".) A motherboard vendor could choose, for example, to have
a reset mechanism that involved writing the text of the U.S.
Declaration of Indepedence in UTF-8 to port 0xCF9 with interrupts
disabled. Since the motherboard vendor also supplies the firmware
that is on the motherboard, it would supply firmware whose
ResetSystem() function did exactly that.