pmode problems...

I have been working on my OS for quite some time, and due o some deisgn faults, have decided to start over, and re-do my bootloader and kernel, to sort out some issues, for some reason, I can not get my bootloader to jump to pmode successfully, as soon as i re-enable interupts, it dies. Here is the code, from after the kernel is laoded into memory, to when I try to re-enable interupts:
in boot.asm:
[code]
cli
xor ax, ax
mov ds, ax

lgdt [gdt_desc]

mov eax, cr0
or eax, 1
mov cr0, eax

jmp 08h:0000
[/code]

this is my GDT:
[code]
gdt: ; Address for the GDT

gdt_null: ; Null Segment
dd 0
dd 0

gdt_code:
dw 0FFFFh
dw 0x8000
db 0
db 10011010b
db 11001111b
db 0

gdt_data:
dw 0FFFFh
dw 0x8000
db 0
db 10010010b
db 11001111b
db 0

gdt_end:



gdt_desc:
dw gdt_end - gdt-1
dd gdt
[/code]
And this is the code from the kernel:
[code]
mov ax,10h
mov ds,ax
mov ss,ax
mov esp,0x90000
lidt [IDT_desc]
sti

mov edi,16
mov ah,9
mov al,"a"
mov [gs:edi],ax
hang:
jmp hang
[/code]

the bootloader loads the kernel fine, and executes the lidt, and contiunes to put the char on the screen in the right place, but then dies.

