IDTkernel Buggy!?

[mr. xsism]

OMG!! I am so sorry newbies. I had a previous problem with my IDTkernel that is posted on Bona Fide OSdev, but there might be more! I need your help. Those of you who spent days frying your nogins, i am really sorry. I wrote that kernel when I myself was a newbie, please help me debug it.

---word of advice---
Osdev can often be very heart breaking and mind shattering, but it is also very rewarding. Don't give up. If you need help, use these forums, goto Bona Fide, or come to #osdev @ irc.wyldryde.net for help from us "expereinced" osdevers.

Here is the link that i'd like you to test. I think the IRQ masking is buggy, but i also think i have fixed it(just not updated it to the site yet.

[Link:]
http://osdev.neopages.net/downloads/tuts/IDTkernel.zip

Thanks for your help. I unfortunately didn't here of this until i read a post. Please, if there are any errors in ANY of my tutorials or example code, email me. I always have my email in the readme.txt files included. Here is my email just in case: monkeykiller4u (at) hotmail.com

Also read this tutorial that i'm working on and tell me how it is so far:
http://osdev.neopages.net/tutorials/Xosdev.zip

Remember to give me feedback, i'm almost always in #osdev @ irc.wyldryde.net

Regards,
mr. xsism

[df]

---word of advice---
Osdev can often be very heart breaking and mind shattering, but it is also very rewarding. Don't give up. If you need help, use these forums, goto Bona Fide, or come to #osdev @ irc.wyldryde.net for help from us "expereinced" osdevers.

#osdev is good, but if you ask questions that are directly in things like the intel PDF's, etc. you wont get a nice reception. There is no hand holding in #osdev

sometimes a good option is to just hang around for a while and say nothing to see how the channel operates.

[Pype.Clicker]

on page 4 of your tutorial, GDTBASE DD 0x50 will hardly make your GDT starting at 0x500 !! I think you underestimate the misunderstanding about the GDT base address. A lot of newbie have problems with that because they set their bootsector at CS=07C0, IP=0000 and find that their GDT cannot be used correctly when they put the offset (relative to 0x7C0) in GDTR.base ...


Aswell, the GDT entry is *not* a selector but a *descriptor*. The selector is the index in the GDT. Thus 0x08 is a selector [limlo - baselo - baseme - type - basehi - misc] is a descriptor.

Finally (as it's the third error i found, i end up here ...) your readers will hardly be able to run "call _k_main" without having set up a pmode stack ...

[Pype.Clicker]

personnally, i would not recommend your code as a tutorial in its current form. The way you make bios calls for instance (repeating the commands rather than making a loop) isn't very clean (you don't even test for errors) and is a shame in an environment where only 512 bytes are available.

...

[distantvoices]

Well, i canna shut my trap whilst reading inconsistencies ...

xsism, please, please stay with exact expressions: There is really no way with confusing f. ex. a gdt Descriptor (which you call correctly but unsharp to some extent a gdt-entry) and a selector, which tells the processor which descriptor to pick out of many.

ok, this is one of 'em, may be the least one.

As for your IDT-Kernel: it didn't convince me with proper quality for it confused folks in some very queer way. this is due to your remapping stuff and due to the fact that you after install a custom handler in the bios idt. I don't consider this well planned for a tutorial kernel. It does not show how to do that thingy RIGHT, cuz the lad's n gal's scanning throu' it might trust it and try it out and do some experiments with it... and bang there comes Mr. TripleFault as there aren't handlers available at the proper places.

stay safe gosh

[mr. xsism]

:'(
Wow, you guys have no mercy.


First off,df, have you been there? It really depends what time it is If we're ready and awake we don't mind guiding you through the problem as far as we can go.

---

Secondly, pype, you're wrong. Look at my GDT moving code again; it clearly moves it to 0x500:

Code: Select all

; -[move GDT to 0x500]- ;
xor ax,ax
mov ds,ax
mov es,ax
mov si,GDT                    ; Move From [DS:SI]
mov di,[GDTbase]              ; Move to [ES:DI]
mov cx,[GDTsize]              ; size of GDT
cld                           ; Clear the Direction Flag
rep movsb                     ; Move it

GDTbase:GDTsize id the format. This equates to
0x50:0x0 which translates to linear 0x500.

Pype, i also must say that whether i have a loop or not doesn't matter, i only use about 300bytes in the code. It doesn't hurt to space this stuff out, i want the reader to see what is happening as plainly as possible.

