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
Il 05/03/2013 20:12, Laszlo Ersek ha scritto:
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. Open romlayout.S: [...]
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].
Actually, Peter explained that it is okay. S3 doesn't clear the PAM configuration, but S4 does. The PAM registers are attached to the same power line as the RAM.
Paolo
On 03/05/13 20:25, Paolo Bonzini wrote:
Il 05/03/2013 20:12, Laszlo Ersek ha scritto:
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. Open romlayout.S: [...]
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].
Actually, Peter explained that it is okay. S3 doesn't clear the PAM configuration, but S4 does. The PAM registers are attached to the same power line as the RAM.
Ah, you expect me to understand that "memory controller configuration" is a superset of the PAM registers :)
Laszlo
-
Laszlo Ersek -
Paolo Bonzini