Here is the bochs output
[code]
00001213996e[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00001213996e[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00001213996e[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00001213996i[CPU0 ] protected mode
00001213996i[CPU0 ] CS.d_b = 32 bit
00001213996i[CPU0 ] SS.d_b = 32 bit
00001213996i[CPU0 ] | EAX=00000961 EBX=00000600 ECX=00000000 EDX=000000a1
00001213996i[CPU0 ] | ESP=00090000 EBP=00000000 ESI=00007d9a EDI=00000010
00001213996i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df IF tf sf zf af PF cf
00001213996i[CPU0 ] | SEG selector base limit G D
00001213996i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00001213996i[CPU0 ] | CS:0008( 0001| 0| 0) 00008000 000fffff 1 1
00001213996i[CPU0 ] | DS:0010( 0002| 0| 0) 00008000 000fffff 1 1
00001213996i[CPU0 ] | SS:0010( 0002| 0| 0) 00008000 000fffff 1 1
00001213996i[CPU0 ] | ES:07e0( 0000| 0| 0) 00007e00 0000ffff 0 0
00001213996i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00001213996i[CPU0 ] | GS:b800( 0000| 0| 0) 000b8000 0000ffff 0 0
00001213996i[CPU0 ] | EIP=0000013d (0000013d)
00001213996i[CPU0 ] | CR0=0x00000011 CR1=0 CR2=0x00000000
00001213996i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00001213996i[CPU0 ] >> jmp .+0xfffffffe (0x0000813d) : EBFE
00001213996e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
[/code]

Any help on this would really be appreciated as it is driving me mad.

Comments

  • When you issue [b]sti[/b], it enables hardware interrupts. Have you re-mapped the hardware interrupt requests to your IDT? via the PIC or APIC? If not, then it is probably crashing do to a timer interrupt, which is issued by hardware. As it does not refer to your IDT, it executes invalid code.

    In rmode, it is already mapped via BIOS. However, because you have loaded your own IDT in pmode, it becomes invalid.

    I also noticed your [b]mov [gs:edi],ax[/b] instruction, but I do not see where you set GS. If GS does not point to a valid GDT offset (Most likely 0x10), it will GPF.

    According to the Bochs error report, GS, ES, and FS are all invalid (And you are using GS, which will GPF as noted above.) I would fix this.

    If there is anything else I see, I will let you know ;)

    Good luck!

    [hr][size=1][leftbr].:EvolutionEngine[rightbr][leftbr].:MicroOS Operating System[rightbr][leftbr][link=http://www.brokenthorn.com]Website :: OS Development Series[rightbr][/link][/size]
  • AHA, thanks, I have got a bit of code that remaps hardware IRQs, but i removed it as I thought that could be causing the problem, also, I thought that you could still access the segment registers with there old values, I will change that though.

    This is the hardware interrupt remaping thingy...is this what I should have?

    [code]
    mapIRQs:
    ;setup the PIC master
    PIC_1 equ 0x20
    PIC_2 equ 0xa0
    PIC_1_DATA equ 0x21
    PIC_2_DATA equ 0xa1
    PIC_1_START equ 0x20
    PIC_2_START equ 0x28

    mov al,0x11
    mov dx,PIC_1
    out dx,al
    mov dx,PIC_2
    out dx,al

    mov dx,PIC_1_DATA
    mov al,PIC_1_START
    out dx,al
    mov dx,PIC_2_DATA
    mov al,PIC_2_START
    out dx,al

    mov dx,PIC_1_DATA
    mov al,0x04
    out dx,al
    mov dx,PIC_2_DATA
    mov al,0x02
    out dx,al

    mov dx,PIC_1_DATA
    mov al,0x01
    out dx,al
    mov dx,PIC_2_DATA
    out dx,al

    mov dx,PIC_1_DATA
    mov al,0x00
    out dx,al
    mov dx,PIC_2_DATA
    out dx,al
    [/code]
  • On a seperate topic, I have been looking through your tutorials, there pretty damned good...shame the one I really need isnt done yet (Interrupts)...nod nod wink wink....lol just messing..
  • : On a seperate topic, I have been looking through your tutorials,
    : there pretty damned good...shame the one I really need isnt done yet
    : (Interrupts)...nod nod wink wink....lol just messing..
    :

    I do have a 8259A PIC tutorial up that explains mapping hardware interrupts :p => [link=http://www.brokenthorn.com/Resources/OSDevPic.html]Clicky[/link]

    Anyways, the PIC initialization code that you posted should work fine. (Insure you clear interrupts before calling the routine though.)

    Also insure entries 32 - 40 in your IDT are set up to handle the hardware interrupts (IRQ's), because you mapped the 16 hardware interrupts to these entries in your IDT.

    Last but not least, do not forget to send an EOI signal to the PIC controllers at the end of each interrupt request, or the PIC will not unmask the other interrupts.

    [hr][size=1][leftbr].:EvolutionEngine[rightbr][leftbr].:MicroOS Operating System[rightbr][leftbr][link=http://www.brokenthorn.com]Website :: OS Development Series[rightbr][/link][/size]
  • I have checked my IDT, and its the same one I was using with my last OS code, and it worked fine, ints 0-48 all work fine, do you know what the byte should be that controls the gate for hardware ints, I think all of mine are set to 0x8e

  • Hm...

    The only other thing I see that looks odd is that the base address in the GDT is set to 0x8000. This might be your intention though. However, if anything references memory below this address, it will GPF...

    What I would do is test only if your IDT is working. ie, Disable hardware interrupts via CLI, and then issue a software interrupt such as INT n (do not use INT 3 - thats a different instruction.)

    If it works, then your IDT is working fine for that interrupt. If it does not work still, there may be a problem with the IDT itself.

    Just because it worked fine in your previous bootloader, does not mean it will work in this one. This theory is espically true for bootloaders and beginning stages of kernels.

    Good luck, and I hope this helps!

    [hr][size=1][leftbr].:EvolutionEngine[rightbr][leftbr].:MicroOS Operating System[rightbr][leftbr][link=http://www.brokenthorn.com]Website :: OS Development Series[rightbr][/link][/size]
  • Well, it looks like we have found the problem...When I call int 48 (set up to point as Syserror...It doesnt call it, it just crashes...
    This is that part of the IDT, is there something blatently wrong with it? it looks ok to me.
    [code]
    dw Syserror ;48
    dw 08
    db 0
    db 0x8f
    dw 00
    [/code]


  • HAHA sorted it...

    the problem was this, as I was loading the OS at 0x8000, and setting code and data segs to start there, the IDT_desc that holds the location was pointing to the location relative t0 0x8000, not relative to 0, so IDTR was pointing to memory location, 0x167, instead of memory location 0x8167...so I added 0x8000 to it...and away I went...Thanks for the help


  • I'm glad you got it working!
    [hr][size=1][leftbr].:EvolutionEngine[rightbr][leftbr].:MicroOS Operating System[rightbr][leftbr][link=http://www.brokenthorn.com]Website :: OS Development Series[rightbr][/link][/size]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories