OSDev.org

Hello, I'm the newest of the newbies around here (or, at least, I registered about five minutes ago). I've been trying to get into OS development for a while, after doing Java, PHP, C/C++, BASIC, and a bit of ASM here and there. I've been reading up on some tutorials, but each one either requires GRUB or another bootloader, and when it doesn't require it, the tutorial just flat out doesn't have enough for me to dissect and get started with. Since they can't share the same code (sure, I could adapt them together, but that would be painstakingly stressful), does anyone know how to take the Bare Bones tutorial on this site's wiki, and make it self booting? I know that it's probably just a few lines to add to the entry point, perhaps a bit of ASM, but I have no clue as to what/where to add it.

So, err, Bare Bones tutorial. How do I make it boot itself WITHOUT the help of GRUB?

It's actually much more that just a few lines of ASM.

It needs to do basic initialization of things, depending on the OS.

There is a link to the wiki page on this.

-JL

Short answer: you cant

Long answer:
The four Bare Bones kernels on the wiki are built around the multiboot specification. That means they can be booted by any bootloader that complies with that standard. It also means that they expect you to provide such a bootloader and nothing else.

Multiboot is not the smallest standard in the collection. If you want to write a bootloader yourself that can provide everything barebones need, you'll have to set apart quite some time for that. So the few lines you want can quickly go towards half a thousand, if not more.

Grub is meant to simplify OS development by removing the bootloader stage altogether, and does a good job at that. That brings us to the conclusion that you either do use GRUB or anything similar, or you skip barebones and follow the babystep tutorial to construct your own bootloader.


As a side note, expect that tutorials that don't mention the "bootloader", usually assume GRUB.

Surely you expected this: I'm totally lost with the link you gave, piranha. Bear with me for a moment, because no matter what tutorial I follow, I'd prefer that it'd explain the following:

1. How to boot into the kernel WITHOUT GRUB
2. How to enter protected mode
3. How to link together the kernel's C source and ASM entry

Dr_Link wrote:1. How to boot into the kernel WITHOUT GRUB

Use your own bootloader. [wiki]Category:Babystep[/wiki], Bootloader and Rolling_Your_Own_Bootloader give both the theoretical and the practical side.

2. How to enter protected mode

Hey look, there's code for it in piranha's link

3. How to link together the kernel's C source and ASM entry

You dont
Make two binaries and have the first (bootloader) load the second (kernel)

You dont Smile
Make two binaries and have the first (bootloader) load the second (kernel)

To expand on that: You are going to need some way of loading the kernel off of a floppy. That means that you either set apart secors for the kernel or write a FS driver in the bootloader, which would mean that you would probably have to make a 2 stage loader, as the FS code would take up most/all/more than the alloted 510 bytes for loading the kernel.

I suggest making a basic working kernel first, than if you want making your bootloader.

Having the multiboot stuff makes things much easier.

3. How to link together the kernel's C source and ASM entry

If you mean a simple entry code for the kernel:
Thats easy, just compile both files and link them together with ld (or other linker). Thats on the wiki too: BareBones.

If you ment the bootloader and the kernel:
You don't. As Combuster said, the bootloader loads the kernel from a storage medium.

-JL

There's some pretty good tutorials on this at BrokenThorn, written by neon, a member here.

piranha wrote:

You dont Smile
Make two binaries and have the first (bootloader) load the second (kernel)

I suggest making a basic working kernel first, than if you want making your bootloader.

Don't agree. I can imagine you prefer making a basic working kernel first. Some people don't want to mess with loading stuff, but directly begin with a kernel.

But making your own bootloader has some advantages:
- You learn from it. When you take care of loading your kernel with your own program, you learn exactly how your kernel is loaded and placed in memory. This knowledge is a benefit when you are developing your kernel
- You can take your own decisions about the bootloader. My bootloader collects many information about the system, like information for accessing VESA from protectedmode. I store information about the bootdisk the way I want to. I don't need a string addressing the root-device, it's too hard for normal users.
- Userfriendlyness. Things like multiboot aren't userfriendly. Lilo, Grub and all other ways to load Linux are not good for people without computer knowledge. I think for most hobby-OS-es userfriendlyness is not the most important. I believe real userfriendlyness has also impact on the design of your bootloader and your kernel.
For example the way Mac OS boots..an example of userfriendlyness.
On the PC BeOS. No multiboot or other highly configurable bootloaders that can load ELF-binaries, but a userfriendly menusystem. A bootloader must be userfriendly and flexible. Making a disk bootable must be no more than copying a couple of files. No further configuration.

