Re: Protected Mode:

On 29 Jun 2006 16:58:21 -0700, pela.zris@xxxxxxxxx wrote:

I am trying to run some code to switch the processor from real mode to
protected mode. I am using an ICE to debug and have been able to trace
the execution.

I have a valid gdt and idt setup, however when I try to execute my
C-code after switching the 32-bit protected code, it looks like the CPU
is still trying to execute the instructions as 16-bit instructions.
The 16-bit execution causes some side effects which I can track, a ram
location is changed. The ICE's trace is based on an option (i.e
dissassembles in real or protected mode), so it is no help. Only the
side effect clues me into what could be going on wrong.

The BIOS initial comes up and sets a gdt but only for 16-bit
instructions, so I have to recreate the gdt I would like to use.

The code I am using is very similar to many of the example found on the
web. I just modified existing code from:
http://my.execpc.com/~geezer/os/

Any suggestion on what I can try?

Post your exact code, if possible. This isn't the kind of thing that
usually can be adduced from "very similar to" code.

Also, have you carefully examined your own code and compared what it
does (exactly, not approximately) to what Intel specifies in their
section on switching modes from real to protected? Do you flush the
instruction queue, for example, as you are supposed to? Do you reload
_all_ of the selector/segment registers _after_ you set up the GDT in
order to be sure that the internal cache is properly set up? There is
a special JMP that you need that I always code with DB in assembly, as
the MASM/ML assembler doesn't (I don't think so, anyway) have the
ability to properly code it? Etc. Do you fully understand the whys
and wherefores for each and every step?

Also, and finally, there are some opcodes that are interpreted
differently when present in 32-bit segments than when in 16-bit
segments. And I don't just mean _slightly_ differently. I mean,
entirely different registers, etc. Does your c compiler actually
generate the 32-bit opcodes, as designed for 32-bit segments?

Jon
.

Relevant Pages

  • Re: Protected Mode:
    ... I am using an ICE to debug and have been able to trace ... is still trying to execute the instructions as 16-bit instructions. ... The 16-bit execution causes some side effects which I can track, ... dissassembles in real or protected mode), ...
    (comp.arch.embedded)
  • Re: [pm] Strange cleanups in -test8 kernel/acpi/wakeup.S
    ... understand your generic plea for review, I fail to see how it would help ... > registers are in gdt ... you must reload the GDT in protected mode ... what you killed were debugging hacks. ...
    (Linux-Kernel)
  • Re: [pm] Strange cleanups in -test8 kernel/acpi/wakeup.S
    ... >> loading gdt. ... you must reload the GDT in protected mode ... what you killed were debugging hacks. ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: What is the purpose of %fs?
    ... application program during execution." ... In protected mode these registers hold indices into descriptor tables ... When you load one of these registers with an index that points to an invalid table entry, you get a General Protection Fault. ... I know that a useful and important value is read, as the rest of the function relies on this value, conditionally branching if that value or a value derived from that value has some property, uses that value as a base pointer for additional data reads, ... ...
    (comp.os.linux.development.system)
  • Protected Mode:
    ... I am trying to run some code to switch the processor from real mode to ... The 16-bit execution causes some side effects which I can track, ... dissassembles in real or protected mode), ...
    (comp.arch.embedded)