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.
//Peter