Protected mode problem

[~]

By the way, if you load your kernel at 0x100 it will eventually FAIL. It's not a recommendable thing to do.

Anyway, the free memory area for the first Megabyte starts at 0x500, but won't be enough for a full OS.

So, you SHOULD change the lines that read like:

In bootstrap:

Code: Select all

__MyKernelPlainEntry__ equ 0x100

At the kernel start:

Code: Select all

bits 32
org 0x100

-----------------
To something like:


In bootstrap:

Code: Select all

__MyKernelPlainEntry__ equ 0x100000

At the kernel start:

Code: Select all

bits 32
org 0x100000

So that your kernel loads at the start of second megabyte of memory, that in decimal would be the number 1,048,576 or, just after Megabyte #0.

[Nenad]

Tried compiling your bootloader, but I end up with this in Bochs:

Code: Select all

00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8

00001569680i[FDD  ] attempt to read/write sector 204 past last sector 18
00001570904i[FDD  ] attempt to read/write sector 204 past last sector 18

And that's it... It just stops executing...

Added a HLT to the kernel to see if Bochs will react on it, but nothing happened...
Why?

I copied the bootloader to the MBR with partcopy:
partcopy hello.bin 0 200 -f1 (B: disk in windows, since I'm using a virtual floppy disk)

[Combuster]

Would you mind posting a floppy image of the original kernel?

[Nenad]

Which one? Mine (the second one), or the one that "~" posted?

[~]

Before testing the following, have you been successful to use RAWWRITE to copy the disk image previously posted?

I don't use partcopy so I don't know why that happens (hint: try using 100 instead of 200, and make sure the floppy is still usable -that you copied properly the 512-byte file in the first sector-...). I have attached a binary boot sector. In a true DOS console you should write what I'm posting here like this to the floppy:

Code: Select all

C:\>debug boot.s
- w 100 0 0 1
- q

[Nenad]

Nope, didn't use rawrite, since I thought partcopy was just as ok... Is it?
(PS: I think partcopy doesn't detect my virtual drive B: in Windows)

I'm using a virtual floppy, so I have to use debug to write to the floppy like so:

Code: Select all

C:\>debug boot.s
- w 100 1 0 1
- q 

But even after that, I still get...

Code: Select all

00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8

00001569673i[FDD  ] attempt to read/write sector 204 past last sector 18
00001570897i[FDD  ] attempt to read/write sector 204 past last sector 18

...in bochs.

Bochs only displays "Booting from floppy..." and that's it.

The virtual floppy prog I'm using is:
http://chitchat.at.infoseek.co.jp/vmware/vfd.html

[~]

Some pointers:

- If you can, you should post an image of the current floppy you are working on to test it.

- The image posted first (5Kb, test_image.img) is to be copied on a floppy, it's not a boot sector but a whole diskette image. If you haven't yet been able to copy it (and test it in a real machine), you might be mixing things and getting wrong results.

- Test it in a real machine (if you don't have a second one, you'll have to restart it to test it), maybe the floppy drive present screws things up.

[Nenad]

Don't have any floppy diskettes on me right now, and my old floppy drive hasn't seen a working floppy in ages , so I'll have to stick to VFD for now (since my dumb "OS" that I posted a while ago worked just fine on a virtual floppy drive with Bochs, Virtual PC and QEmu)

As for your "test_image.img" file, i didn't copy it anywhere (can't load it in VFD also), I just loaded it with Virtual PC as a CD drive (since VPC won't accept it as a floppy since it's not 1.4MB in size)... Needless to say, it failed to boot...

Am I missing something? Got any other way to load it?

Here's my second version of my Bootloader + Kernel that I have posted a while ago, but in an image file. Give it a twirl...

[~]

Well, I already tried the boot sector I posted, and it works well with my dummy kernel. I post it, and you should use it with the previous boot sector I posted as well, and it should work (it works in my hardware and in my Bochs).

Now, your kernel should be 100% 32-bit Protected mode. If you have BIOS interrupts calls in it, you will have to get rid of them, to begin with. Doesn't your kernel call the BIOS? If so, that's the first problem.

I suspect that you either will have to rewrite the foundation of your kernel (by using what I have already posted), or trying to clarify the way your kernel gets loaded.

-------------------------------
At least, the alternative boot loader does it:

- Loads the kernel from floppy (actually is loaded at 0x1000, so take care about that, but it's strongly recommended to load it at 0x100000).

- Activates protected mode

- Configures DS and ES for protected mode

- Disables interrupts

- Performs a 32-bit far jump to the start of the kernel

- It even turns of the floppy

- The kernel should be 32-bit protected mode program, which means that it cannot call the BIOS anymore, so at this point your kernel core would be loaded in memory and running.


If you want to simplify your work, you may use the alternative boot sector to have your kernel ready into protected mode, and rewrite your kernel to forget reloading the GDT (at least by now) and activating interrupts.

See what you can rewrite and make work just by reconfiguring the stack; it you manage to display messages without using the BIOS, then it means you are starting properly a stand-alone 32-bit kernel.

You might want to create a new source code project to try it out.

[Combuster]

i traced the bug to the code below:

Code: Select all

xor ax, ax
mov ds, ax              ; Set the DS-register to 0 - used by lgdt
(set PE in CR0)
lgdt [gdt_desc]         ; Load the GDT descriptor 

The GDT exists in the binary executing. However it is not located in segment 0, but in segment 0x0100 (CS)
in this case, you should load DS with CS, instead of loading it with zero.

After that, you might want to check that the base points to 0x0100:gdt (0x1000+gdt) instead of 0x0000:gdt.

The IDT should be loaded exactly the same way as the GDT, so that's something to fix as well...

[edit]Like i said before, it is a good thing to familiarize yourself with bochs' debugger. It allowed me to locate the error in under 5 minutes[/edit]