OSDev.org

Ah spring, when a young man's fancy turns to thoughts of... writing a bootloader.

Well, that's how it seems, with all these posts. I don't want to discourage anyone from writing a bootloader, but if you know what you're up against, you might change your mind and use GRUB after all.

First of all, the boot code must fit into 512 bytes.

• This is a job for assembly language. If you hate asm, forget it. If you don't know asm, forget it.
• You must know your tools. When I wrote a bootsector, NASM made code that was larger than necessary. I had to figure out why this was happening, and work around it.
• If the code for what you want to do won't fit into 512 bytes, then you must write the bootloader in stages. Stage 1 fits into 512 bytes, and does nothing more than find, load, and run the larger Stage 2.

It's convenient to have Stage 1 understand a filesystem. This lets you treat Stage 2 as a regular file. Can you write a FAT12 bootloader in 512 bytes? I know you can, because I've done it (see http://my.execpc.com/~geezer/osd/boot/fatboot.zip). But there are severe limitations:

• No room in the code for error messages. If something goes wrong, the loader just beeps
• Stage 2 must run in (or start running in) real mode (16-bit)
• Stage 2 must be in binary format, without headers or relocations
• Stage 2 must be stored in the root directory of the disk

OK, you accept all these limitations. Can you now write a 512-byte Stage 1 for FAT16 or ext2? The FAT16 code is slightly more complex than FAT12, and ext2 is much more complex. More seriously, since FAT16 is meant for hard drives, the boot code must now support both CHS (INT 13h AH=02h) and LBA (INT 13h AH=42h). Maybe you can squeeze
some code into 512 bytes that works on your computer, but it won't be very robust. When you ask other people to try out your OS, your code will fail because their computers are different from yours.

So you give up on the filesystem-type bootloader. New plan:
embed a map of the disk sectors used by Stage 2 into the Stage 1 bootsector. This is how GRUB's Stage 1 works. No big filesystem code, so now there's room in the bootsector for both CHS and LBA code and for text error messages, though they're short and cryptic ("Geom Error"). And this type of loader works with any filesystem.

But where does the sector map come from? It must be created by an install program. GRUB has an installer that runs from the Linux command prompt. GRUB Stage 2 also has an install program built into it, invoked by the "setup" command. So you've made your Stage 1 loader smaller and simpler, but all the complexity has moved into the install program (or into Stage 2).

And an installer is not all that's built in to GRUB. It has:

• read/write code for various filesystems (and VFS layer!)
• code to switch to real mode to call 16-bit BIOS interrupts
• command-line and menu user interfaces
• code to read ELF, a.out, and Multiboot executable files
• code to support compressed (gzip) kernels and modules
• simple memory management code
• serial port code
• network code!
• C library code: printf(), strcpy(), etc.

In other words, GRUB is like a small operating system! Beware of setting out to create one OS (e.g. a Linux clone) and get bogged down creating a different OS (a fancy bootloader).

Summary and suggestions:

• Writing a bootloader is not as easy, fun, or interesting as you might think
• Use GRUB to boot 32-bit kernels
• Use MS-DOS or FreeDOS to boot 16-bit kernels
• If using GRUB really bothers you, write your own bootloader LATER, when you have something worth booting

Peace

..

*gg*
when spring comes bringing along the sweet fragrance of life and colourful flowers, my fancy is more attracted by the hum of the bees and the whisper of the wind's voice at the birch's 'n'oak's summits, where it plays it's games with lovely leaves longing for the sun.

Chris, you are damned right, that it's a messy task to write a bootloader, espacially one that shall support a file system. I have nevertheless stuffed together one small crappy bootsector just to know how that thing runs, nothing special, nothing huge, just a bootloader that loads the kernel, prepares protected mode and jumps to that thing. since my kernel grew faster and faster as soon as I got beyond asm and triple fault stage *rofl* - which didn't last very long, just a couple of weeks to get things sorted out - and delved deep into process management, console drivers, I found out, that my small bootsector has overcome it's right for existence - and for I am not the one who is so smart and though to reinvent a perfectly constructed wheel, I started using grub.

Grub is something easing your life soon after you have decided to link an elf kernel and stuffing the bytes and def's needed by grub into the asm layer of the kernel where is located the entry point and several lowlevel init routines ... Yo', and thus I got rid of the need to use dd, since a simple cp in my script suffices.

@Perica: Do you really intend to design a new file system?

..

tough guy you are. I hold thumbs that you get it running.

>Use MS-DOS or FreeDOS to boot 16-bit kernels

please tell me,

1. how can we do it ?

2. is the dos boot loader available freely ?

many thanks

suhmaamiar

Suhmaamiar wrote: >Use MS-DOS or FreeDOS to boot 16-bit kernels

please tell me,

1. how can we do it ?

2. is the dos boot loader available freely ?

Most 16-bit compilers for x86 create DOS executables (.COM file or .EXE file), so it makes sense to build your 16-bit x86 kernel as a DOS executable, then use DOS itself (not the DOS boot loader) to load your kernel.

DOS is available under Windows 9x as "MS-DOS mode". If you're running Windows NT/2k/XP or Linux, you'll can install FreeDOS and use it instead.

Perica Senjak wrote: What do you think of the FileSystem "Reserved Area" idea? I would not have to put any FileSystem code in the BootSector (That would be left to the SecondStage loader );

I think this is a good idea. A region of contiguous sectors reserved for the bootloader at the start of the disk would really simplify things. FAT supports this but I forget if ext2 does or not.

Offical GRUB site, with source code: http://www.gnu.org/software/grub/

I wouldn't push grub out of my bed (in german we say ... das w?rd ich nicht von der bettkante stossen - it is hard to translate to something with similar sense in english). It is very convenient and once you got used to multiboot headers and other stuff, you can work with it straight forward.