saltlamp wrote:
I'd say, If your not using a fixed file-system and/or not on a very small storage medium,
This is true. However my OS is not DOS-like, does not use fixed filesystem nor is it limited to very small storage, yet I decided to roll my own loader. My reasons were:
- My OS is 64 bits only, and GRUB is simply not capable of booting ELF64 executables (Multiboot protocol is protected mode only!).
- Multiboot's "machine state" is not sufficient for modern hardware. What's the status of floating point extensions and SMP for example?
- Since mine is a micro-kernel, I prefer to load an initial ram disk with the kernel executable inside. GRUB does not support this, because grub.cfg specifies kernel and initrd as two separate files.
- What's more, I boot my kernel on AArch64 machines too. There's simply no GRUB on that platform. (There's an U-Boot hack with
an unofficial third-party Multiboot implementation, but that's 32 bits only, and the changes to the Multiboot structure for ARM are not standardized at all.) From
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot:
Quote:
However multiboot1 is very x86 specific. multiboot2 is cross platform but doesn't currently support ARM. Both are more complicated than what is needed on ARM.
- Which leads us to my final point, my multi-platform bootloader translates everything into a machine-independent structure, something GRUB won't do for your kernel. You see, my kernel does not know nor care if for example the memory map was provided by E820, EFI_Get_MemoryMap, GPU MailBox calls or whatever, it receives the map in exactly the same format with exactly the same memory type codes on all platforms. Unlike Multiboot, you can implement this on new platforms without the need of updating the spec.
saltlamp wrote:
then develop your operating system first, using another boot-loader; then, if you want, you can write a boot-loader.
This design scheme (platform agnostic boot protocol) is very essential in my kernel, I couldn't patch it into an existing one. It had to be designed that way from the start. All I'm saying here is, if you choose to write your OS first, and you add the bootloader later, then be prepared for a kernel rewrite (I see no point in developing yet another Multiboot bootloader for your existing kernel which loader would have exactly the same restrictions as GRUB, but probably less roboust and less stable, imho). I think if you want to write your own bootloader, there has to be a good reason, something that you can't do with Multiboot, and you should start with that loader. Imho.
Cheers,
bzt