On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 +0100, Paolo Bonzini wrote:
Resuming from suspend-to-RAM should not reset all devices. Only the CPU should get a reset signal.
Hm... on reflection, I don't actually know if this is true.
Perhaps we *should* reset all devices. After all, in a real machine they'll all have been turned off and the RAM will have been in self-refresh. Surely they have to be reset?
So maybe we should *let* the i440FX PAM registers get reset to point to ROM. And fix the firmware to *cope* with that, check to see if the shadow RAM already holds an image of a started-up firmware with the correct checksum, and jump back to it.
That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work if the PAM configuration is reset?
I think it is indeed a problem with SeaBIOS. (git.seabios.org (80.81.252.135) seems to be down ATM, so I can only check at f465e1ec.) Open romlayout.S:
622 reset_vector: 623 ljmpw $SEG_BIOS, $entry_post
537 entry_post: 538 cmpl $0, %cs:HaveRunPost // Check for resume/reboot 539 jnz entry_resume 540 ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point
239 entry_resume: ... 248 // Call handler. 249 jmp handle_resume
handle_resume() [src/resume.c] inb_cmos(CMOS_RESET_CODE)
It checks the CMOS only after looking at HaveRunPost. The value of HaveRunPost depends on the PAM settings. It's always 0 in ROM, in which case we continue at handle_post() [src/post.c].
Laszlo