creating an image to test grub-loaded kernel with bochs

[bkilgore]

Hi.

I've been using bochs extensively to test my code in the past, and up until a few days ago this was relatively easy to do. I had my own bootloader, which would simply load ther kernel starting from sector 2, so to create a floppy image to load into bochs, i would simply combine the files before launching bochs, and use it as the floppy, and everything worked fine.

A few days ago, my kernel became too big to work with my existing bootloader. I decided it wasn't worth the effort at this time to figure out why my bootloader wasn't working, and finally make the move to switch to grub. I ave successfully created a bootable floppy, to which i can simply copy my kernel and boot in a regular pc and it works fine. However, no this means i have to take the time to copy the kernel to the floppy, and then boot off the floppy, which adds considerable time, especially since I am used to testing very small changes until i get something just right (i do a LOT of testing). Now this adds considerable time to development i'd like to avoid.

I was wondering if anyone has any idea how to create an on-the-fly grub-bootable image like i used to do with my own bootloader? I've looked into it, and it seems like it would be difficult because grub hard-codes offset to stage2 into stage1, so i'm not sure how this would work. is there a way to create a filesystem-fee grub bootdisk? i know the default one is, but it won't boot anything, only load the setup program. can i force grub to boot my kernel from a specific sector? am i missing something big? thanks for your help!

[Solar]

When copying your floppy into an image, sector order is preserved, so you shouldn't have a problem...?

Then again, that still means you have a write / read cycle on the floppy drive. Since kernels aren't usually that big (I mean the self-written ones, not Linux ), perhaps you could consider setting up a toolchain within Bochs.

You could take one of the available Linux images, create your compiler toolchain in there, and do your development in Bochs. It'll be slower, but perhaps still faster than writing / reading from floppy everytime.

[bkilgore]

You're right, if I copy it to an image, that works fine. That's what I'm doing for now, or just running it off of the floppy directly. But I'm looking for a way of making a floppy image without actually using the drive, preserving the position of stage2 in the image.

My only thought right now is that i can take this oppurtunity to write some fat12 code, and then write a little program that will take a file, treat it as a fat12 disk, and write files onto it. This way, I can just have the program automatically overwrite my kernel on the current disk and modify the FAT tables accordingly.

That's currently what i'm working on, but if anyone has any better ideas i'd love to hear them.

[Solar]

Still not sure if having the dev toolchain within Bochs (and thus writing directly to the image file from *within* Bochs) isn't easier during early development stage.

That's probably what *I* will be working on next. (Unless someone points me to a Linux Bochs image with gcc 3.2.* installed...)

[Pype.Clicker]

an alternative would be to use the "loop device" feature of Linux : get a snapshot of a FAT-formatted floppy in a file (cat /dev/fd0 >floppy.img does it nicely), then mount that image with the loop device (simulating a disk with a file) and put/remove files as you would do with the floppy, but without the ugly floppy latency

from "man mount:"

THE LOOP DEVICE
One further possible type is a mount via the loop device.
For example, the command

Code: Select all

         mount /tmp/fdimage /mnt -t msdos -o loop=/dev/loop3,blocksize=1024

will set up the loop device /dev/loop3 to correspond to
the file /tmp/fdimage, and then mount this device on /mnt.
This type of mount knows about three options, namely loop,
offset and encryption, that are really options to los?
etup(8). If no explicit loop device is mentioned (but
just an option `-o loop' is given), then mount will try to
find some unused loop device and use that. If you are not
so unwise as to make /etc/mtab a symbolic link to
/proc/mounts then any loop device allocated by mount will
be freed by umount. You can also free a loop device by
hand, using `losetup -d', see losetup(8).

[Solar]

See? With Unix, everything is possible - if you know someone who can tell you how.

Good advice, Pype!

[distantvoices]

that trick is cool ) Now I don't have that floppy scratching anymore ) Nice to read such things and learn from them.

stay safe folks

[nullify]

As an aside, the ability to modify a floppy image directly is also possible through Windows NT/2K/XP using a virtual floppy driver (http://chitchat.tripod.co.jp/vmware/vfd.html) a friend of mine found some time ago.

I have not used it in awhile, but I think (unlike WinImage) the process can be automated, since it has a console version.

[bkilgore]

Thanks you for all of your answers! I think I'm going to try a virtual floppy driver for windows first, since that's the OS I mainly dev in.

Solar: I get better what you mean now about setting up a toolchain within bochs, and that sounds like it wouldn't be too hard, but i'm going to try to stay with windows if i can.

Pype: the loop device--what a wonderful, wonderful tool. Thanks for the tip!

[Tim]

Also for Windows, do a Google search on FileDisk. It's a driver which acts pretty much the same as the Linux loopback device.