OSDev.org

I am currently trying to plan out my operating system, and was wondering if someone could clarify something for me:

I am going to write my own bootloader. I know that the bootloader is going to sit on the floppy (no hd support yet) within the first 512 bytes.

Tell me if im right here:

My bootloader will operate at 16-bit real mode.
Now, to get to the second stage (yeah, its a two-stage bootloader), I'm going to make a couple BIOS interrupt calls to read from the floppy disk. With these interrupt calls, im going to read "sectors" from the floppy disk (specificly the sectors that contain the 2nd stage bootloader) and then throw them into memory.

Now heres my question:

The first stage bootloader has to be done entirely in assembly for obvious reasons. In order to read from the floppy disk, do I need to implement a FAT12 driver within that 512 limit? I see no other way of grabbing the second stage bootloader while keeping a legit filesystem.

Also,

I'm a little confused what to do after i've loaded the flat binary contents of the second bootloader into memory. Whats the best way of telling the processor to "jump" over to my newly memory allocated bootloader, and start processing its instructions?

Remember, I'm still in 16-bit real mode... My second stage bootloaders going to work the magic and switch me over to 32-bit protected, A20 Line, etc. What do you guys think?

The first stage bootloader has to be done entirely in assembly for obvious reasons. In order to read from the floppy disk, do I need to implement a FAT12 driver within that 512 limit

i'm pretty sure, or you could know the exact sectors where the second boot loader and load those into memory

Whats the best way of telling the processor to "jump" over to my newly memory allocated bootloader, and start processing its instructions?

i would think

my five cents:
instead of spending your time writing a boot loader, spend it reading the grub manual and spend the rest of the time writing your OS.

Hey,

This might help you with developing a bootloader.

You dont need to implement your own FAT12 driver at all. Just parse the FAT12 filesystem to find your second stage loader, and load it to some location in physical memory.

The link I posted above contains several tutorials on developing a FAT12 bootloader from scratch using NASM. The series itself uses MSVC++ as its primary build tool, however it is better to use a cross compiler for better portability support.

Good luck

Hi,

someprogr wrote:The first stage bootloader has to be done entirely in assembly for obvious reasons. In order to read from the floppy disk, do I need to implement a FAT12 driver within that 512 limit? I see no other way of grabbing the second stage bootloader while keeping a legit filesystem.

The FAT filesystem has a "reserved sectors" field in the BPB (BIOS Parameter Block). This determines then number of sectors that are reserved between the start of the partition/disk and the start of the File Allocation Table, including the boot sector.

If you set the "reserved sectors" field to something like 36 then you'd have 35 more contiguous sectors between the boot sector and the File Allocation Table that you could use for your second stage.

Note: If you're tricky you could have a single binary, where the BIOS loads the first 512 bytes at 0x00007C00 and code in the first 512 bytes loads the rest of the binary starting at 0x00007E00. That way you can end up with something like an 18 KB first stage that's in memory from 0x00007C00 to 0x0000C400, and won't need a second stage. This also saves a little space, as things like strings (e.g. error messages) and other data in the first 512 bytes can be re-used by the rest of the code, and you can put routines that are needed later into the first 512 bytes.

someprogr wrote:I'm a little confused what to do after i've loaded the flat binary contents of the second bootloader into memory. Whats the best way of telling the processor to "jump" over to my newly memory allocated bootloader, and start processing its instructions?

If you need to "jump" to your second stage, then using a "JMP" instruction might work...


Cheers,

Brendan

If you dont want to use JMP, you can always use RET or RETF

But yes, JMP is a more standard method

The way that Brendan suggested really is best.
Just extend the first stage bootloader beyond one sector, and have it load the rest of itself, with INT 0x13 commands -- and start reading at sector #2. Even a 5K total 1st stage bootloader can accomplish nearly anything you could ever want.