OSDev.org

hiya,

in the light of my OS development going down for the time being, i was thinking of writing my own bootloader.

i was just wondering what you would want in a bootloader?

i was thinking (quite obviously):
- a20 enable
- protected mode entry
- multiboot compliance

but is there anything else that (maybe just your OS) would like to see in a bootloader?

Some ideas:

• To give you the memory map of the system / total ram installed
• To be able to load your kernel in higher half
• To set a vbe mode / vesa 3.0 pmode entry
• Long mode entry in case the kernel wants it
• Multi FS support (fat12/16/32, ext2/3, no fs), multiple hardware(usb drive, floppy drive, hard disk)
• Display a logo while your kernel and ramdisk is loading

Cheers,
Gonzalo

Hi,

Some ideas...

First, I'll use the words "boot code" instead of "boot loader", where "boot code" includes everything that occurs before the kernel is operational (which may be split into many separate stages, beginning with a boot loader).

Before switching to protected mode (IMHO) it's best to gather any/all information that the kernel needs from the BIOS, so you don't need to bother with switching back to real mode (or using virtual8086 mode) after. Here's a list of things to consider:

• Getting APM information (e.g. for older computers without ACPI)
• Getting all the information the BIOS will give you about storage devices.
• Setting up a default video mode using BIOS/VBE (e.g. in case there's no video driver for the video card). This may include setting a video mode that was selected while the OS was running (and stored somewhere that the boot code can find), and getting a list of all possible video modes and passing this list to the OS (so that people can choose a new video mode and reboot; and so that you don't need to bother with virtual8086 mode for this). It might also include getting DDC/EDID information from the monitor.
• Asking the BIOS if PCI configuration space uses "mechanism #1" or "mechanism #2".
• Getting a map of the physical address space (not just detecting available RAM).
• Loading anything the OS will need before file systems, etc are working into RAM. For a monolithic kernel this might just be the kernel. For a micro-kernel this might mean a large number of separate files, or a single archive of many files (e.g. a boot image).

Other ideas (for before or after enabling protected mode) include:

• Decompressing files that were loaded (e.g. to improve boot times by loading less from disk).
• Code to test the CPU to see if it's capable of running the OS - I do this early during boot (just in case someone tries to boot an ancient computer that doesn't support protected mode).
• Checking some sort of checksum (CRC, MD5) for each file that was loaded into RAM to ensure nothing went wrong.
• Setting up paging for the kernel, so that the kernel itself doesn't have to handle 2 different addressing schemes (with and without paging).
• Code to display messages from boot code in any video mode that may have been selected. This could involve storing the messages in RAM so that the data can be saved as a log file later on (e.g. "var/log/dmesg").
• Code to make the "PC speaker" beep if something goes wrong (in case there is no video card - headless systems).
• Code to send messages from the boot code to the serial port (headless systems again). This could involve buffering the messages, so that someone can connect a dumb terminal after the computer starts beeping to find out why boot failed (so they don't need to reboot to see messages they missed before they plugged the dumb terminal in).
• Waiting for a UPS battery to become charged. Note: There's a minor problem with most UPSs - if the power fails then there's usually enough battery power to let the OS save data, etc (so no data is lost, file systems aren't corrupted, etc); but if a second power failure occurs soon after the first power failure, then the battery may not have enough charge to keep the OS running long enough to save it's data and the data can be lost anyway (in this case, the purpose of having a UPS is defeated). Halting during boot until the battery has enough charge avoids this problem.
• Code to test if RAM is faulty or not.
• Some way of controlling options in the boot code - for e.g. to force the boot code to assume the computer is headless, specify a default video mode, to tell it if RAM testing should be disabled (or maybe if RAM testing should be run continuously, like "memtest86k"); and possibly to control kernel options too.
• Possibly, start AP CPUs and check the features supported by all CPUs, and then use this information to decide which kernel to boot (e.g. a 32-bit kernel or a 64-bit kernel, a single-CPU kernel or a SMP kernel, or...). Imagine a generic boot CD that includes several kernels and automatically selects the right kernel to use (e.g. for installing the OS).

IMHO modularity is also a very good idea. For example, most of this can be shifted out of the boot loader/s and into a second (or third) stage; and it'd be good to have a module for sending the boot messages to video, another module for sending the boot messages to serial, another module for sending the boot messages to an IP address (via. telnet), etc (where you'd only install what you need).

Also, one of the things I do is split the boot code into "firmware dependent" and "firmware independent" parts, where the firmware dependent code gathers whatever information it can and puts the information into a standardized format (and puts the computer into a standardized state) and the firmware independent part uses this standardized information so that it doesn't need to care what firmware was being used. That way you should be able to support EFI/UEFI, or LinuxBIOS/Coreboot, or OpenFirware, or anything else just by writing a new boot loader, without touching the rest of the boot code or the OS itself (in this case it's important not to use virtual8086 or something after boot, because you can't use normal BIOS functions on EFI or Coreboot or something else because they just don't exist).


