Against bootloaders

[eekee]

Sorry, Schol-R-LEA, but I'm picking a fight. Not really, I just don't understand just this one point.

This leads to the next big decision: which Bootloader to use. There are a number of different standard bootloaders for x86, with the most prominent being grub. We strong recommend against Rolling Your Own Bootloader, but it is an option as well.

I don't understand this. Fancy bootloaders can leave parts of the computer in unexpected states, especially on non-PC architectures. Even grub on PCs can leave the text-mode cursor enabled or disabled depending on its configuration. U-Boot on ARM selects seemingly random states for even MMU and CPU features, varying from board to board. Some say "Never use U-Boot," and I believe them. If you are stuck with (users using) U-boot you have to reinitialize everything, just as if there was no fancy bootloader in the first place.

Then there's multiboot, which is all touchy-feely "nice", but it's impossible to do right. The ELF standard is vast, no bootloader can implement all of it, so different bootloaders will inevitably implement different parts. If your architecture precludes linking, you don't want ELF object format, or even if you write your own ELF linker, you're in trouble because, when you write the ELF symbols for multiboot into your kernel image, you may not have selected the same parts of ELF as whichever bootloaders your users choose to use.

For example, 9front has a toolchain older than ELF which is perfectly adequate for its own needs. "Multiboot support" is engineered into the kernel so it boots with grub, but it doesn't boot with syslinux. syslinux supports multiboot, so why doesn't it? syslinux's multiboot support must be different to grub's, so where's the "multi" in "multiboot"? pxelinux is part of the syslinux package, what if I want a boot menu on my diskless terminal?

Bootable forths make a stronger example. Linking one of these with gnu ld is a ridiculous proposition, sort-of like building a little dune buggy with a huge crane! A complete interactive forth can be built on a kernel of only some hundreds of lines of assembly language code, well under 1000. Why would you bother linking that? Why would you want to when it goes against the architecture of your system? I don't think it's even limited to forth, I'm starting to see how a more comfortable language & system could be built on such a tiny kernel without any more assembly language.

[nullplan]

I don't understand this. Fancy bootloaders can leave parts of the computer in unexpected states, especially on non-PC architectures. Even grub on PCs can leave the text-mode cursor enabled or disabled depending on its configuration. U-Boot on ARM selects seemingly random states for even MMU and CPU features, varying from board to board. Some say "Never use U-Boot," and I believe them. If you are stuck with (users using) U-boot you have to reinitialize everything, just as if there was no fancy bootloader in the first place.

The boot loader has one job: To load everything needed to boot. In the course of doing so, it may have need of the system's hardware in weird ways, yes. However, if U-Boot doesn't muck with the hardware, the firmware will. So you have to reinitialize everything, anyway.

Then there's multiboot, which is all touchy-feely "nice", but it's impossible to do right. The ELF standard is vast, no bootloader can implement all of it, so different bootloaders will inevitably implement different parts. If your architecture precludes linking, you don't want ELF object format, or even if you write your own ELF linker, you're in trouble because, when you write the ELF symbols for multiboot into your kernel image, you may not have selected the same parts of ELF as whichever bootloaders your users choose to use.

I have no idea what you mean by "vast" ELF standard. For static executables (which a kernel is, if the developers have any sense), ELF consists pretty much just of the ELF headers and the program headers. No symbol gets used anywhere. Now, the problem is that ELF is pretty much made for MMU systems, which most bootloaders don't set up. Which is why I have a separate loader application to get from multiboot or UEFI entry point to the environment my kernel likes.

For example, 9front has a toolchain older than ELF which is perfectly adequate for its own needs. "Multiboot support" is engineered into the kernel so it boots with grub, but it doesn't boot with syslinux. syslinux supports multiboot, so why doesn't it? syslinux's multiboot support must be different to grub's, so where's the "multi" in "multiboot"? pxelinux is part of the syslinux package, what if I want a boot menu on my diskless terminal?

