Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
There's about a billion threads on IDTs, this was in one of them.
This particular example has been proven to break down when you start using it in code that is linked instead of in a flat binary. Then again I wrote it to show someone what a really basic IDT could look like so it not working in that circumstance really doesn't bother me.
Code_sel is you code segment descriptor that is located in your GDT. Normally you have one code segment descriptor for the GDT and then another for the IDT.
well that Code_Sel is the code selector we will define in our GDT and this code:
well i dont know its just like one of those little structures defined in that IDT ..
but why r u asking me this?
oh so u r telling me .. thanks buddy ..
actually i will start working on this code on the weekend .. then i will start asking quesitons u know
BTW thanx for ur help
DANGER: If you have a C/C++ Kernel and use Curufir's code and LINK it...it will break apart.
I'm using someone elses IDT...almost about to test it, but now I'm making FritzOS C++ and making a more powerful printf ( I made FritzOS C++ without the run-time information...I really don't need it ).
I keep telling you it's just a problem with me assuming the addresses of the ISRs (And I can, because I use flat binary and I know where I put them). Once you start linking against anything you need to use both sections in the IDT that describe routine entry, ie fill in both the 0-15 and 16-31 bits of the address (Which Intel very kindly split into two sections, thanks Intel). I only ever bother with the 0-15 bits precisely because I know NASM will handle the situation as I want it to. If you're linking then you're going to have to mess around with things a bit. As I keep saying: "This was meant as an example, not for actual use".
well i have a few confusions in ur IDT
ok so in ur IDT u go from 0-31 intr's .. the rest 32 onwards are all software intr's so why u r doing something with them .. i mean i m asking u that do we have to do something with them ??
ok and then u started these from 32 and went till 47 .. now why is that .. why 47 ??
;*****************************
;* System defined interrupts *
;*****************************
IDT_30:????????????;A sample of interrupt
???DW ISR_Sample??????;Bits 0-15 of entry point offset
???DW Code_Sel??????;Valid code selector
???DB 0x00?????????;Blank
???DB 0x8e?????????;32-bit Ring 0 interrupt gate
???DW 0x0000??????;Bits 31->16 of entry point offset
what is this .. i mean is it something different from others ?
and now
about this actual work of these intr's
like u have this for IRQ_0
IRQ_0:??????;PIT (Programmable Interrupt Timer)
???;****************************************************
???;* A sample of how to handle a interrupt from IRQ 0 *
???;****************************************************
???PUSHA
???CALL PIT_Handler
???MOV AL, 0x20
???OUT 0x20, AL
???POPA
???IRET
can u plz tell me what exactly are u doing here and why ?
Ok, with deference to the fact that once you've grasped all the IDT concepts you'll want to write your own (And if you're going to link into an executable then you'll have to anyway) I'll keep things general.
That example is set up as follows.
0->31 Are processor exceptions and interrupts reserved by Intel for future use. The processor itself calls these interrupts, so they should be handled in some way. In this example the way of handling them is to just immediately return. In a real situation you'll want to do much much more. Some exceptions push an error code onto the stack when they call the interrupt. To correctly return from an exception of this sort you need to pop off the errorcode before the IRET, which is effectively what adding 4 to esp does.
32->47 are assumed to be where you remapped the PICs to. When the PICs fire for an IRQ (eg IRQ1 for the a keyboard event) they call an interrupt. You can set which interrupts they call, but most people map the PICs to 32->47 so that's what I used.
48 is just a normal software interrupt, it doesn't do anything special, it's just to provide an example of what happens with software interrupts.
Before you return from an IRQ you have to send an EOI signal to the PIC(s). The example actually breaks down here, because for IRQs using the second PIC you also need to EOI the second PIC as well. That's what the IO port operations are about.
No you don't have to use all the interrupts at all (I'm sure that's mentioned in a comment somewhere). The reason I filled in the rest of the table is that it effectively fixes the size of the IDT no matter how many entries you stick in there although you need to adjust the rep statements (A times directive would probably be more effective). Reason I want that is because I usually have the IDT before the code in my kernel so having it as a fixed size means I don't have to recalculate offset to jump to in the bootsector all the time. That and if I slip up and call an interrupt I'm not handling there won't be an exception I'm also not handling which would result in horrible things happening. If I slip up under the scheme of the example then a call to a bad interrupt (Eg int 71) would just result in nothing happening.
Hope that clears it up.
Maybe I should get around to rewriting this example so that it works with C and is a bit clearer. Of course that would mean actually finishing remaking my Linux system (Note: Be careful updating to glibc-2.3.1 and recompiling things...ouch). If you want (IMO) a much better example, and one that should work with C, then take a look at Christopher Giese's OSD examples (There's a link somewhere on this board, probably on a different IDT topic).
Note: I noticed a while back that I'd forgotten exception 9 also pushes an errorcode which I missed popping.
well i couldnt ask for a better explaination
one more thing that what r u talking about this linking into executable stuff ??
what i m thinking is that i will put my IDT in the 2nd stage loader which has the GDT too and which sets up the pmode and then jump to C kernel ..
so am i doing the right thing or what ???
there is something else which i m confused about .. my C kernel is 8704 bytes ( i have no idea why it is so big ) .. so i use to load it the 3rd sector of floppy .. now when i read it from my 2nd stage loader .. i load it from 3rd sector , head 0 and read 20 sectors from here as this kernel is so freaking big :-\
now i m confused about this head 0.. how many sectors are there in one head .. ill just suppose (asn an example) there are 15 .. but then i m only reading from head 0 and some part of kernel is in head 1 .. but it seems to read everything and works properly ..
hope u udnerstood my question
BTW thanx for ur help
When you produce object files with nasm/a compiler etc they contain lists of information about memory references within the object file as well as your actual code. The linker then uses these tables to patch up your code so that everything works nicely together. This is where it breaks. The linker won't automatically patch up the references to the IDT so IDTR ends up wrong as do the entry points in the IDT. This particular IDT will probably only work with nasm outputting a flat binary. Attempting to use it as part of a larger file by linking it as an object most probably won't work (And I've been told it doesn't). I may/may not get around to writing a basic example that you can link with C sometime.
So long as you setup GDT and IDT before you enter PMode then the actual mechanics of how you load things in is entirely personal choice (Although some methods are better than others)
1.44mb 3.5 inch floppy disk has 80 cylinders (Here track and cylinder mean the same thing because there's only 1 platter), 2 heads, and 18 sectors per track. This means that once you reach the 18th sector on a track you need to switch heads. Remember that just because you think the CHS scheme should start at 0/0/0 doesn't mean the disk designers do (Hint ).
And yes, that's a very big kernel if you don't have an IDT in there yet. Restrict your real mode code to the smallest needed to get to PMode (For which you need IDT/GDT) unless you have some burning desire to use the processor in real mode. Note: Having said this there are some useful functions for finding about system equipment in the BIOS (Eg Getting a memory map, Vesa etc) which you'll need BIOS access (Real mode/V86) to use.
) .. so i use to load it the 3rd sector of floppy .. now when i read it from my 2nd stage loader .. i load it from 3rd sector , head 0 and read 20 sectors from here