OSDev.org

Posted: **Fri Oct 07, 2005 11:00 pm**

I am having problems loading a generic gdt
here is my code, along with my a20 enabler code incase that causes some problem
bochs reports that the index requested is greater than the limit which it says is 0 but it should be 3(or 24 bytes)

Code: Select all

[BITS 16]
jmp strt
tGDT:
;null;this is a generic gdt

dw 0
dw 0
dw 0
dw 0
;data
dw 0xffff
dw 0
db 0
db 0x92 
db 0xff
db 0
;code
dw 0xffff
dw 0
db 0
db 0x9A  
db 0xff
db 0

tGDT_END:

GDTR:
GDTsize DW 8*3-1
GDTbase DD tGDT


wkc:
xor al,al
in al, 0x64                   ; get kbd status
test al, 2                    ; is bit 1 clear?
jnz wkc                       ; if not wait some more
ret

halt:
mov byte [gs:0],al
mov byte [gs:1],0x04
cli
hlt

;; 'wait keyboard to be full' function ;;
wkf:
xor cx,cx
in al, 0x64                   ; get kbd status
test al, 1                    ; is bit 0 clear?
jz wkf                        ; if not wait some more
ret
strt:
;enable a20
cli

call wkc                   ; wait for kbd buffer to clear
mov al,0xd1                ; tell it we want to write to output port
out 0x64,al
call wkc                   ; wait again for kbd to clear
mov al,0xdf                ; set desired settings (A20 gate)
out 0x60,al                ; send value to data reg
call wkc                   ; wait for kbd to clear

mov cx,0x10
kbdwait:
xor ax,ax                  ; do anything
out 0xe0,ax                ; some mor nonsense
loop kbdwait               ; loop to waste time

;check if a20 was enabled
mov al,0xd0
out 0x64,al                 ; tell kbdc we want to read output port
call wkf                    ; wait for data to get in it
in al,0x60                  ; get it
test al,2                   ; test if A20 is on
jnz a20_on                  ; if it is clear, then it is off
mov al,'A'                  ; Error: A20 gate not enabled, halt pc
call halt
a20_on:

xor edx,edx
xor eax,eax

 ;says data not relocatable for 16bit stuff


mov eax,cr0
or al,1
cli
mov bx,0xb800
mov es,bx
mov bx,0
mov byte [es:bx],'h'
mov cr0,eax
[bits 32]
lgdt [GDTR]
mov bx,0x08
mov ds,bx
mov es,bx
mov ss,bx
mov gs,bx
mov fs,bx
jmp 0x10:t
t:

Posted: **Tue Oct 11, 2005 11:00 pm**

Well the first thing which may cause a problem is your GDTR

GDTR:
GDTsize DW 8*3-1
GDTbase DD tGDT

GDTbase is set to and offset from the begining of your boot sector and since I do not see you defining the ORG of your boot sector this means that when you load the GDTR the cpu will look for your GDT at say 0x0000:0x0003 ( the 3rd byte of memory ) and your GDT is not there it is at 0x07C0:0x0003 ( or 0x7C03 ) so you have two options either specify [org 0x7C00] or

patch your GDTBase with some simple code such as

mov eax, 0x07C0 ; what ever segment your in
shl eax, 4 ; multiply segment by 16 (like the cpu would )
add [GDTBase], eax ; update the GDTR to reflect where GDT is in mem

lgdt [GDTR]

Secondly, while this may or may not cause an issue it is not a good idea to set bits which are reserved for future use which you are doing in your GDT

;data
dw 0xFFFF
dw 0x0000
db 0x00
db 0x92
db 0xFF <-- you are settings a bit here which is reserved
db 0x00
;data
dw 0xFFFF
dw 0x0000
db 0x00
db 0x9A
db 0xFF <-- you are settings a bit here which is reserved
db 0x00

those are some of the first things i would fix from glancing at your code and they may not be the only things causing your problem however the should get you in the right direction.

Dave

Posted: **Wed Oct 12, 2005 11:00 pm**

he didnt say that this was the boot sector however your comment still applies

if it IS the boot sector you need the signature bytes at the end

if it IS the boot sector i would advise you to change that -- there is no reason to be enabling a20 and PM jumping in the boot sector -- it just makes it harder to write properly

Posted: **Wed Oct 12, 2005 11:00 pm**

JAAman wrote:he didnt say that this was the boot sector however your comment still applies

Well I was just assuming so the only change to my comment would 0x07C0 would need to be changed to whatever segment your code is loaded

Posted: **Wed Oct 12, 2005 11:00 pm**

i'm sorry if i wasn't clear: my 2&3 points were to hckr83

your assumption was perfectly logical

thats why i gave those tips, they aren't the problem but they could cause trouble later (if this is indeed the boot sector)

Posted: **Fri Oct 21, 2005 11:00 pm**

hmmm 10 days, only 2nd page
well there is a slight problem with lgdtp [gdtr] 16bit crap is not relocatable in coff which is the only format both nasm and ld supports

and you cant go to 32bit mode without a gdt so how in the crap do you do it there has got to be a better way than counting bytes

Posted: **Sat Oct 22, 2005 11:00 pm**

Is this code in your boot loader? If it is your boot loader are you linking this to your kernel or any C files?

Dave

Posted: **Sat Oct 22, 2005 11:00 pm**

it was as kernel code because i dont know how to make a fat12 bootloader and i cant find any that are 32 bit and work
so i got example code from a 16bit bootloader and made the last bit 32 bit with this code

Posted: **Sat Oct 22, 2005 11:00 pm**

Ok since this is your boot code there is no need to link it with ld. Just compile with nasm as a raw binary file making sure to set segment addresses and origin addresses as necessary. Your kernel does not need to be linked with your boot loader ( not saying you are, but just making sure your not ). Have your boot loader read in your kernel to where ever you please.

Secondly, there is no need to use a executable file format. You should be able to compile and link as raw binary with almost any compiler and linker.

OSDev.org

gdt help

gdt help

Re: gdt help

Re: gdt help

Re: gdt help

Re: gdt help

Re: gdt help

Re: gdt help

Re: gdt help

Re: gdt help