Hi,

While I agree with your sentiments (I would always suggest that a new user starts with a boot loader for the learning experience), I'm not so sure about what you say with regards to user-friendliness.

I think the issue with multiboot compliant loaders being almost 'over-configurable' for the standard use can easily be overcome by building a decent boot disk handler in to the OS. Simply make it so that the user can select that a disk is bootable when that disk is formatted (or later) and by default, don't ask that user about how that user wants the OS booted.

In other words, the OS's disk handling system could simply add the appropriate menu options to the boot loader and install it without displaying a plethora of options. Suddenly, multiboot becomes more user friendly.

Cheers,
Adam

Hi,

• I agree with much of what you've said - creating one's own bootloader is indeed a great learning experience, however I feel that your statements conflict slightly when talking about 'userfriendlyness' and examples of it.

• Userfriendlyness. Things like multiboot aren't userfriendly.

  Who are you talking about here as the 'user'? The lamen who presses the "enter" key when the menu shows up or the kernel proper (as a client program it could be said to be a "user" of the bootloader). If the former, multiboot is a kernel entry specification. It by design has no effect on the user whatsoever - it is completely invisible. If the latter; well, standards can't appear perfect to everyone - everyone has different tastes.

• I believe real userfriendlyness has also impact on the design of your bootloader and your kernel.
  For example the way Mac OS boots..an example of userfriendlyness.

  I agree here Mac OS is extremely user friendly in all it does - it perhaps has the advantage of being created by Apple who are able to employ people extremely skilled in creating user friendly hardware and software. Nevertheless, any hobby project could learn extreme amounts from observing how commercial OSes do things.

• On the PC BeOS. No multiboot or other highly configurable bootloaders that can load ELF-binaries, but a userfriendly menusystem.

  Firstly, I again don't see the relevance of multiboot here when talking about user friendlyness. There is nothing whatsoever in the specification document that relates to I/O of any kind, particularly with the user (with exception of probing VESA modes, which could be classified as I/O).
  
  Secondly, with respect to 'configurability' and the loading of ELF binaries - Did you know that Mac OS, which you previously stated was a good example of user friendliness, [on the PPC] boots via OpenFirmware, which is as configurable as one could wish, and also loads kernels as ELF binaries! [among other formats]

• A bootloader must be userfriendly and flexible.

  Flexibility necessarily implies 'configurability', as far as I can see.

• Making a disk bootable must be no more than copying a couple of files. No further configuration.

  Again I refer you to Mac OS on the PPC - to make a disk bootable a special Apple_Bootstrap type partition is required to be made, formatted with HFS, and populated with a special directory structure. Fdisk does all of this for you - however it is slightly more than 'copying a couple of files'!
  
  As I said previously, I agree with the brunt of your point, but these things in particular I felt the need to point out.

Cheers,

James

I agree that making a bootloader is a great learning experience, just IMHO if I want to develop a kernel, I don't want to spend a lot of time working on a bootloader if I can just use GRUB to test it.

-JL

Lilo, Grub and all other ways to load Linux are not good for people without computer knowledge

I think that if you're developing an OS you should have a good computer knowledge level.

Pyrofan1 wrote:

Lilo, Grub and all other ways to load Linux are not good for people without computer knowledge

I think that if you're developing an OS you should have a good computer knowledge level.

Of course...But I didn't mean with "people without computer knowledge" the developers, but a some of the (future) users.

I decided to do the bare bones tutorial, didn't quite work out so well. The C example on the wiki:
...this code does not compile with:

gcc -o kernel.o -c kernel.c -Wall -Wextra -Werror -nostdlib -nostartfiles -nodefaultlibs

as the tutorial stated. I'm given an error involving the "unused arguments mbd and magic"...

I can't delete these, so exactly how do I get a kernel.o to produce from the compiler?

Hi,

If you don't want to use the parameters at the moment, change the function header to:
When you want to use the multiboot parameters, you will obviously have to put the names back in.

This is just a warning, but you are (correctly) using the -Werror flag, hence terminating the compilation process. The other way to stop this being treated as an error would be to remove this flag (not recommended).

Cheers,
Adam