Finally (as it's the third error i found, i end up here ...) your readers will hardly be able to run "call _k_main" without having set up a pmode stack ...

Oh really? Well then, why does it work?

---

Lastly, Beyond, ok, i'll be more political about it. But WTF are you talking about a BIOS IDT(IVT) for? That code works fine now, i never get any triples.

this is due to your remapping stuff and due to the fact that you after install a custom handler in the bios idt.

What in the world does that mean? It doesn't work? it doesn't "do that thingy RIGHT" ? I don't understand.

---

Wow, i thought i had humbled myself to the ground, but you guys just plain planted my face in the soil. Try to be nice, you might scare other osdevers away.

BTW,i'm not a newbie, but i was when i wrote the kernel. Give me some slack.


Regards,
mr. xsism

[Pype.Clicker]

:'(
Wow, you guys have no mercy.

Don't take us wrong. We don't mean your work is crap (if it was, i would just post "this is crap" as private message and drop the thread :p ). But i don't believe your tutorial is ready for real newbies -- this is called a review : tracking errors and proposing improvements so that you can end up with a better and reliable work

Code: Select all

Secondly, pype, you're wrong. Look at my GDT moving code again; it clearly moves it to 0x500:

; -[move GDT to 0x500]- ;
xor ax,ax
mov ds,ax
mov es,ax
mov si,GDT ; Move From [DS:SI]
mov di,[GDTbase] ; Move to [ES:DI]
mov cx,[GDTsize] ; size of GDT
cld ; Clear the Direction Flag
rep movsb ; Move it

Code: Select all

GDTbase:GDTsize id the format. This equates to 
0x50:0x0 which translates to linear 0x500.

Err ... that was in the code and i read the ch01.pdf ... By the way, the fact you move the GDT does not change anything: setting GDTbase to 0x50 will make the GDT start at linear address 0x50, not 0x500 ! It seems correct in IDTkernel.zip:boot.asm (you have GDTbase DD 0x500), but it is not in ch01.pdf.

Moreover, in your code, this isn't event what you do ... you have

Code: Select all

;------------GDT Table---------------;
GDTR:
GDTsize DW GDT_END-GDT-1
GDTbase DD GDT

so your copy loop actually keeps your GDT at its actual place

Pype, i also must say that whether i have a loop or not doesn't matter, i only use about 300bytes in the code. It doesn't hurt to space this stuff out, i want the reader to see what is happening as plainly as possible.

imho it does hurt. Not because of the space, but because it means that you will more easily introduce errors in what you're doing. For instance, the BOOT.ASM in IDTkernel.zip you start loading more sectors and only check for errors on the first 18 of them ...
If you want user to understand and code to be clean, you could, for instance, have a data-driven approach

Code: Select all

;; datas for kernel loading. track, head, size, offset (hi byte).
sectorlist db 0,0,17,0x00
               db 0,1,18,0x22
               db 1,0,18,0x46
               db 1,1,18,0x6A
...
               db 3,1,18,0xFA
               db 0,0,0,0

.retry:
mov al, [sectorlist+di+2]
or al, al
je .done
mov ax,0xffff
mov es, ax
mov bl, 0x10
mov bh, [sectorlist+di+3]
mov ah, 2

mov dh,[sectorlist+di+1]
mov cl, 19
sub cl, al ;; <-- that's a hack. i don't feel like re-typing the whole table
mov ch,[sectorlist+di]
int 0x13
jc .retry
add di,4
jmp .retry
.done:

Note that your loader could be easier if

• you start at track 0, head 1, sector 1 rather than 0.0.2 (this way, you always load a whole track at once and therefore sector and size are constants
• you pusha before calling int0x13 and popa after, so that you can

  Code: Select all

  add bx,18*512 
  xor dh,1
  jnz .sametrack ;; when dh=0->1, keep the same track.
  inc ch               ;; when dh=1->0 (ZF set), go to next track.
  

  
  

  Finally (as it's the third error i found, i end up here ...) your readers will hardly be able to run "call _k_main" without having set up a pmode stack ...

  Oh really? Well then, why does it work?

  Because you did in your code but didn't mention it in the tutorial.
  It's a very important step and it should be explicitely explained.

[beyond infinity lazy]

xsism stay upright. One learns and makes errors.

Ok, you have done some redesign. 've been referring to an older version of your kernel, which really screwed folks up. Recently, I 've told two guys who 've tried to work with your "older" idt-kernel, what was missing. May be other's could have done this job much better than me.

One question: One doesn't need to reenable the irq-lines with sti to issue a software interrupt command? As far as I am informed, the instructions sti/cli turn on/off the hard ware interrupts to speak roughly.

Regarding the sentences you didn't understand: pls mark, I am no native english speaker. It can occur that i screw sentences up.

and last but not least: take it with a grain of salt, gosh! You earn respect: folks LOOK at your work and tell you whats up in honest way.

Stay safe.

[mr. xsism]

ok, i need to apologize for my reaction; it was uncalled for.

Pype, i need to thank you. I'll go over my IDTkernel and osdev tuts(2 seperate projects) and clean them up. Thank you for your advice. Please note that those two projects use different versions of my bootloader.

Code: Select all

GDTbase:GDTsize id the format. This equates to 
0x50:0x0 which translates to linear 0x500.

sorry, that should really say this:

Code: Select all

GDTbase is the address of the GDT moved table. This equates to 0x50:0x0 which translates to linear 0x500.

I'll also add uttorial text on loading the pmode stack.

---

Beyond, I'm not sure what you mean, but here is what i think you mean. To disable interrupts, you use cli. But IRQs need to be masked to diable them. If you 'cli' then you pretty much kill IRQs, IIRC.

Don't mind your grammar, thanks for telling me about the probs. I'll update the code and then ask for another critique, if you guys don't mind. I know i don't mind being criticized, as long as it is healthy

Regards,
mr. xsism

[Pype.Clicker]

One question: One doesn't need to reenable the irq-lines with sti to issue a software interrupt command? As far as I am informed, the instructions sti/cli turn on/off the hard ware interrupts to speak roughly.

software INT nn, exceptions (including debug exception and NMI) aren't sensitive to the IF flag. Thus doing a CLI doesn't prevent you from receiving general protection faults, from issuing INT 30h or getting the Non Maskable Interrupt (that i never get so far

What CLI does is telling the processor not to acknowledge interrupt requests (IRQ) from the Programmable Interrupt Controller. The unacknowledged interrupt is kept pending in the PIC and will therefore be processed by the CPU as soon as it re-enables interrupts with STI (and send an IACK).

The PIC can keep one pending request per interrupt. Thus if IRQ0 occurs while in CLI mode, it isn't lost, just deferred. If you stay in CLI mode during 2 time ticks, the second IRQ0 *is* lost.

I can't remember whether masked interrupt (at the PIC, using the mask port 0x21 and 0xA1) are deferred or dropped immediately, but i would rather say they're dropped.