When things like this happen, in my experience it almost always means you aren't following the standard, but rather, your deviations from the standard are tolerable to one implementation and not to another.

[pat]

I don't understand this. Fancy bootloaders can leave parts of the computer in unexpected states, especially on non-PC architectures. Even grub on PCs can leave the text-mode cursor enabled or disabled depending on its configuration. U-Boot on ARM selects seemingly random states for even MMU and CPU features, varying from board to board. Some say "Never use U-Boot," and I believe them. If you are stuck with (users using) U-boot you have to reinitialize everything, just as if there was no fancy bootloader in the first place.

Which is why you pretty much just disregard the delivered state, and put things in what your system considers to be valid starting states. One piece at a time as you bring different parts of your OS up.

Think of off-the-shelf bootloaders as a handy tools that spares you the tedium of mucking about in real mode. In grub's case, it gets you to protected mode, gives you some info about the system's memory and where your modules are plus a few other things. Then you just take it from there in a much nicer environment than what you'd have to start in otherwise. I like to use a second stage that performs some setup and sanity checks before getting to the kernel proper. Makes the kernel cleaner: either it starts in a valid configuration (with all the info it needs), or it doesn't start at all.

[Schol-R-LEA]

The main reason is simple: for most would-be OS-Devs, the boot loader is a blind alley, one which they can easily get stuck in. In the experience of this group - at least in the past - the majority of developers who start by working on a boot loader never get past it. The warnings in the Wiki about this were written with this experience in mind, and my post reflects this as well.

The thing is, the boot loader isn't part of the OS itself, and the boot process - even on systems where the process isn't in some legacy mode which isn't really used any more by most systems (i.e., almost everything except the PC) - is a separate thing almost entirely unrelated to the OS it launches and having nearly zero influence on it after control is passed. It isn't part of OS-Dev - it's a hurdle you need to get over in order to start the actual OS, and the more time you spend on that, the longer it will be before you are developing the OS proper.

IOW, writing one's own boot loader is, for most us, a distraction we don't need.

I realize that coming from me, this is a bit hypocritical in a number of ways - after all, I have been one of those who has been stuck in the way I mentioned for over 15 years (even if the reasons I am stuck have nothing to do with OS-dev at all), and I do intend to write a loader myself after I have gotten to the point of having the design of my kernel in hand (actually, I will probably write at least two separate kernels... assuming I ever write one at all... with the first being a more conventional design built solely as a way to re-build my confidence and skills, and booted using GRUB). However, for the majority of newcomers, starting at the boot loader is a mistake. I have no problem with someone writing their own after they have a good grasp of actual OS-dev (as you clearly do), but IMAO, for the majority of people who come here a custom boot loader should be one last steps they take, not the first, and only if they see an actual advantage to creating one.

Writing your own boot loader is like writing your own compiler and linker - it only makes sense if you are doing something which simply won't work with the existing tools. In my own case, I plan (for my 'real' target, which would be the second if I do as I said earlier) to use a very unconventional language and toolchain to write an equally unconventional kernel and document system, so I really have no choice (about the toolchain, that is; whether I will be able to use an existing boot loader remains to be seen, though I mean to at least try to in the early development stages). However, if you intend - as do probably 80% of the people coming here - to write your OS in C (where you already have toolsets ranging from GCC/Binutils, Clang/LLVM, Visual Studio, etc. to choose from), or some other existing mainstream language for which there is a suitable compiler and toolchain, you probably shouldn't bother. I think that the same logic applies to the boot loader.

Though I certainly agree that an OS written in Forth would be better served by a custom boot loader. A loader aimed at a C/C++ OS would be a poor fit, and anyone experienced enough to write a Forth interpreter would not find writing a boot loader a major obstacle.

[GMorgan]

For an idea of what a good custom loader might be. L4 Pistachio has a kickstarter module that loads the kernel, sigma0 and root task. It needs to do this because the kernel doesn't know what elf is so something has to basically initialise the system before going away. This issue is unique to microkernels though. Especially microkernels obsessed with small working sets and no policy in kernel.

