OSDev.org

Thread for reference: viewtopic.php?f=1&t=33784

@Schol-R-LEA: I like the change you made to the bootloader paragraph in your new thread. It says everything that's really needed.

thomtl wrote:Thread for reference: viewtopic.php?f=1&t=33784

I don't understand. There are as many if not more threads about GRUB issues...
viewtopic.php?f=1&t=33766
viewtopic.php?f=1&t=33799
Just to name the most recent two.

Cheers,
bzt

Neither of those threads are about grub, per se.

iansjack wrote:Neither of those threads are about grub, per se.

True, not the software itself, but they are usability issues of grub, and problems loading OSes using multiboot. Perfect examples that grub and its accompanied multiboot protocol are overcomplicated, therefore not as easy option as one would expect. And that was my original point: it's easier to write a boot record that just loads your kernel like Xv6 does (not to mention that you could use Xv6 boot record as-is to load ANY ELF kernel if you don't want to roll your own loader. It is a hell lot easier to install Xv6 boot record than installing and configuring grub correctly).

Cheers,
bzt

I hardly think that a simple typo in a source file represents a problem with the complexity of either the multiboot standard or GRUB.

As for a failure to read the documentation - that's not a problem unique to GRUB.

If GRUB is so hard to use, why do people ITT keep acting like writing a bootloader is a litmus test for programming ability?

Pick one guys, either GRUB is too hard or GRUB users are too dumb to write an OS.

I'm in the process of writing my own EFI bootloader, thus far I've been able to successfully transfer control to my kernel. Now I'm working out the rest.
I was led to this decision by how attractive UEFI looks from an osdev perspective, as well as how difficult I found looking for information on how to configure GRUB2 for UEFI. I know the support is there, but I'll be damned if I can find any good resource on it. Figuring out how to set it up was actually more painful by far than reading the UEFI spec, from which I actually learned something.
For me this process has been rewarding. I haven't gotten everything finished yet, far from it, but for others the process can be fun and educational. I can see why you wouldn't advise this as required learning for a developer just starting to learn osdev, but it has definitely given me a better understanding of an important osdev concept. I haven't gotten everything figured out yet, mind you.
For me ( and probably many others ) hardware compatibility is not a factor. Getting your hobby OS working in qemu is enough work.
If the general consensus is so against rolling your own, it might be worthwhile for someone to invest some time in writing a good introduction to using GRUB+UEFI in the wiki.

One pro to writing a boot-loader yourself would be in the case of an operating system similar to DOS.

When you are writing a floppy-disk based operating system, saving and not having as many bytes as possible go to waste, is certainly helpful. If you look at the disassembled source for the MS-DOS 5.0 boot-sector, you can see that their is more than just loading files:

https://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm

There is also disk setup, testing for a valid 'System disk', and loading only a fraction of io.sys. You can also set the state for the system post-boot, too, if you need, without having to set the state in another file that gets loaded.

Another advantage, again, is if you are using a file-system that is fixed, like FAT 12/16. The Root Directory is fixed at either 224, or 448, so saving the amount of files put on the disk is crucial. If you can put the same functionality in a file, such as 'bootsect.dos', instead of having another file, maybe 'dosldr.com' or something, which does pre-kernel setup (DOS has no kernel, just an execution monitor, but you get the idea), and just do it in 'bootsect.dos', you saved on file on the disk that could be used for something else.

Just my two cents. If you are not writing a DOS, then IMHO, the boot-loader is a hit or miss. I'd say, If your not using a fixed file-system and/or not on a very small storage medium, then develop your operating system first, using another boot-loader; then, if you want, you can write a boot-loader.

~Joe

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_ ... /Multiboot:

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