CODEWITHSUNDEEP
assemblyx86fasmbochs
i.y.
i.y.

Reputation: 163

X86: protected mode, GDT, IDT

I've tried to execute simple kernel with a kolibri bootloader. It's being loaded into 1000:0000. I don't understand, what's wrong in this part:

...
; switch to PM
mov eax, cr0
or  al, 1
mov cr0, eax

use32
PROTECTED_ENTRY:
mov  ax, 00010000b  ; DATA
mov  ds, ax
mov  ss, ax
mov  esp, 0xFFFF

jmp $

mov  ax, 00011000b  ; VIDEO
mov  es, ax
mov  edi, 0

mov  esi, string
int 1

jmp $

'cause in debugger it looks like this enter image description here

What's going on here? Why ES and DS aren't being changed?

P.S. i'm trying to get this kernel working with kolibri loader: http://wasm.ru/article.php?article=ia32int

Upvotes: 3

Views: 1227

Answers (2)

ughoavgfhw
ughoavgfhw

Reputation: 39905

The processor does not automatically enter protected mode when you set the protected bit in cr0. It enters protected mode when cs is changed after that. The easiest way to do this is to insert a far jump immediately after writing to cr0.

mov cr0, eax
.db 066h
jmp CODE_SEGMENT:PROTECTED_ENTRY

use32
PROTECTED_ENTRY:

Hopefully I got that right. (I'm used to AT&T syntax.) That .db is an operand size override to allow a 32 bit address.

Upvotes: 4

Gunther Piez
Gunther Piez

Reputation: 30439

Tee debugger does disassemble the 32bit code (you told the assembler to generate 32 bit code with the use32 pseudo op) as 16 bit code. So the instruction mov ax, 10h is interpreted as mov eax, d88e0010h, where the d88e part is in reality the opcode for next instruction, mov ds,ax.

Similar for mov esp, 0xffff, which is interpreted as mov sp, 0xffff and the two additional zero bytes show up as the spurious add byte ptr... instruction.

What the processor actually executes, depends on its current state - is it in protected mode, real mode, flat mode etc. Look at the status registers to find out. Possibly you can tell the debugger to interpret the code different.

Upvotes: 3

Related Questions