Jamie Lokier wrote:
Sebastian Herbszt wrote:
>We could have qemu do a soft reset (not reload rom) on a triple fault
>or keyboard controller reset, and then have SeaBIOS request a hard
>reset (have qemu reload rom) if it detects a soft reset that is not a
>"resume" request.
>
>I'm also not sure what qemu does today.
I don't think such an interface would add a long time benefit and
would prefer a proper solution which will not tie seabios even more
to qemu. One day it might be possible to run a commercial BIOS on
qemu, just like it is possible on Bochs. Adding this interface
might prevent that.
What does a real BIOS on real hardware do?
Do real BIOSes make a decision as described above, and we're just
assuming they don't?
A real BIOS gets started, checks CMOS shutdown status byte and decides
whether to POST or resume execution somewhere else.
One way to answer may be: On a real PC with i440FX, what kind of reset
are the different reset methods (triple fault, keyboard etc.) normally
configured to do?
Should be those
power on -> hard reset
CPU shutdown bus cycle -> soft reset
TRC register (BISTE=0, SHRE=0, RCPU=1) -> soft reset
TRC register (BISTE=0, SHRE=1, RCPU=1) -> hard reset
keyboard controller -> soft reset
I/O port 92h -> soft reset
RC register (SRST=0, RCPU=1) -> soft reset
RC register (SRST=1, RCPU=1) -> hard reset
IIRC, HIMEM.SYS in DOS must use at least one of the
switch-to-real-mode methods to work, and that driver is needed by
Windows 3/3.11/95/98/ME, but I'm a bit vague on the details.
The highmem.sys version i got here seems to use CR0 to switch between real and
protected mode. I can't find where/if it loads a hosed IDT.
- Sebastian
