To all the members who have an actual running OS:
Which bootloading method do you use and why?
For example, do you use a custom bootloader because your OS loads onto special hardware (eg: router) and doesn't need all of grub's features?
Bootloading: What method and Why?
Custom. Primarily because grub does not do what I need, security, and portability purposes.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
-
piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
I use GRUB, because it's simple to setup, available, has multiboot and can deal with itself.
I don't want to deal with writing my own, because I prefer kernel development, plus my OS (currently) requires multiboot to run.
I know that there are other BL's with multiboot, but I'm familiar with GRUB, so there you are.
-JL
I don't want to deal with writing my own, because I prefer kernel development, plus my OS (currently) requires multiboot to run.
I know that there are other BL's with multiboot, but I'm familiar with GRUB, so there you are.
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
. Small and compact, sets up pmode for my OS and jumps to it.
Originally, GRUB but I'm working on a custom version now.
The idea with my current boot loader is to get all the run-once stuff out of the kernel and in to the boot loader. This includes video mode switching, setting up a physical memory stack/bitmap (customisable via menu option), setting up paging to allow the kernel to start directly in the upper half (works for both 32 and 64 bit kernels automatically) and the option of having an 'alternative kernel' - if the CPU does not support 64 bit mode, the 32 bit kernel will be loaded instead.
The original version of CBoot was a second stage boot loader, loaded by GRUB (with the kernel as a module). I am currently focussing all my efforts on creating a stand-alone product (starting with support for a FAT12 disk and extending support from there).
Cheers,
Adam
Oh - I plan to put device detection code in there too and present it to the kernel in a nice uniform format.
The idea with my current boot loader is to get all the run-once stuff out of the kernel and in to the boot loader. This includes video mode switching, setting up a physical memory stack/bitmap (customisable via menu option), setting up paging to allow the kernel to start directly in the upper half (works for both 32 and 64 bit kernels automatically) and the option of having an 'alternative kernel' - if the CPU does not support 64 bit mode, the 32 bit kernel will be loaded instead.
The original version of CBoot was a second stage boot loader, loaded by GRUB (with the kernel as a module). I am currently focussing all my efforts on creating a stand-alone product (starting with support for a FAT12 disk and extending support from there).
Cheers,
Adam
Oh - I plan to put device detection code in there too and present it to the kernel in a nice uniform format.
I use a custom bootloader that I made. It basically loads a configuration file which tells it the number of bootable operating systems on the disk, the name of the file to load and the address to move it to. The reason I decided to do this was so that if I had a bug and wasn't sure how to fix it I could make multiple builds of the kernel and use my bootloader to load them. The reason why I don't use GRUB is that I wanted to learn and experience the challenge of writing a bootloader.
Custum.
For userfriendlyness. My OS uses an own partitiontable, with partitions. One partition is a bootstrap, universal for each versions. A bootstrappartition is not always needed. Bootstrap can be loaded from floppy but also from network boot (PXE). It doesn't matter where the bootstrap is loaded from to boot the system.
Other partitions can be filesystems with just data. Copy some OS-files is enough to make a partition bootable. It's like the Apple partition system and the BSD partition system, best of both.
That system resides in a normal MBR-partition (like BSD does), but the partition can also span the whole harddisk. The bootsector becomes the MBR, for the bootloader nothing changes. But in that case there is no compatibility for other OS-es.
The bootloader is graphical, like Apple with graphical symbols showing errors and simple keys to boot from a non-default disk, like pressing 'c' for the CD-ROM. It has a console, but that's normal users won't see that until they press some key combinations. It's under development right now.
I don't like Grub. I think an os is not complete without bootloader.
Maybe it's too much for a bootloader for an OS where the kernel is in a very early stage of development. You can discuss the priority. What's important? It isn't hard to understand some people like to begin directly with kernel development. That's the most important part. Without kernel, no OS. Without bootloader, you can also make a great OS (loaded with stuff like Grub). But I have a vision about bootloaders, inspired by older Apples and a little bit the Alpha-platform, and I like to work that out.
For userfriendlyness. My OS uses an own partitiontable, with partitions. One partition is a bootstrap, universal for each versions. A bootstrappartition is not always needed. Bootstrap can be loaded from floppy but also from network boot (PXE). It doesn't matter where the bootstrap is loaded from to boot the system.
Other partitions can be filesystems with just data. Copy some OS-files is enough to make a partition bootable. It's like the Apple partition system and the BSD partition system, best of both.
That system resides in a normal MBR-partition (like BSD does), but the partition can also span the whole harddisk. The bootsector becomes the MBR, for the bootloader nothing changes. But in that case there is no compatibility for other OS-es.
The bootloader is graphical, like Apple with graphical symbols showing errors and simple keys to boot from a non-default disk, like pressing 'c' for the CD-ROM. It has a console, but that's normal users won't see that until they press some key combinations. It's under development right now.
I don't like Grub. I think an os is not complete without bootloader.
Maybe it's too much for a bootloader for an OS where the kernel is in a very early stage of development. You can discuss the priority. What's important? It isn't hard to understand some people like to begin directly with kernel development. That's the most important part. Without kernel, no OS. Without bootloader, you can also make a great OS (loaded with stuff like Grub). But I have a vision about bootloaders, inspired by older Apples and a little bit the Alpha-platform, and I like to work that out.
custom
1) I have a custom filesystem, and I don't want to bother teaching somebody else's bootloader to understand it.
2) Grub is too big. My filesystem loads a 256K table during boot, and grub is in the way. My bootloader is 3K, and does just about everything that grub does -- but a LOT faster.
3) Grub's boot process is not automated the way I want, AFAIK. If there is only one bootable partition, it should boot instantly. If there are multiple choices, it should ask.
4) Grub does not give the user options for passing kernel specific info to the booted kernel, or to select an alternate kernel prior to load. My bootloader allows an alternate INIT program to run, a "test" kernel to be selected, and a "singlestep mode" flag to be set.
5) Grub has errors, and part of the whole reason I'm doing this in the first place is that I don't want to be dealing with *other people's* bugs!
6) Grub does not pass me any BIOS PCI information.
7) Grub does not pass me a sufficient amount of VBE information, AFAIK.
8) Grub does not guarantee the location, in memory, of modules. The last thing I want to deal with from my bootloader is uncertainties.
9) My kernel demands LBA mode support, E820 support. Grub does not test for this -- or error out for me.
10) I want to be certain where the temporary GDT is, in memory.
11) I want my complete MBR to remain in memory, at a known location. I use it for locating the boot disk.
12) My bootloader contains my volume name for the partition, plus extra info that my kernel needs. So I want it to be small enough to remain in memory at a known location.
13) My bootloader not only loads my kernel, it also loads a flat copy of my root directory for me -- at a known location in memory.
14) There is some BIOS floppy info that grub does not pass on.
15) The Multiboot spec is not sufficiently pretty for my tastes.
1) I have a custom filesystem, and I don't want to bother teaching somebody else's bootloader to understand it.
2) Grub is too big. My filesystem loads a 256K table during boot, and grub is in the way. My bootloader is 3K, and does just about everything that grub does -- but a LOT faster.
3) Grub's boot process is not automated the way I want, AFAIK. If there is only one bootable partition, it should boot instantly. If there are multiple choices, it should ask.
4) Grub does not give the user options for passing kernel specific info to the booted kernel, or to select an alternate kernel prior to load. My bootloader allows an alternate INIT program to run, a "test" kernel to be selected, and a "singlestep mode" flag to be set.
5) Grub has errors, and part of the whole reason I'm doing this in the first place is that I don't want to be dealing with *other people's* bugs!
6) Grub does not pass me any BIOS PCI information.
7) Grub does not pass me a sufficient amount of VBE information, AFAIK.
8) Grub does not guarantee the location, in memory, of modules. The last thing I want to deal with from my bootloader is uncertainties.
9) My kernel demands LBA mode support, E820 support. Grub does not test for this -- or error out for me.
10) I want to be certain where the temporary GDT is, in memory.
11) I want my complete MBR to remain in memory, at a known location. I use it for locating the boot disk.
12) My bootloader contains my volume name for the partition, plus extra info that my kernel needs. So I want it to be small enough to remain in memory at a known location.
13) My bootloader not only loads my kernel, it also loads a flat copy of my root directory for me -- at a known location in memory.
14) There is some BIOS floppy info that grub does not pass on.
15) The Multiboot spec is not sufficiently pretty for my tastes.
GRUB is a nice bootloader, but it is also GPL'd, thus rendering it useless for me.
I designed me own to get around having to use other people's code, and I also redesigned it for size and speed.
I designed me own to get around having to use other people's code, and I also redesigned it for size and speed.
Website: https://joscor.com
-
codemastersnake
- Member
- Posts: 148
- Joined: Sun Nov 07, 2004 12:00 am
- Contact: