IDT: Reboot again
Posted: Sun Oct 27, 2002 5:02 pm
[attachment deleted by admin]
Page 1 of 2
Re:IDT: Reboot again
Posted: Sun Oct 27, 2002 5:03 pm
[attachment deleted by admin]
Re:IDT: Reboot again
Posted: Sun Oct 27, 2002 7:16 pm
oh and, in fritz_boot.asm under the lgdt there shoulde be lidt [ idt_ptr ]
Re:IDT: Reboot again
Posted: Sun Oct 27, 2002 8:30 pm
change:
to
The gdt register contains the start of the gdt (gdt in this case) and the size of the gdt (gdt_end-gdt-1). Probably a typo since you got the idt one right (Don't go turning interrupts on btw, it'll try executing at address 0 *ouch*).
Dunno about the rest, I don't use C at this point.
Ok, here's to clear up some confusion about the IDT (Hopefully
).
The IDT exists in memory as a table of 8 byte entries. So there are 8 bytes describing each of the possible 256 interrupts you can declare have (You don't need them all if you don't want them).
A standard IDT entry:
To load the IDT you fill out the IDT register with the correct information. The correct information being the length of the IDT, and the start in memory of the IDT.
With this information you can load the IDT using the lidt assembly language command (Here lidt(IDTR)).
There are 32 interrupts at the start of the table reserved for use by the processor in such scenarios as eg Division by 0. Most people remap the PIC(s) to use the 16 interrupts just above this, leaving 208 interrupts for your own personal desires.
When an interrupt occurs (Wether it's because of a processor exception, an IRQ, or your software using INT) the processor goes to the IDT, multiplies the interrupt number by 8, checks the permissions based on the information in the IDT entry and if possible jumps to the code the IDT entry specifies as associated with that interrupt. The IDT is nothing more than a lookup table (With permissions and code selectors) used by the processor to find where it should be going when an interrupt happens. Most of the times people's code falls over and reboots the comp with new IDT code it is because they've failed to put in routines to handle the 32 reserved interrupts and the IRQ interrupts (IRQ 0-System timer, will kill your code every time if you turn it on and don't have a routine to handle it).
Hope that helps, tricky to explain clearly I'm afraid.
Curufir
Code: Select all
gdtr
dw gdt_end-1
dd gdt
Code: Select all
gdtr
dw gdt_end-gdt-1
dd gdt
Dunno about the rest, I don't use C at this point.
Ok, here's to clear up some confusion about the IDT (Hopefully
).The IDT exists in memory as a table of 8 byte entries. So there are 8 bytes describing each of the possible 256 interrupts you can declare have (You don't need them all if you don't want them).
A standard IDT entry:
Code: Select all
DW ISR_0 ;Bits 0-15 of the interrupt routine's address
DW Code_Sel ;The code selector from a valid GDT that your interrupt routine will run in
;These bytes handle what type of entry this is, see the intel manuals for details of what the bits mean
DB 0x00 ;Blank
DB 0x8E ;32-bit Ring 0 interrupt gate
DW 0x0000 ;Bits 31->16 of the interrupt routine's address
Code: Select all
IDTR:
DW IDT_End-IDT_Start-1
DD IDT_Start
;Here IDT_Start and IDT_End are labels in nasm code, their position should be self evident
There are 32 interrupts at the start of the table reserved for use by the processor in such scenarios as eg Division by 0. Most people remap the PIC(s) to use the 16 interrupts just above this, leaving 208 interrupts for your own personal desires.
When an interrupt occurs (Wether it's because of a processor exception, an IRQ, or your software using INT) the processor goes to the IDT, multiplies the interrupt number by 8, checks the permissions based on the information in the IDT entry and if possible jumps to the code the IDT entry specifies as associated with that interrupt. The IDT is nothing more than a lookup table (With permissions and code selectors) used by the processor to find where it should be going when an interrupt happens. Most of the times people's code falls over and reboots the comp with new IDT code it is because they've failed to put in routines to handle the 32 reserved interrupts and the IRQ interrupts (IRQ 0-System timer, will kill your code every time if you turn it on and don't have a routine to handle it).
Hope that helps, tricky to explain clearly I'm afraid.
Curufir
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 3:35 am
maybe i'm just missing a few bytes of code, but as long as you don't set up a proper handler in your IDT descriptors (they're actually pointing to address 0, which is in the BIOS area (IVT), isn't it ? chances that this code is good to handle clock irq or exception are low ...
by the way, does it reboot when you do the LIDT[...] command or when you enable interrupts (STI) ?
by the way, does it reboot when you do the LIDT[...] command or when you enable interrupts (STI) ?
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 6:29 am
reboots when I do sti, reading Curufir's stuff still...
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 11:55 am
So, will I need to make my own interrupt handler? And remap the pic THEN I can use sti?
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 2:30 pm
what steps to I have to do to enable the IRQ's?
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 3:02 pm
I hvae the same problem with my kernel - when I have
then system reboots - if I remove the offending line the OS boots as normal.
Code: Select all
asm("sti");Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 6:15 pm
you definately need to make your own interrupt handlers before enabling interrupts.
you should also install exception handlers so that you can catch errors before they reboot your PC now & in the future.. it will be very helpful
also, you can't simply point your interrupts to the IVT, since the CPU will be in pmode attempting to execute real mode code. you have to write your own handlers. one thing you can do, however, is have your handler switch back to real mode, then execute the IVT handler, then switch back to pmode. i wouldn't recommend you try this however, switching from pmode back to real mode is very touchy and it took me a while to get it right. just get your ints working before you try that
you should also install exception handlers so that you can catch errors before they reboot your PC now & in the future.. it will be very helpful
also, you can't simply point your interrupts to the IVT, since the CPU will be in pmode attempting to execute real mode code. you have to write your own handlers. one thing you can do, however, is have your handler switch back to real mode, then execute the IVT handler, then switch back to pmode. i wouldn't recommend you try this however, switching from pmode back to real mode is very touchy and it took me a while to get it right. just get your ints working before you try that
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 6:34 pm
ty mrd,
But where is a place for NASM in Linux that has a simple interrupt handler?
But where is a place for NASM in Linux that has a simple interrupt handler?
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 7:49 pm
[attachment deleted by admin]
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 8:25 pm
i'll test it...but I love that
!;* Do something, anything, it's your interrupt, go [glow=red,2,300]hog-wild *[/glow]
Re:IDT: Reboot again
Posted: Mon Oct 28, 2002 9:08 pm
TY! it worked!
bye
;D ;D ;D ;D
bye
;D ;D ;D ;DRe:IDT: Reboot again
Posted: Thu Oct 31, 2002 6:16 pm
I think I may be having a similar problem, but I lost what you were talking about. I mov the GDT starting at byte 2064. Then switch to PM. sti. Interrupts no longer work. Where did they go? From some of the stuff I read I cant use use the BIOS calls(like the print screen) in real mode. Will that mean I need to write ALL the ints for PM?