Page 2 of 2

Posted: Fri Nov 03, 2006 4:37 pm
by nick8325
When I boot your Kernel.bin with GRUB, it works...

Are you using Boot.asm or GRUB? (I'm a bit confused because Kernel.asm has a multiboot header)

Posted: Fri Nov 03, 2006 4:40 pm
by Combuster
Fear wrote:Can you post the linker script you used to compile it? Because I tried some examples with the rodata section in it, and it still compiled the same way....
I dont use linker scripts :), I just compile it to an executable native to my os, but thats probably not what you want.

What i do wonder, is HOW you try to load and execute the code, as plainly running it in userspace will go horribly wrong. Perhaps you are loading your code at the wrong linear address causing the data pointers to be pointing into nowhere. I hope you tried using Bochs' and its debugger, it can help you solve this sort of problems easily.

btw, the convention is to use "int main()", not "void Main()" (notice the capitalisation)

I see you posted an upload during this wiriting

One thing i noticed is the fact that your own bootloader dumps the image at 0x10000 [0x1000 segment], jumps to the code at 0x1000 linear, and neither address can be used by grub (since i see multiboot stuff...). I'll probably assume you use grub as you do get into kernel code somewhere.
I dont see a floppy image so i cant quickly run it, as I don't have grub anywhere on floppy. (also, i don't feel like opening a hex editor right now to dump the kernels contents)
Things to check:
- where do you have grub load it, and to where do you map the actual image
- what format are you compiling to, binary or something else?
- do you have bochs 8)

edit: i cant type fast enough to keep up with you guys

Posted: Fri Nov 03, 2006 4:41 pm
by Fear
I'm using Boot.asm and about that header... I didn't write that file. I was doing a tutorial before, and it was one of the files. So, I figured I would just pop it into my new file... So, something is probably wrong with Boot.asm.

Posted: Fri Nov 03, 2006 4:53 pm
by nick8325
Well, all that multiboot stuff in Kernel.asm is for GRUB (which is another bootloader). As Combuster said, Boot.asm isn't quite right: It will load the kernel to address 0x10000 (0x1000:0) but then jump to address 0x1000. Also, your linker script is wrong - the line "phys = 0x100000" tells the linker that your kernel will be loaded at address 0x100000. So, you have three different addresses in three different places, and they need to be the same :)

You could either:
  • Make all the addresses the same. For example, by changing "mov bx, 0x1000" in Boot.asm to "mov bx, 0x100", and changing "phys = 0x100000" to "phys = 0x1000" (and removing the multiboot stuff from Kernel.asm - you won't need it). Or...

    Use GRUB instead of Boot.asm to boot your kernel.
I use GRUB myself - it does a good job of booting the kernel, and I'd rather write a kernel than write a bootloader :) It's up to you which one you choose, of course.

Posted: Fri Nov 03, 2006 4:58 pm
by Fear
Dude, your awesome. You fixed it. I'm so happy!

Posted: Fri Nov 03, 2006 5:00 pm
by nick8325
I'm glad it's working :)

Posted: Mon Nov 06, 2006 6:52 pm
by Fear
One other thing, the screen (80x25) has 2000 slots for text, and when I clear it, it works perfectly. Then, after I write 6 lines of text, it stops working. I can't write anymore, and Bochs reports the error: interrupt(): gate descriptor is not valid sys seg. What does this mean, and whats going on?

Posted: Tue Nov 07, 2006 3:56 am
by Combuster
It means, an interrupt occurred and the corrensponding entry in your IDT was found to be incorrect. You can either disable interrupts, or fix (write?) your interrupt table.

Posted: Tue Nov 07, 2006 6:35 am
by Fear
Yeah, write is the right one... Haven't gotten around to it. But why does an interrupt occur there, but not after all the text before it?

Posted: Tue Nov 07, 2006 11:24 am
by Combuster
Since it occurs at at a regular point in time, its probably the PIT at IRQ0. It'll just pick a clock cycle to interrupt your code. How much you can do before that depends on how well you optimized your code.
Still, you should handle all IRQs - it isnt really professional if anybody is able to crash your kernel by just hitting the keyboard or touching the mouse.