Problem booting from floppy

[Sean]

I have been developing a small stage2 bootloader in c/asm to run off of a floppy, and I've run into a problem. When I have bochs use a disk image for a floppy, everything works fine; however, if I write that image directly to a floppy and tell bochs to use the physical drive, my stage2 loaer acts up.

Currently, the only thing my stage2 loader does is output the amount of memory and check if the processor is supported. All of this works fine from the image. When I write this to a real disk, I can only access the video memory from my assembly code. Can anyone help me out? I don't know what the problem could be if it only occurs when using a real floppy.

Some specs:
bootblock:
-size = 2 sectors
-loads the 2nd sector using int 0x13, then the on-disk header to find information about the stage2 loader
-enables A20
-goes into unreal mode and loads kernel
-goes into protected mode and jumps to stage2 loader

stage2:
-entry point set to 0x10000
-finds total memory
-checks for cpuid support
-prints total memory

(note: In an attempt to debug the situation, I placed several writes to video memory before and after the asm stub calls the c entry, so I know it's being called correctly.)

Let me know if you need more information.

[Pype.Clicker]

i'm not sure reading the floppy through bochs is very representative of what would occur on a Real PC with a Real Floppy ...

do you perform appropriate INT13 status checks ?

[Sean]

No, I did not. But it doesn't seem like that would be the problem. I know that my stage2 is being loaded correctly because I placed some asm code in it that writes '123' to the screen.

I have attached the image I'm running so you can see what I mean. Anything written to the screen is being done through the stage2 loader pulled from the disk by my bootblock. The stage2 loader was compiled by djgpp and linked against my 32bit stub assembled by nasm. Let me know if there's any information I could include that would help. Thanks.

(I should also note that I'm still using bochs to test with the real floppy, so it's not even like my stage2 is running on a different hardware.)

EDIT: Let me clarify what I said earlier. I am doing a check in the actual routine that loads the sectors through int 0x13, but I'm not verifying the actual stage2 binary after I load it.

[Pype.Clicker]

So roughly, you suspect that when you're loading through the real floppy, the C code is still called, but has no access to the video memory ...

maybe you could open both the floppy and the image with hexdump (or any other hex editor) and check the content on the floppy is what you expected ...

that sounds really strange. Do you have the source code of that bootloader & stage2 somewhere ?

[Sean]

Here is the source code. It isn't the most beautiful piece of code just yet, but you should be able to follow it. kernel.c is the core of the stage2 loader, and block0.asm is the first and second block of the bootloader. Hope this helps.

[Pype.Clicker]

Code: Select all

   mov ebp, 0x10000
   mov esp, ebp

   call ebx

this looks weird ... i do not remember of a "call <register content>" stuff in IA-32 ...

another thing that could occur is that your "screenOffset" could be in the ".BSS" section of the image (uninitialized data in case you haven't met it yet). If your bootloader did not wipe the BSS before running the C program, the content of that memory area may be garbage ...

now what if the BSS is read on the disk too (it shouldn't but let's say it is). With a file image, there are chances the sectorz you read for the 'BSS' will be full of zeroes and make a valid bss content, while with a real floppy, chances are that it will contain real garbage.

does it make sense ?

what about a small screenOffset=0 in kernelEntry() or in clearScreen() that you could call before you do some kputs ?

[Sean]

Hmmm. I think I may have solved the problem, but I'm not sure. It might have to do with the way I was writing to the disk. Does anyone know how rawrite treats files that aren't exactly the size of the disk? I did a test by making the size of the image exactly the same as that of the disk, and everything works fine now. I'll look further into it, just to make sure. The stage2 loader now works fine using Bochs w/ a real floppy, but I have yet to test it on a real machine.

Pype.Clicker: using the call instruction with a register works just fine. It's a little something I picked up from the OpenBeOS bootloader. It's pretty handy if you're reading the entry point from some data on the disk. And the two lines before it aren't directly related to the jump, they're just setting up the stack for the kernel. EBX is loaded a little while before that.

Thanks for the help. I'll look into that issue with the disk image size. Seems kinda odd to me.

EDIT: The stage2 loader now boots on my real PC and prints the correct amount of memory.