Defining idt in asm not working

[Cyao]

So im making a little kernel all in asm, and now i am trying to make the idt. I've already looked at the code for a while but I just can't find what I'm doing wrong . Can anyone help me take a look?

Code: Select all

FRAMEBUFFER equ 0x7FFF0
WIDTH equ 640
HEIGHT equ 400

[org 0x1000]
[bits 32]

main:
    lidt [idtr]
    int 0x0
    jmp $

idtr:
    dw idt_end - idt - 1
    dd idt

%macro idt_noerr 0                                          
    dw no_error_isr
    dw 0x08
    db 0                                                    
    db 0x8E
    dw (no_error_isr - $$ + 0x1000) >> 16
%endmacro

%macro idt_err 0
    dw error_isr
    dw 0x08
    db 0
    db 0x8E
    dw (error_isr - $$ + 0x1000) >> 16
%endmacro

align 8
idt:
    idt_noerr
    idt_noerr
    idt_noerr
idt_end:
                                                        
error_isr:
    add esp, 4
no_error_isr:
    iret

[iansjack]

Shouldn't your idt be using idt_err and idt_noerr rather than isr_err and isr_noerr? (I'm not claiming that's the only problem with your code, but it seems to be an obvious show-stopper.)

[Cyao]

Shouldn't your idt be using idt_err and idt_noerr rather than isr_err and isr_noerr? (I'm not claiming that's the only problem with your code, but it seems to be an obvious show-stopper.)

Oh didn't see that, but isn't it wierd that i used two undifined lables there but nasm didn't even give me a warning, the code is already everything i got.

[nullplan]

Also, the idt label should be after the align macro, else the IDT includes the alignment padding. And I would be very surprised if your macros keep working once you move the kernel beyond the 64kB range. But that is for later and not a showstopper. (Also, the routine called is the only point of differentiation between different interrupts, so you really need a different one for each interrupt, but that is also not a show-stopper right now).

[Octocontrabass]

Code: Select all

FRAMEBUFFER equ 0x7FFF0

It doesn't matter since you don't have any code to access the framebuffer, but I'm curious about the significance of this number.

Code: Select all

[org 0x1000]
[bits 32]

The NASM developers recommend using the user-level directive (without square brackets) instead of the primitive directive (with square brackets).

Code: Select all

idt:
    align 8

You're including the alignment padding inside your IDT. That might be why it doesn't work.

Code: Select all

error_isr:
    cli

Code: Select all

no_error_isr:
    cli

Your ISRs should never start with CLI. You're already using interrupt gates, so the CPU will automatically clear EFLAGS.IF when it jumps to your ISR. If you were using trap gates instead, CLI would not prevent the CPU from handling another interrupt after jumping to the ISR but before executing the CLI instruction.

[Cyao]

It doesn't matter since you don't have any code to access the framebuffer, but I'm curious about the significance of this number.

I am using VBE video mode, so in the bootsect i got the video mode info, and stored the video adress to the adress 0x7FFF0, probebly gonna change it after i get the idt working

Anyway my code is still now working , is there any chance that i need to use a i686 nasm? the command im currently using is nasm kernel.asm -o kernel.bin -f bin -O0 (the O0 is just to be sure that it isn't nasm that makes my code broken)

[Octocontrabass]

Anyway my code is still now working

I don't see anything else wrong with it. How do you know it's not working?

is there any chance that i need to use a i686 nasm?

There's no such thing.

(the O0 is just to be sure that it isn't nasm that makes my code broken)

NASM's optimizations won't change the behavior of the code you've posted. (And if you need to disable NASM's optimizations elsewhere, you can use the "strict" keyword to disable optimization on individual instructions instead of your whole program.)

[Cyao]

I don't see anything else wrong with it. How do you know it's not working?

The cpu just tripple falts (aka qemu quits immediately since i am using the -no-reboot flag) when i call the int 0x0

There's no such thing.There's no such thing.

Oh good I am just afraid since the last time i defined a idt it didn't work because i used x86_64-elf-gcc instead of i686-elf-gcc

[Octocontrabass]

qemu

Since you're using QEMU, have you tried adding "-d int" to see which faults are leading up to the triple fault? (You may also need to add "-accel tcg".)

[devc1]

(You may also need to add "-accel tcg".)

Isn't TCG used by default in QEMU ?


Cyao1234, try aligning the IDTR on a 16 byte boundary and the IDT on a 4KB boundary, I don't know if I'm right but one time in the past my IDT won't work unless I aligned it on a 4kb boundary.

[Cyao]

Cyao1234, try aligning the IDTR on a 16 byte boundary and the IDT on a 4KB boundary, I don't know if I'm right but one time in the past my IDT won't work unless I aligned it on a 4kb boundary.

Just did that now and it still doesn't work

Since you're using QEMU, have you tried adding "-d int" to see which faults are leading up to the triple fault?

I just did it now and it seems that the idt register is 0, which is a bit wierd since the idt is at somewhere like 0x1000, is there a few operation gap between when i can first use a int and when i define the idt? Also the whole debug log is here
https://github.com/cheyao/AsmOS

[devc1]

if it shows that IDT = 0 then the IDTR is invalid.

You're not aligning IDTR as I see in the repository, add "align 0x10" before IDTR declaration.
change :

Code: Select all

idtr:
    dw idt_end - idt - 1
    dd idt

to :

Code: Select all

align 16
idtr:
    dw idt_end - idt - 1
    dd idt

[devc1]

It seems that your stack pointer is residing in the EBDA (Extended BIOS Data Area):

Code: Select all

init_pm:
    mov ax, DATA_SEG
    mov ds, ax
    mov ss, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
; :(
    mov ebp, 0x90000
    mov esp, ebp

This is a special BIOS area that may not contain real RAM, try setting the stack pointer to something like 0x20000 instead, this will fix some further problems (not essentially the IDT one).

Check this article for a mapping of the low memory (physical memory below 1 mb) : https://wiki.osdev.org/Memory_Map_(x86)

[Octocontrabass]

Isn't TCG used by default in QEMU ?

It depends on the host's capabilities.

is there a few operation gap between when i can first use a int and when i define the idt?

No.

Also the whole debug log is here
https://github.com/cheyao/AsmOS

Code: Select all

0: v=00 e=0000 i=1 cpl=0 IP=0008:0000000000007e07

Your kernel is loaded at 0x7E00 but you've assembled it to run at 0x1000. You need to assemble it and load it at the same address.

It seems that your stack pointer is residing in the EBDA (Extended BIOS Data Area):

The EBDA in QEMU is small enough that 0x90000 is fine.

[devc1]

I have just compiled and run your OS and it seems to work completely fine, where is the problem ?
The interrupt is handled without any problem ?

Octocontrabass is right, just replace "org 0x1000" with "org 0x7E00" and it will work, it worked on my PC.