OSDev.org

Hi every,
I am trying to get my second stage boot loader up and running and am running into some conceptual difficulties.

Currently my first stage boot loader does the following:

• Clears the screen and sets a stack (for proof of concept)
• Resets the disk controller back to the first sector on the 0th head/drive
• Reads this into a disk buffer at 0x7E00 (just beyond where the boot loader is loaded into memory)
• ... unimplemented, a jump to that memory location to continue execution of stage02

My stage02 boot loader is simple, originating at 0x0000 for now, all it does is the following:

• Writes a message to the screen (it has some data and code for this, using BIOS functions).

I compiled the stage02 code using the following command:

Now here comes my confusion. Usually, as I have been walking through single stage boot loaders and simple code examples, I have had the following workflow: where I can directly execute this code: OR

I can create a bootable image using the following commands: then finally running that image in bochs.

In my first example, would I be able to compile my stage01 boot loader, my stage02 boot loader, and then append stage02 binary to stage01 binary? That doesn't seem correct, as I need a FAT on my second, which isn't present in the current code.

It's 1am here now, and I can't formulate my words completely correctly. I will reformulate my question tomorrow morning to make it more clear.

FAT is not a requirement, it's a file system. There are many file systems, non of which are a requirement to boot.
Yes, you can simply stick your second stage to the 2nd sector and read it in if you'd like, and it will happily run as long as you told the assembler the correct origin.

You only need a way to know which sector(s) to load, this can be in the form of a file system, or simply a hard-coded value. A file system makes things much simpler for creating/naming files of course . My point though is that a file system is not required, you can read a device block by block as long as you know what block contains what information. This is where the file system is handy, it stores the block information for a file as long as you know its name, and it is much more dynamic than a static list of locations (as in, you can create a new file or modify it's size and change it's physical location on disk and still be able to access it without issue).

Ready4Dis wrote:FAT is not a requirement, it's a file system. There are many file systems, non of which are a requirement to boot.

Correct that is how I understand it, yet I was under the impression that we wanted the second stage to be a FAT formatted section, so we can read it as one, although I could be mistaken. If that was true, I was wondering how to format that binary image as a FAT formatted image, but now based on what you are saying, I feel that is an incorrect approach. Then again, should I be dealing with strictly binary images at this point still? (Most probably)

The confusion arises because I get some resources that I am looking at that mention that Floppy Disks are FAT12 formatted. Example:

Or you could read up on FAT12, the filesystem used on floppy drives, and implement that.

which makes me assume that any sector past the 512 Byte boot01 bootloader is formatted according to the FAT12 standard. I am most likely mistaken.

Ready4Dis wrote:Yes, you can simply stick your second stage to the 2nd sector and read it in if you'd like, and it will happily run as long as you told the assembler the correct origin.

So I can simply(?): and get my (hopefully) intended results? What if I wanted to make this into an iso image?

Thank you for all your help thus far, and I hope I am not asking too many questions.

which makes me assume that any sector past the 512 Byte boot01 bootloader is formatted according to the FAT12 standard. I am most likely mistaken.

You can format the disk any way you like. And, since Fat12 supports hidden sectors and reserved sectors, you can put your kernel boot loader + kernel in the first 10 sectors and still have a fat12 formatted disk. There is nothing saying a floppy disk has to be formatted fat12 or any file system. You can create your own file system if you'd like and use that. A disk is nothing more than a collection of sectors, how you choose to use them is up to you. The nice thing about Fat12 is that just about any operating system in existence supports it at this point, making it very easy to copy files.

Then again, should I be dealing with strictly binary images at this point still? (Most probably)

See previous statement, you can just set them as reserved sectors and use them as a flat binary if you'd like, or you can find an example of a fat12 boot loader and start using fat 12. The decision is up to you honestly.

and get my (hopefully) intended results? What if I wanted to make this into an iso image?

Well, i would hope, but I can't say for sure as I don't use the same tools as you. I wrote my own image creator along with my own formatting utility and a utility that copies my bootloader and mbr to disk. Doing a cat should work as long as the first sector is 512 bytes, and hen you compiled your kernel, you told where it was going to be (if using assembly, this is typically the [org] directive). You said in your initial statement it was "originating at 0x0000 for now", that should not be the case. If you're loading it to 0x7E00, then it needs to be at that origin (either via linking if you're using a linker, or via the org directive in your assembler). Just like your boot loader needs to know it's at 0x7c00, your kernel needs to know its location. I never tried making an iso (cd image?), but look into el torrito, that's the standard for bootable cd images. Normally you can just take your floppy image and use a bootable cd creator and it should work just fine as long as you have a bootable floppy image to give it.