Even then, kickstarter launches through multiboot and loads it's modules via grub.

[eekee]

For a moment, I thought my problem is that I'm so old-school, I can't imagine OS development by people unqualified to write bootloaders, but then I read a bit more and started thinking again.

I have a separate loader application to get from multiboot or UEFI entry point to the environment my kernel likes.

L4 Pistachio has a kickstarter module that loads the kernel, sigma0 and root task. [...] kickstarter launches through multiboot and loads it's modules via grub.

I appreciate I may have been wrong about ELF, but this all makes multiboot look like just another boot architecture. I guess I do like it when the bootloader can set options which affect the boot environment, but I find it less stressful to edit those options from another OS, which can be arranged. Loading an initrd isn't an improvement over appending the initrd to the kernel image, it's another bit of config to get forgotten. I'm amused to see 9front use Grub's initrd feature to load plan9.ini, but considering plan9.ini is normally on a FAT partition, what's the point?

I suppose there are things about BIOS boot which annoyingly take time and effort without producing results for a while, but if you don't have the patience and determination to get through that, how will you have the patience and determination for other hard OS dev tasks? I've found have more patience for the BIOS than I do for designing my OS! I suppose that's not true of everybody.

I don't really buy the "zero influence" thing. If nothing else, the bootloader selects the kernel! I often find I have to be aware of and work with the boot process when dealing with OSs I didn't write, never mind one where I'm actually developing the kernel. The only complete exception so far is Windows, but that's because it's the only OS I've ever treated as just an appliance.

I keep coming back to wanting to compare writing a bootloader with writing a driver. Both are low-level tasks. Both may be painfully hard, hence my paragraph on patience and determination. Which is easier varies depending on the developer's experience and understanding.

[nullplan]

For a moment, I thought my problem is that I'm so old-school, I can't imagine OS development by people unqualified to write bootloaders, but then I read a bit more and started thinking again.

I probably could if I wanted to, but it's a solved problem so why should I? It's also not the problem I actually want to solve.

I keep coming back to wanting to compare writing a bootloader with writing a driver. Both are low-level tasks. Both may be painfully hard, hence my paragraph on patience and determination. Which is easier varies depending on the developer's experience and understanding.

Writing a BIOS bootloader is low-level, yes, but it is for an entirely different environment than writing a driver for the kernel. 16-bit real mode is weird, not really knowing what you're booting from is even weirder. All you have is DL, which contains a mostly opaque token that only makes sense to the BIOS. And then when you have your spiffy bootloader, all you have is a piece of code to put on the disk and forget about forever.

I guess what I'm saying is, writing a bootloader is like taking biking lessons to get your car driver's licence. It's a completely different skillset.

[Korona]

OP basically says (among other things): GRUB leaves some parts of the system in an unspecified state. Hence, it's better to use your own loader, which will have to deal with even more unspecified state.

I don't follow that argument.

If you buy a car, it may break every once in a while. Hence, better walk everywhere on foot!

[StudlyCaps]

I think a lot of new people assume "I'm making an OS, I'm supposed to roll my own bootloader." Most 'OS' tutorials also seem to start with the boot loader (some are just bootloaders). The thing is GRUB is probably a better bootloader than most people will end up making. It's been tested on 1000's of hardware configs and has years of fixes and improvements. It's far from perfect, and there is no reason not to make a bootloader if that is something you want to do, but if it simply doesn't interest you then there is no real advantage to doing it.

[iansjack]

To my mind it's the same as writing your own assembler and C compiler. Sure you can do it, and it's an interesting excercise, but it has no relevance to OS development. Same goes for writing your own bootloader, especially if it relies on classic BIOS rather than UEFI. Nothing you learn by doing so will apply to the OS itself.

Peole who want to "do it all themselves" really should be writing the microcode for their chosen processor too.

