Possible addressing problem

[GenHornet18]

Well I'm back to writing my bootloader after my kernel grew beyond the size limits I had first used when loading sectors. I think I have corrected it to load one sector at a time and increase the address until it loads the right amount of sectors. I seem to be having a number of errors with addressing specifically with; the GDT and protected mode jumps. I'm hoping you can provide some insight into why these addresses are off, or why exactly it's not jumping correctly (it may be something with my original ORG or registers too, something just doesn't add up...).

my bootsector works fine, and transfers control to this second stage, which is to load the kernel, enter protected mode and transfer control to the kernel:

Code: Select all

[BITS 16]
[ORG 7E00h]

jmp 0000h:Setup

Setup: 
   xor AX, AX           ;set segments and switch to text mode
   mov DS, AX
   mov ES, AX
   mov SS, AX
   mov SP, AX

   mov AH, 00h
   mov AL, 03h
   int 10h
  
   mov [BootDrive], DL
   lea SI, [TITLE]
   call PrintS
jmp Main

BootDrive db 0

Main:
   mov CL, 05h
   mov DL, [BootDrive]
.reset:                  
   xor AX, AX                   
   int 13h 
   jz .read
   sub CL, 01h            
   jnz .reset
   mov AH, 01h
   jmp Error
.read:
   mov AX, 1000h        ; load to physical address 10000h
   mov ES, AX
   xor BX, BX
   
   mov AH, 02h
   mov AL, 01h
   mov CH, 00h
   mov CL, 06h
   mov DH, 00h
.readsector:  		             
   int 13h
   jc Error
   cmp CL, 6Ah
   je .kdone
   add BX, 200h
   inc CL
   jmp .readsector
  
.kdone:
   lea SI, [KLOAD]
   call PrintS

.pMode:
   cli
   mov AX, 2401h         ;enable the A20 line, fast then slow
   int 15h
   jc Error
   jmp Final

A20_secondary:
   call Empty_8042  
   mov AL, 0D1h      
   out 64h, AL
   call Empty_8042
   mov AL, 0DFh      
   out 60h, AL
   call Empty_8042

Final:
   lea SI, [A20SET]
   call PrintS

   pusha
   lgdt[GDTTable]         ;load GDT
   popa

   mov EAX, CR0           ;finally set protected mode
   or EAX, 01h
   mov CR0, EAX
   jmp 08h:clear_pipe

[BITS 32]
clear_pipe:
   mov AX, 10h         
   mov DS, AX              
   mov SS, AX
   mov ES, AX 
   xor EAX, EAX
   mov FS, AX
   mov GS, AX            
   mov ESP, 200000h       
jmp 08h:10000h
hlt

PrintS:
    mov AH, 0Eh      
.loop:   
    lodsb             
    test AL, AL       
    jz .done         
    int 10h         
    jmp .loop
.done:
    ret

Empty_8042:
    call Waitingloop
    in AL, 64h
    cmp AL, 0FFh    
    je .done
   
    test AL, 01h        
    jz .no_output
    call Waitingloop
    in AL, 60h       
    jmp Empty_8042   
   
.no_output:
    test AL, 02h        
    jnz Empty_8042   
.done:
ret

Waitingloop:                   
    mov EBX,9FFFFh
.loop_start:
    dec EBX     
    jnz .loop_start
    ret

Error:
 [regular error msg]


;****************
; Strings
;****************
[regulars]
   
GDT:
null:      
   dd 00h
   dd 00h

code:               
   dw 0FFFFh
   dw 00h
   db 00h
   db 10011010b
   db 11001111b
   db 00h

data:               
   dw 0FFFFh
   dw 00h
   db 00h
   db 10010010b
   db 11001111b
   db 00h
               
GDTTable:                      
   Limit dw 24   
   Base dd null

times 2048-($-$$) db 0

Thanks for any help you can provide, I can't seem to find a solution.

[Gigasoft]

You forgot a [BITS 16] before PrintS.

[GenHornet18]

Thanks but the main error (as shown by bochs) seems to be "load_seg_reg(ES, 0xFFFF): invalid segment". I'm not sure where this happens (or exactly what is happening), I don't believe I overload the ES register anywhere...

[bitshifter]

This seems wrong...

Code: Select all

GDTTable:                     
   Limit dw 24   
   Base dd null

Where Base should be: GDT + (CS * 16)

Also you are: call Empty_8042 from 16bit area

[Gigasoft]

GDT base is OK, since null equals GDT and DS is 0.

If it still doesn't work after inserting the [BITS 16], the error is probably easily found using the debugging version of Bochs. Remember to disable interrupts before going to protected mode.

[bitshifter]

Haha, your right.
For some reason i took null as 0, not as a label

[GenHornet18]

Thanks,

Although [BITS 16] before 'PrintS' had no effect, I suppose I'll examine the bochs log and post, see if it can derive a solution.

[Gigasoft]

In the debugging version of Bochs, you can set a breakpoint on 0:0x7e00 and step through it until you get to the error, if you can't find out what's wrong from the log (which is sometimes hard).

[GenHornet18]

Well my debugging skills are fairly low but I didn't see anything completely wrong. Running in regular bochs I get a screen shot shown below. Everything seems to execute correctly in the code until it hits the last jump to the kernel. So I'm wondering is my protected mode addressing off? (kernel loaded to physical 10000h).

[Gigasoft]

Oh, int 13h overwrites AX so it won't be 201h anymore, that's the problem. Therefore it only manages to load one sector.

[GenHornet18]

Thanks,

It wasn't reading the entire kernel (I assumed CH was automatically incremented and I also forgot about the returns). Even with that fixed however, the original error still remains, same as before. Any ideas as to what it could be?