MoS Boot Loader

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Post Reply
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

MoS Boot Loader

Post by neon »

Hey everyone,

As some of you may know I have been rewriting my bootloader from scratch. I wanted to give it a very clean design and easy to add features and extend on.

MoS Boot Loader - Design

MoS is a typical two stage boot loader composed of three programs. Stage1 (Stage1.sys) is a flat binary program that loads and executes the 2nd stage image (KRNLDR) depending on the media type and file system type that Stage1 is meant to work with. The MBR program is responsible for loading the boot sector on the primary boot partition and is also coinsidered a stage 1 program.

KRNLDR is a image file composed of two programs: the Startup Module (Startup.sys) and OSLoader.exe. Startup.sys puts the system into protected mode and basic system initialization. It also provides a 32bit<>16bit interface to call the BIOS from protected mode as well as interfacing for EFI firmware (Once implemented anyway). It also executes the 2nd program within itself--OSLoader, and passes boot time information (Boot drive, Boot filesystem) to it as well as its 16bit interface routine, io_services).

OSLoader.exe is the core of the bootloader written in Microsoft Visual C++ 2008. It provides abstract interfaces for different file system types, media types, network booting, boot menu, chain loading support, internal command parser, and optional boot time utility programs. It uses io_services passed from the startup module for calling BIOS or EFI routines from protected mode.

OSLoader.exe and Startup.sys are merged together using a small program I made into the KRNLDR image file that is loaded by a Stage1 program.

Features

Currently lacking in features, but here you go:

>Stage1 for FAT12 floppy media and MBR is completed
>Startup.sys is completed
>Enters protected mode very early to aid in catching problems using its IDT
>Portable: Works in tested laptops, PCs, Virtual PC, and all tested versions of Bochs
>OSLoader has FAT12 support and an abstract file system interface. Soon to support FAT16 and FAT32
>Internal command parser

Features soon to come:

>Full multi boot compliance;
>More filesystems that we will look at: fat16, fat32, etfs, hpfs, ntfs
>Full partitioning support (Its not fully implemented yet)
>More media boot devices: CD, DVD, USB, HDD, Full network booting support
>More Boot time utility support: I have a few boot time programs in mind that can be useful...
>Chain loading implementation

Screenshots

Here is the boot loaders main menu. It provides several boot time options that can be added to via the internal command parser.

Image

Heres the internal command parser running different commands. Some of these commands will be changed though as to provide an easier way of working with boot time configuration and to allow running boot time scripts:

Image

Im not releasing it yet as it is not yet ready for release. I want to see if I can throw in a few more features before its first release. Let me know what you think and if there are anything you would like added ;)

I am also looking for comments on its design. ie; improvements? Is it a good design? Any form of feedback is always helpful :)
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
User avatar
Troy Martin
Member
Member
Posts: 1686
Joined: Fri Apr 18, 2008 4:40 pm
Location: Langley, Vancouver, BC, Canada
Contact:

Re: MoS Boot Loader

Post by Troy Martin »

Nifty! Keep up the great work! I ought to do a multi-stage interpretive bootloader for my OS, it would be so much easier to have boot-time options. Even though no mode switching is neccesary!

Hmmm, I should find out if FAT12 leaves any sectors blank and use those... I can fit I/O and string routines into less than 384 bytes and write a simple shell in less than 1024...

EDIT: Yep, I finished a second-stage bootloader sort of like yours in three hours and 1.6 KiB for TBOS 0.4.0!
Image
Image
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
I wish I could add more tex
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: MoS Boot Loader

Post by neon »

EDIT: Yep, I finished a second-stage bootloader sort of like yours in three hours and 1.6 KiB for TBOS 0.4.0
Cant be sort of like mine if its that small - My boot loader's 2nd stage binary is 30 KB ;)

Its always nice to see more boot loaders being developed though. Nice work :D
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
User avatar
Troy Martin
Member
Member
Posts: 1686
Joined: Fri Apr 18, 2008 4:40 pm
Location: Langley, Vancouver, BC, Canada
Contact:

Re: MoS Boot Loader

Post by Troy Martin »

Thanks, but the file code is based off of the MikeOS bootloader (which is based off of someone else's PD bootloader I think). So I can't take all the credit... ](*,)

30 KB!? That's five times the size of my whole kernel!
Image
Image
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
I wish I could add more tex
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: MoS Boot Loader

Post by neon »

30 KB!? That's five times the size of my whole kernel!
Im surprised here ;) I figured my boot loader was pretty small compared to other commercial boot loaders... In any case, it'll get bigger once the missing features are implemented.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
User avatar
Troy Martin
Member
Member
Posts: 1686
Joined: Fri Apr 18, 2008 4:40 pm
Location: Langley, Vancouver, BC, Canada
Contact:

Re: MoS Boot Loader

Post by Troy Martin »

Then again, my kernel is real mode with very heavy use of the BIOS functions. Fun fun fun!
Image
Image
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
I wish I could add more tex
User avatar
Dex
Member
Member
Posts: 1444
Joined: Fri Jan 27, 2006 12:00 am
Contact:

Re: MoS Boot Loader

Post by Dex »

Well done neon, if i understand your comments right, you can go back to realmode to call bios int etc, with this it is very easy to implement basic USB support, using int 13h, because if the bios support booting from USB, when you go back to realmode, you can read/write to the USB device as easy as say a floppy, that is if you booted from it in the first place.
User avatar
neon
Member
Member
Posts: 1567
Joined: Sun Feb 18, 2007 7:28 pm
Contact:

Re: MoS Boot Loader

Post by neon »

Well done neon, if i understand your comments right, you can go back to realmode to call bios int etc, with this it is very easy to implement basic USB support, using int 13h, because if the bios support booting from USB, when you go back to realmode, you can read/write to the USB device as easy as say a floppy, that is if you booted from it in the first place.
Thanks :) You understood it correctly. I suspect USB booting would be pretty simple, unfortunately I have no way to test it as my machines do not seem to support it :(

In any case, I am considering taking a lesson from Vista and separating my OS-specific loader from the generic machine loader and have KRNLDR load and execute my systems loader.exe if we are booting MoS, again, passing io_services so it can call the BIOS in protected mode. This way loader.exe can re-enable paging, setup basic page tables, load the kernel and all boot-time driver files, as well as any more initialization needed before passing control to the kernel for driver initialization.

I feel this may be a cleaner design (although adds a little more complexity to it). Any suggestions are always welcome ;)
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
Post Reply