On the other hand, it's a good prevarication technique to avoid getting to work on the OS itself.

[bzt]

Hi,

I know I'm a minority with this opinion here, but I agree with eekee. If an OSDev wannabie can't wrap their head around a boot loader, then there's little chance they will succeed with other parts of OSDev. Even though it does not have the usual device interface, booting environment is just another device to dealt with, nothing more.

I personally don't like GRUB. It's a bloated nightmare IMHO, which is bigger than my whole kernel, yet it can't boot from any file system. I think its developers made poor design choices (especially with version 2, version 1 was better in many aspects). I prefer a simple boot protocol, therefore I've implemented that on different platforms. It is only a fraction in size of GRUB (the biggest is the UEFI version with 90k), much simpler to use and it is much more flexible. Despite of the small size, it allows me to load an initrd on many different machines, even on ones that GRUB does not support at all. But I'm an experienced programmer with several decades behind, and I understand that many can't write such a good multi-arch boot loader, that's why I've licensed it under MIT.

On the other hand, if multi-platform is not a goal, then there's simply no reason to suck with GRUB or other complicated loaders, just load your kernel and off you go. Take a look for example at Xv6. It's boot record is coded in two files:
- bootasm.S sets up protected mode and calls bootmain
- bootmain.c simply loads the segments from an elf file which is stored on disk starting from sector 1.
That's all, no 2nd stage loader, and it works perfectly. K.I.S.S. you know. And this boot record is universal, it can load ANY 32 bit elf kernel, not just Xv6.

Cheers,
bzt

[klange]

As a community, we slowly adopted the stance of discouraging custom bootloaders as a starting point to writing operating systems after literal decades of it being a major stumbling block for beginners. So many people take the wrong steps in trying to get into this community and give up long before they've had a chance to do anything close to an operating system, because they spent all that time trying to initialize an x86 PC through its esoteric hoops of backwards compatibility. Is this historical artifact of the PC a valuable and interesting topic to learn? Of course it is, but if you tell a 10 year old kid they need to chop down a tree and lathe their own bat before they can play baseball, they'll quit before they've ever had a chance to run the bases.

[Octacone]

Ditching GRUB (and going custom) was one of the best things I've ever done.
It made me learn so so much, it wasn't an easy path, but it was well worth it!
Also it gave me a lot more control and made my OS a lot smaller.
Anyone can do it! Trust me!
I used to suck at Assembly, but eventually step by step I was getting better and my bootloader was getting more usable.
Just make sure not to follow any bootloader tutorials because they truly suck and just confuse people.
If you can't figure out a bootloader, maybe osdeving is not for you, sad but true, I agree with bzt

I know I'm a minority with this opinion here, but I agree with eekee. If an OSDev wannabie can't wrap their head around a boot loader, then there's little chance they will succeed with other parts of OSDev. Even though it does not have the usual device interface, booting environment is just another device to dealt with, nothing more.
I personally don't like GRUB. It's a bloated nightmare IMHO, which is bigger than my whole kernel, yet it can't boot from any file system.

Enough said.

[eekee]

I'm fascinated to see lots of good points both for and against Grub & co. It's especially interesting to see experience pointing both for and against. Shouldn't be possible, but it is! What starting to think is this: "If you're new to OS dev, you're better off using multiboot, but in the long term, rolling your own bootloader is better."

To be honest, I can see some reason to OS dev which doesn't involve drivers, relying instead on UEFI, OpenFirmware, or even the BIOS. Interesting architectures can be investigated without writing low-level drivers, allowing for some performance loss. If writing drivers isn't a hard requirement for OS dev, I have to admit writing a bootloader shouldn't be.

[iansjack]

I think there is an excellent demonstration in another current thread of the difficulties entailed in writing your own bootloader rather than using a tried and tested one. Sure, write a bootloader if that is your end goal. But if you want to get on with writing an OS don't get sidelined by irrelevant detail.