Page 1 of 1

Booloader problem - suspected gdt problems

Posted: Mon Dec 12, 2005 3:03 pm
by 0Scoder
Ok, I've been writing a boot-loader recently (not all my code, I confess). With the help of candy I've almost got it running, but I just can't see around one last problem. Whenever I run my bootloader it gives a gpf and reboots (tested in bochs and normall PC). I've traced the error down to when ds is reloaded - suggesting a problem with the gdt.

Also, my bochsout gives this debug message:

Code: Select all

load_seg_reg: GDT: DS: index(0002) > limit(000000)
I know this problem will probably turn out to be a simple error, but I'm completely stuck!

Bootloader code is attached (yes, the [org 0] is supposed to be there (instead of [org 0x7c00])).

Main code (with disk access bits removed) is listed below:

Code: Select all

;*************************************************************************
      [BITS 16]
          ORG 0
          jmp     START
     
     OEM_ID                db "SCIOX-OS"
     BytesPerSector        dw 0x0200
     SectorsPerCluster     db 0x01
     ReservedSectors       dw 0x0001
     TotalFATs             db 0x02
     MaxRootEntries        dw 0x00E0
     TotalSectorsSmall     dw 0x0B40
     MediaDescriptor       db 0xF0
     SectorsPerFAT         dw 0x0009
     SectorsPerTrack       dw 0x0012
     NumHeads              dw 0x0002
     HiddenSectors         dd 0x00000000
     TotalSectorsLarge     dd 0x00000000
     DriveNumber           db 0x00
     Flags                 db 0x00
     Signature             db 0x29
     VolumeID              dd 0xFFFFFFFF
     VolumeLabel           db "SCIOX  BOOT"
     SystemID              db "FAT12   "
     
     START:
     ; code located at 0000:7C00, adjust segment registers
          cli
          mov     ax, 0x07C0
          mov     ds, ax
          mov     es, ax
          mov     fs, ax
          mov     gs, ax
     ; create stack
          mov     ax, 0x0000
          mov     ss, ax
          mov     sp, 0xFFFc
          sti

    ................
   
wait1:   in   al, 64h      
   test   al, 2      
   jnz   wait1      

   mov   al, 0xD1   
   out   64h, al      
wait2:   in   al, 64h      
   and   ax, byte 2
   jnz   wait2

   mov   al, 0xDF   
   out   60h, al      

pmode:
;==========Into PMODE!==========
mov eax,cr0         
or al,1         
mov cr0,eax

;==========Load the General Descriptor Table==========
lgdt[GDTR+31744]  ;add on 0x7c00, as compiler thinks we are at address 0, which we are not...
;==========Reinitialize all registers for jump into Kernel==========

mov eax,0x10      
mov ds,eax      
    cli                ;Computer reboots before this instruction - this should show if it's been fixed, incase there are more errorneos instructions below
    hlt
mov es,eax
mov fs,eax
mov gs,eax
mov ss,eax
mov esp,0xfffc      
         ;this changed by shaz and
         ;Pype.Clicker. 0xfffc is
         ;the new figure because 0xfffc is divisible by 4
         ;and the entire stack can be aligned (making it
          ;faster)

jmp CODESEL:switch

     .................

     absoluteSector db 0x00
     absoluteHead   db 0x00
     absoluteTrack  db 0x00
     
     datasector  dw 0x0000
     cluster     dw 0x0000
     ImageName   db "KERNEL  BIN"

[BITS 32]
switch:

jmp CODESEL:0x100000   

hlt         


;==========DATA (GDT) AREA==========
GDTR:            
GDTsize DW 0x18   
GDTbase DD GDT+31744          ;add on 0x7c00 - as we are org 0  (wrong)

GDT:
NULLSEL         EQU $-GDT 
      DD 0x0         
      DD 0x0
CODESEL          EQU $-GDT 
      DW     0xFFFF          
      DW     0x0              
      DB     0x00             
      DB     0x9A             
      DB     0xCF            
      DB     0x00             
DATASEL          EQU $-GDT  
      DW     0xFFFF           
      DW     0x0              
      DB     0x00             
      DB     0x92             
      DB     0xCF             
      DB     0x00              
GDTEND:
          TIMES 510-($-$$) DB 0
          DW 0xAA55
;*************************************************************************
Thanks in advance for any help,
OScoder

Re:Booloader problem - suspected gdt problems

Posted: Mon Dec 12, 2005 4:17 pm
by Candy
OScoder wrote: Ok, I've been writing a boot-loader recently (not all my code, I confess). With the help of candy I've almost got it running, but I just can't see around one last problem.
Was afraid of this, you ran off quite quickly that last chat. Thought of one last thing I needed to tell you:

Code: Select all

<snip>
;==========Load the General Descriptor Table==========
lgdt[GDTR+31744]  ;add on 0x7c00, as compiler thinks we are at address 0, which we are not...
;==========Reinitialize all registers for jump into Kernel==========
<snip>
;==========DATA (GDT) AREA==========
GDTR:            
GDTsize DW 0x18   
GDTbase DD GDT+31744          ;add on 0x7c00 - as we are org 0  (wrong)
<snip>
Modify to :

Code: Select all

<snip>
;==========Load the General Descriptor Table==========
lgdt[GDTR]
;==========Reinitialize all registers for jump into Kernel==========
<snip>
;==========DATA (GDT) AREA==========
GDTR:            
GDTsize DW 0x18   
GDTbase DD GDT+7c00h          ;add on 0x7c00 - as we are org 0  (wrong)
<snip>
Explanation: The lgdt command uses the SEGMENTED memory location (that is, with 0x7c0 segment) to look for the GDT pseudo-descriptor. It loads it, and sees the values in it as LINEAR memory locations for the GDT. So, the first need not have the 0x7c00, but the second does need it.

Re:Booloader problem - suspected gdt problems

Posted: Tue Dec 13, 2005 2:04 pm
by 0Scoder
Ok, that fixed it at last. Also I had the wrong address in the kernel to jump to, but I noticed that one myself. Thanks again candy, how many times is that you've fixed my os now?