IDT / IRQs

[JAAman]

actually kernel32.asm IS important: thats where your loading your IDT! unless your loading it in your C file?
I couldn't find it in your kernel16.asm and if its wrong then the IRQ would cause a jump to a invalid location (but i guess most likely it would tripple fault because the handlers would prob be invalid?)

or did you forget to load your IDT? but that should cause a tripple-fault not bogus mem

selectors? you mean into CS? with a
JMP FAR code_selector:offset

into DS/SS/ES/FS/GS? with
mov AX,data_selector
mov DS,AX

[z4ck]

i load the idt in the c file... (kernel.c)

the kernel32.asm can you see here:
http://www.domae.ch/downloads/PiratOs/kernel32.asm


thx

[JAAman]

well then if i want to check your LIDT i need your c file now dont i

are you sure the type for the IDT.base should be interupt? doesnt this refer to your struct just above it? this doesnt look right. it should be a long.

also your IDTR.limit = 256*(sizeof(interrupt)-1);
this would be: IDTR.limit=256*((8)-1)
IDTR.limit=256*(7)
IDTR.limit=1792
shouldnt this be:
(256*sizeof(interupt))-1?
IDTR.limit=(256*8)-1
IDTR.limit=2048-1
IDTR.limit=2047

isnt going to be a prob since you dont actually use the higher INTs just something to note

i've now checked the manuals and yes your interrupt struct looks correct it could just be your IDTR.base type

[z4ck]

I have set the type to "pointer to interupt" so i can save there a adress to a interupt structure...

now i have changed that what you have written, but unfortunately it doesn't work yet...that with the IDTR.limit, i give you right. Mine is fault... But the other one with the IDT.base, i think, is mine just a other variant...

see here the new idt.c file (http://www.domae.ch/downloads/PiratOs/idt.c...)


in this file is also the LIDT, which you mean.


thanks a lot that you take a lot of time to help me

[JAAman]

only thing i can see at this point is why do you have the 1 in the GDT base? (kernel16.asm)

your CS selector isnt 0 based?
that changes everything i cant believe i missed that

so your gdt.CODE is 1MB based? and your gdt.DATA is 0 based -- this could be a problem

most compilers expect CS.base = DS.base = SS.base but your CS.base!=DS.base sometimes this will work anyway but you may have trouble later

the real problem would be that you prob tell your linker that it is loaded at 0 since its loaded at 1MB and CS.base=1MB the offset should be 0

if your not doing this (and telling it to load at 1MB) then your calls could easily break and your IDT will definatly be wrong(since it needs offsets)

if you are doing this(linking at 0)then your data references will be wrong and your IDT.base will be wrong since it expects an ABSOLUTE address(which means it should not be reletive to ANY segment

since your gdt.DATA is 0 based the offset is the same as the absolute address and the IDT.base be correct if you are linking to 1MB but then your IDT entries will be wrong because they are CS reletive and the linker will ad 1MB to the file offset and end up in bogus_mem

[z4ck]

so, what i have to change???

if i change something in the base of the gdt, pmode don't work....and bochs reboot..

(thx, i was thinking ever that this may be false)

[JAAman]

ok first you need to know what offset you are linking to
in your linker command line or linker script

most likely you are linking it to 0 (or not specifying) if this is the case you will need to change the CS.base to 0 AND change your linking to 1MB
or
you can change DS.base to 1MB and continue linking to 0 but you will need to add 1MB to the address before you LIDT so that
IDTR.base=(unsigned long)IDT
becomes
IDTR.base=(unsigned long) (IDT+0x0100000)
and you may also have to patch the LIDT command but I'm not sure

the easiest solution would be just to change your linking to 1MB and then change your CS.base=0

if you ARE linking to 1MB you must change your CS.base to 0

[z4ck]

hm, but i didn't link it to 0.

see my linker script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
  .text 0x10200 : {
    *(.text)
  }
  .data : {
    *(.data)
  }
  .bss :  { 					
    *(.bss)
  }
}

[/code]

[JAAman]

ok i just took another look at my manuals and i was wrong that address is 64k not 1MB(thats what i get for reading to fast) but if your linking to 64k then your base should be 0 since the link address is an OFFSET not physical address (well actually its a virtual address but since paging isnt enabled its the same as the offset into the segment)

so the linker is add 64K+512 to EVERY address including the ones your loading into the IDT, while the IDT is expecting offsets into the segment
if you change your link script to link it to 0 that will fix the calls and IDT entries but the LIDT and IDTpntr will need to be changed
its good that its adding that to the LIDT and IDTpntr addresses

IMPORTANT NOTE:
if you change the CS.base to 0 your JMP 0x8:.2 WILL NOT WORK
this must be fixed by adding the base(64k)to the address:
JMP 0x8:.2+0x010000
i think that should be correct

[z4ck]

i have now changed my CS.base to 0 and my jump to jmp long 0x08:.2+0x1000....

but i've i change something at the linkerscript the kernel don't work...

[JAAman]

no your linkerscript should be correct as it specifies the loading location as an offset into CS and DS
since your CS=DS is now 0 base then the offset is the physical location you have loaded the file into which would be 64k+512 or 0x010200

i dont no what else to say since i havent found any other errors
mabey someone else has some ideas? or someone has more experience with linker scripts knows of something else that i dont?

[z4ck]

the kernel should be loaded at 64k = 0x10000... but c part (which we must linking) is at 0x10200 = 64k + 512...

now, the error "runing in bogous memory" dosn't appear, and the kernel don't break down... badly, nothing happens.... irq0 don't make anything...

does anybody know an other error?
(JAAman thank for help)

[z4ck]

erm sry JAAman!!! now it rocks!!

If i hit a key, irq1 works.... but however only one times.... i've i hit a key again, irq1 don't come.... maby a fault at EOI (End of Interrupt), don't know...

[z4ck]

thanks JAAman an all others.... IT WORKS!!!

the keyboard runs only one times because we must first clean up the kbc cache....


i will open a new topic if i have other questions. but now i have a lot of work....


bye, see you soon...