Problem with 32bits data segment

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
raymond

Problem with 32bits data segment

Post by raymond »

Hello,

Since a few weeks I am working on a 32-bits kernel for
the Intel 386+ platform. There's one problem which I cannot
fix in my code. For a better understanding of the code,
I want to tell some specs about my kernel first:

The kernel is in the rdkernel.asm file at
http://rvtsoftware.webslice.nl/krnlproj/

rdkernel.inc is needed too..

The system boots up. The bootloader loads the kernel at address
0050:0000, which is equivalent to address 0000:0500 . So the entry
point of the kernel:

ORG     0x0500

The kernel starts in Intel CPU's real mode.

The kernel sets DS to 0 in an early state. After that, the kernel
changes the values for the GDTR register (which is a memory
operation). After the GDTR register is loaded with the LGDT operation,
a switch to Protected Mode is done by the following operations:


MOV     EAX,    CR0             ; Switch to Protected Mode
OR      AL,     1
MOV     CR0,    EAX

To flush the prefetch queue, a far jump is done to
CODE32_IDX:next . CODE32_IDX is the index for the 32-bits code
segment (4Gb, flat model).

DATA32_IDX is the index for the data segment. And here lies the
bug: This segment seems to be protected, because the system crashes
at the following operation:

mov     BYTE [DS:ESI], 'R'


I looked at the 'flags' byte in the 'data32_desc' descriptor,
but they seem okay. What could be the problem?
rverma

RE:Problem with 32bits data segment

Post by rverma »

HOW DOES YOUR DISCRIPTOR LOOK LIKE?
raymond

RE:Problem with 32bits data segment

Post by raymond »

Hello,

The descriptor for the 32-bits data segment looks like this:

data32_desc     dw      0xFFFF           ; 4 Gb data segment
                dw      0x0
                db      0x0
                db      0x92
                db      0xCF
                db      0

Somehow I fixed this bug. It seems that the far jump to CODE32_IDX:next
didn't work right. I changed it to 'jmp $+2' and the segment seem to work.
I think this is a strange kind of bug...
Post Reply