[coreboot] ACPI S3

Feng, Libo Libo.Feng at amd.com
Wed Nov 26 11:44:22 CET 2008

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.

Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

-----Original Message-----
From: Peter Stuge [mailto:peter at stuge.se] 
Sent: Tuesday, November 25, 2008 11:05 AM
To: Feng, Libo
Cc: ron minnich; Li, Maggie; Bao, Zheng; coreboot at coreboot.org; Xie, Michael; Huang, FrankR; Wang, Qingpei
Subject: Re: [coreboot] ACPI S3

Feng, Libo wrote:
> Yes, the processor is running in the real mode, both HDT(AMD debug
> tool)

That is good.

> and machine code can verify it. The prefix of 0x66 indicates a 32bit 
> instruction to the processor which is running in the real mode,

Actually this is not the complete picture.

There is good information in AMD document 24594: "AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions", in particular section 1.2.2 on pages 4-5.

Quoting page 4: "The default operand size for an instruction is determined by a combination of its opcode, the D (default) bit in the current code-segment descriptor, and the current operating mode, as shown in Table 1-2. The operand-size override prefix (66h) selects the non-default operand size."

> however, the processor still executes the instructions in the 16bit 
> way.

One issue could be the D bit in the code segment descriptor as mentioned in the quote above. What does the GDT look like that you are using when switching back to real mode after coreboot is done?
And I think cs must also be reloaded after lgdt, but I may be mistaken about that.

> I will check how to support 32bit instruction set in the real mode.

Using the 0x66 prefix.

> And the code of wakeup.S is put here by Linux for resuming. When 
> system resumes, the processor must be in the real mode,

When the CPU starts executing again, coreboot will run. coreboot switches to protected mode as usual. To properly resume an operating system, coreboot must switch the processor back to real mode before jumping to the resume code that is in Linux wakeup.S. Rudolf has implemented this in the code he has contributed and I think you are already using parts of that. (That is good!)

> but you can see there are some 32bit instruction from either the 
> assembly code or the machine code.

There are 32-bit instructions also in real mode, so the assembly source code is OK.


More information about the coreboot mailing list