[coreboot] ACPI S3
jordan at cosmicpenguin.net
Wed Nov 26 17:03:26 CET 2008
Feng, Libo wrote:
> Hi, all,
> Thank you, Mr. Peter Stuge, The D bit is the key point. With other
> tricks, the system stepped into the 64bit operating mode, however,
> was lost at the line 224 of wakeup.S, as the below link.
> 222 movw $0x0e00 + '!', %ds:(0xb801a) 223 movq
> saved_eip, %rax 224 jmp *%rax
> I think saved_eip is stored prior to sleeping, so, now, I don't know
> where the system jumps into, which is totally random, depending on
> the system state just before sleeping. Now some traces can be sent
> out via serial port, I can't say it is resuming, for the system seems
> not fully working. Now I think resuming the system in the function of
> post_cache_as_ram is not a good idea. Few devices are initialized at
> this point. Rudolf's method is more practicable. I will try it later.
> Thank everyone again.
saved_eip should absolutely not be random - it is saved while the system
is going down (in save_registers). You should confirm with HDT that the
value in saved_eip is somewhat sane (i.e - pointing to somewhere else in
the kernel code space).
What other indications do you have that the system was "lost"? Remember
that you won't get back the video state due to silly behavior on the
part of the ATI GPU - but you should be seeing kernel activity on your
serial port, assuming that you have the kernel console enabled on your
Also, any reason why you are using kernel version 2.6.18 sources? IIRC,
the images you are using had a newer version of the kernel.
I recommend that you step as far as you can with HDT through the resume
process until you confirm that the system has re-entered the C functions.
More information about the coreboot