Cheers,

Brendan

Thanks guys (particularly brendan ) this should keep me busy for a while. Any other ideas are more than welcome though!

i shall post again soon with clearer ideas, and a project plan (or if you're really interested: check my sitehttp://xd-dunce.co.cc. it should be up to date with ideas and such.).

Thanks alot!

James.

P.S. pre-warning for my website: it's quite basic at the moment. haven't done any html in a LOOONNNNGGG while (maybe 2-3 years now). so the layout is currently quite bad, but i am close to a better design being uploaded soon.

Because of the way my OS was designed, (a game console type os, for x86), it has end up as a very good bootloader for other OS's.
It can load a image to anywhere in ram.
It as built in driver for floppy, hdd, atapi, usb, fat12, fat16, fat32, vesa,
It can call BIOS function from Pmode
It as 100's of built in functions
It as both a CLI and GUI interface
Plus much more, but is still only a single exe, less than 64K in size.

Dex, Ive been looking at your source out of curiosity, and I was just wondering, where is the code that does the setup to call BIOS ints and then returns to pmode?

Just to make sure it gets mentioned clearly: I want a bootloader that cleanly supports Dual booting, if the bootloader detects multiple bootable partitions.
And the bootloader absolutely must have a mechanism to let the kernel know precisely where all the "modules" get loaded in memory. It would also be good if there is a way to tell the bootloader *not* to load anything into a particular chunk of memory, because the kernel intends to use it.

64-bit support would be awesome. I know the Pure64 bootloader made by someone on the forum does this, but I wouldn't be able to package it with my GPLed OS and it lacks ext2 support. Right now I have an indirect method of loading using grub and an intermediary kernel, but I would like something cleaner.

bewing wrote:I want a bootloader that cleanly supports Dual booting, if the bootloader detects multiple bootable partitions.

that was the first idea i had, and was going to use it in an early release.

JohnnyTheDon wrote:64-bit support would be awesome. I know the Pure64 bootloader made by someone on the forum does this, but I wouldn't be able to package it with my GPLed OS and it lacks ext2 support. Right now I have an indirect method of loading using grub and an intermediary kernel, but I would like something cleaner.

this may take a bit longer to implement, but i do see it happening (over active imagination IMHO )

Dex wrote:Because of the way my OS was designed, (a game console type os, for x86), it has end up as a very good bootloader for other OS's.
It can load a image to anywhere in ram.
It as built in driver for floppy, hdd, atapi, usb, fat12, fat16, fat32, vesa,
It can call BIOS function from Pmode
It as 100's of built in functions
It as both a CLI and GUI interface
Plus much more, but is still only a single exe, less than 64K in size.

well then i know where ill be stealing my source code from

but seriously... this is a great learning experience for me, and gives me a chance to show exactly what i can do. if i can get even a tenth of these suggestions into a bootloader, i will be happy. but i will try to get them all (if possible. maybe a change in storage medium is required). i can't wait to get started on it all.

thanks for the suggestions guys!

yemista wrote:Dex, Ive been looking at your source out of curiosity, and I was just wondering, where is the code that does the setup to call BIOS ints and then returns to pmode?

In the include file named "RmInt.inc" , in the Functions folder.