bin loader vs grub

[Ozguxxx]

Hi, writing and debugging code about 5-6 hours I finally managed to write a simple bin loader at boot time to anywhere in ram. It currently just loads a kernel linked as a bin file. I load loader by very simple 512 bytes boot code. After that it goes into pmode and loads kernel from fat12 floppy by using 32 bit floppy driver. Struggling not to use grub, I think this is a good start to load more complex files (like elf kernel, etc) I dont know; it also can be used to load modules from floppy. Anyway, after reading about Great Teacher Tim's tutorial that first 1 Meg should be untouched, I thought it IS inevitable to do this. Anyway... You say what does that have to do with us. Question comes: Can somebody tell me or show me somewhere to learn about what grub exactly does at boot time? Thanx...

[Solar]

Question comes: Can somebody tell me or show me somewhere to learn about what grub exactly does at boot time? Thanx...

Well, the idea of the Multiboot specification is that you shouldn't care for anything but the state in which a Multiboot compliant bootloader gives your kernel control of the system.

If that's what you are looking for, look for "Multiboot specification" v0.7 (available from several mirrors), or check the GRUB online manuals. (Hint: www.gnu.org/manual/ is a good entry point for any questions on GNU tools...)

If you are after "learn, then copy", then you should:

a) get the GRUB sources (since I don't know about any "GRUB internals" tutorial), and
b) be aware that this could easily qualify as "work based on GPL'ed software", which might not be what you want.

[Ozguxxx]

Well I just want to see what grub offers and see if they are useful for me. Then I will try to write as good as I can to get what I want. I want to get new inspirations about what a good bootloader is. I am not going to copy any code or ideas.

[Solar]

Well I just want to see what grub offers and see if they are useful for me.

Then check the Multiboot Specification. That is basically a "contract" between bootloader and kernel. A given Multiboot compliant bootloader can boot any Multiboot compliant kernel; a given Multiboot compliant kernel can be booted by any Multiboot compliant bootloader.

In a nutshell:

GRUB boots from the MBR (Master Boot Record), reads the partition table, reads a "stage 2" (where to find that it has been told when installed in the MBR), reads some data from the BIOS, switches to protected mode / enables A20 gate, reads a configuration file, and executes the commands listed in there. (Usually a boot menu - which kernel / system to boot.)

This gives you the ability of changing the configuration without ever touching the bootloader - all you need is editing the config file in a text editor.

Then it loads the specified kernel into RAM, sets registers and flags to values defined by the Multiboot specification, sets up some data structures (among others containing the BIOS data read earlier, like available memory, drives etc.), puts a pointer to the struct in ebx), and passes controll to your kernel image.

Major advantages:

* quite some info has been read from BIOS already, so you don't have to;
* pmode / A20 are already enabled;
* your kernel can be a standard issue ELF file (or a.out or PE!);
* no special magic done to the kernel image - compile, and copy it where the GRUB config expects it;
* no limit on the number of kernels that can be booted from the same file system (like, C:\boot on your FAT32 Windows partition);
* GRUB reads various file systems, and can even boot across a network.

Bottom line, GRUB basically does all the stuff every decent OS has to do, and starts you up to the point where you can begin doing things differently.