Mother of God help me! Floppy trouble

[TexHawk]

I have written a basic test kernel that aims to...
1) Read the boot sector from floppy (using BIOS this works fine)
2) Set up the stack
3) Set up an initial GDT (works fine)
3) Read the kernel that is also located on the floppy into memory at 0x600
4) Enable pmode and A20 gate (tested and seems to work fine)
5) Jump to the kernel

Seems logical but whenever I try this I can tell by test characters appearing on the screen that the process makes it to pmode fine but when I jump to the kernel nothing happens.  Right now its just suppose to print out another char and then hang but it doesn't do that, the computer just reboots.

I load the kernel onto the second sector of disk with the dd command
>dd kernel.bin bs=1 count=512 seek=512

and in my bootsector I try to load the second sector into memory by using BIOS but requesting that it read one sector starting at sector=2 from the floppy disk.  I know this might be a dumb way to do it but I had trouble finding a good pmode example that jump to a kernel.  I guess my overall question is:

1) Would this floppy magic even work
2) Does it matter where I load the kernel to as long as its not in the stack i.e. 0x600?
3) Do I need to do anything in my kernel before I attempt to write to vid mem?
4) Comments and Suggestions would be greatly appreciated.

Thanks,
TexHawk

[DaveHK]

you are free to use the bios routines to read the floppy BEFORE you switch to pmode, this will not work after, but you appear to be ok on that score

you can pretty much load your kernel anywhere you like, if the stack is in the wrong place, you can move that too

bios should have taken care of setting up the VGA controller correctly, so if you are looking for text mode access (mostpeople start there), there is nothing else you need to do at this point

One possible suggestion is to look at how you are jumping to your kernel (step 5), you do know I guess that once you set pmode, the processor is not actually in pmode until you execute a far jump. As you want to jump to your kernel anyway, this is fine, but note that the format in pmode is different, in real mode, the format is segment:offset where each sement is 64k in size, but in pmode, the segment is one of the areas set up in your GDT, beware of this, this is a common mistake

[TexHawk]

Well I issue a jump to my pmode code section based on the segment that is defined in my GDT (base = 0, size = 4GB)

jmp CODE_SEL:pmode

After I clear the instr prefetch queue and reinitialize the segment registers I push a character into the color monitor text-mode area 0xb8000 and this works fine.

If I've loaded the kernel with BIOS (before the pmode jump) to 0x600 can I just issue the command

jmp CODE_SEL:600

to transfer control to the kernel?

Can the kernel be something like:
;**************************************************************
[bits 32]

;gs initialized to CODE_SEL before jump to kernel

mov byte [gs:b8002],'a'      ;test char
mov byte [gs:b8003],0x7      ;attribute

loop1: jmp loop1

Thanks for the quick help!

[Jamethiel]

Umm... Code segments are read-only in PMode. You're probably catching a GPF. Try setting GS to a data segment selector instead of CODE_SEL.

Also, same thing as with the code segment, you need to load your segment selectors -after- you set the PMode bit on, not before, so that the descriptor caches get updated properly.

Hope this helps.

[TexHawk]

Ok,

I tried changing the kernel jump from CODE_SEL:600 to DATA_SEL:600 but when I boot under bochs I still get a CPU PANIC that is something like this:

exception(): 3rd (13) exception with no resolution

And when I try on the test machine it just reboots.  Is anyone familiar with this error or know what might cause it?

[HOS]

well first of all you would probably want CODE_SEL:0x600 and not CODE_SEL:600 but also, like was said, you need to have a data segment also, but load the segment registers after you jump to pmode, cs will be CODE_SEL and the others should be DATA_SEL

[common]

A question that I have here (you may have answered it all ready, but I didn't see it)...have you disabled interrupts using the cli instruction?  If not, you should do so and keep it that way until you have a valid IDT loaded.

[VE3MTM]

That is called a triple-fault, and they are the bane of your existance until you can get interrupt handling going (at least)

Here is what a triple-fault means:
Fault 1: Something bad happens. In your case, probably a bad GDT or improperly executed jump to pmode. An exception is raised (GPF, I believe), firing another interrupt.

Fault 2: There is no IDT (interrupt descripter table, the thing that maps interrupts to handlers), so it fails to find a handler for that error. It raises another exception (another GPF? or is it a double-fault exception?), and another interrupt is fired.

Fault 3: This is really a repeat of the second fault. Since there is no IDT, it couldn't find a handler for the second fault. At this point, the CPU dies horribly and you get an error something like the one you got. If you were on a real computer, not an emulator, the CPU would have reset itself and done a soft-reboot.