joe@settoplinux.org wrote:
What does Qemu do when 0xcf9 is sent to bios Stefan?
Hi Joe,
The I/O 0xcf9 is the "reset register" on most x86 systems. Writing certain values to it will cause a hard or soft reset. Qemu however does not emulate this behavior - as far as I can tell - it certainly does not while SerialICE is active, because all IO accesses go to the target (or are caught by LUA)
Basically what's missing in the LUA script to make resets via cf9 work properly is adding the following to SerialICE_IO_write_filter:
if port == 0xcf9 and data == 0x06 then SerialICE_system_reset() return false, data end
The serial communication code has been rewritten for the last release to be quite hick-up safe.. This means Qemu does not get out of sync if the target reboots, so all that needs to happen after a reboot of the target is to reboot the VM on the host, too, to let it start at the reset vector again... Otherwise it'll just try to execute code right after the out to cf9.. which is usually an endless loop as a safe guard.
Stefan
Stefan Reinauer wrote:
Basically what's missing in the LUA script to make resets via cf9 work properly is adding the following to SerialICE_IO_write_filter:
if port == 0xcf9 and data == 0x06 then SerialICE_system_reset() return false, data end
I will add this in one of the next commits. But I think it's time to start using the device tree code in LUA, or else it'll become too crowded with corner cases of my test machine, which currently has five or six "automatic loop skips":
if ( port == 0x60 and data == 0xaa ) then if ( regs.eip == 0xbd6d and regs.eax == 0x8aa and regs.ecx == 0x00fffff0 ) then -- Loop does IO at f000:bd6d. Execute the first 16 IO accesses printf("Skipping keyboard timeout...\n") regs.eax = 0x01aa -- ah is the outer loop counter regs.ecx = 0x0010 -- and the last 16 end end
Stefan
On December 5, 2009 at 11:31 PM Stefan Reinauer stepan@coresystems.de wrote:
joe@settoplinux.org wrote:
What does Qemu do when 0xcf9 is sent to bios Stefan?
Hi Joe,
The I/O 0xcf9 is the "reset register" on most x86 systems. Writing certain values to it will cause a hard or soft reset. Qemu however does not emulate this behavior - as far as I can tell - it certainly does not while SerialICE is active, because all IO accesses go to the target (or are caught by LUA)
Basically what's missing in the LUA script to make resets via cf9 work properly is adding the following to SerialICE_IO_write_filter:
if port == 0xcf9 and data == 0x06 then SerialICE_system_reset() return false, data end
The serial communication code has been rewritten for the last release to be quite hick-up safe.. This means Qemu does not get out of sync if the target reboots, so all that needs to happen after a reboot of the target is to reboot the VM on the host, too, to let it start at the reset vector again... Otherwise it'll just try to execute code right after the out to cf9.. which is usually an endless loop as a safe guard.
Yeh I know what 0xcf9 is, I just was not sure what Qemu did with it. Sweet! Great work Stefan! I will have to get my head out of my ass and try it out :-)
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org