OSDev.org

Well, for quite a while I was looking for a simple bootloader that would work on more than just floppies. Well, I have found it! The only requirements are using FFS for filesystem(doesn't matter in early stages of your OS anyway) and using ELF for your kernel.

OpenBSD's bootloader works great for me. I have yet to find all its features and how to access them however. So, more info to come..

But here is a simple way to go straight out and boot a ELF kernel from external media..
First, install the bootloader. I recommend going to http://openbsd.org and getting cd44.iso
It includes a ramdisk kernel you can use to easily install the bootloader. All you have to do is start the cd, witht he media in. follow the simple install instructions. Note, thumbdrives and flash cards and external hdds are sd*, harddrives are wd* (hint: don't mess with those!) and if there is no wd* devices listed then that means you have scsi harddrive... be careful cause those are also listed as sd* also. Btw, configuring the network is not required. Also, just use one big / for the partitioning.

at the package installation bit, I am not sure if it would work but I think you should be able to select no packages and there would be no problems, otherwise just choose bsd, etc44.tgz and base44.tgz

then it'll format it and install the bootloader. and it'll end at the "#" prompt. Just halt and voila, you have a ffs drive with the openbsd bootloader.

Now, all you have to do is copy your kernel file to the ffs drive and boot it.
For example and then magically your kernel works... pretty straight forward if you are already using openbsd... if your not(especially if your OS doesn't support ffs volumes) then maybe you are better off with grub or one of those....

earlz wrote:maybe you are better off with grub or one of those....

Well, maybe if the OpenBSD boot loader does a better job than Grub, I think everyone is "better off" with it than with Grub (except perhaps "hello world" kernel writers). Cause Grub uses multiboot, and multiboot sucks hard.

JJ

JJeronimo wrote:

earlz wrote:maybe you are better off with grub or one of those....

Well, maybe if the OpenBSD boot loader does a better job than Grub, I think everyone is "better off" with it than with Grub (except perhaps "hello world" kernel writers). Cause Grub uses multiboot, and multiboot sucks hard.

Sorry. I was too radical.
Multiboot's idea is overall good, and it has good points. However, it's memory map is simply dreadful compared to what could have been done.

JJ

Just use the boot loader that better suits your needs. (I personally prefer my own more then Grub for my needs.)

Multiboot is pretty bad, just because its awfully outdated. The only reason I support it is compatibility with other systems, so someone can easily boot my OS as well as Linux/*BSD/etc on the same partition. One advantage it has is that it forced me to move my startup code into the bootloader, which means the memory that holds startup code can be reclaimed easily.

JohnnyTheDon wrote:Multiboot is pretty bad, just because its awfully outdated.

You are right. It's true that Multiboot was originally designed in 1995, but I didn't remember.

JJ

Age doesnt make code outdated.

it does when hardware changes extremely rapidly.. (a computer 10 years old already contains quite a few obsolete things..)

abachler wrote:Age doesnt make code outdated.

We were talking about a standard, not about code.

Multiboot may have been up to date ten years ago, but now it's outdated because time has changed and we need standards that allow us to develop flexible software easily. For example, ten years ago the PC memory map was much more regular than it is now, and more assumptions could be safely made than now.

JJ

abachler wrote:Age doesnt make code outdated.

Thats not true at all. Would you consider the origional doom up to date? Can you say that a game like Crysis doesn't have better graphics, physics, etc?

And when it comes to operating systems, thats even less true. If you have a Core i7 and you run 16-bit DOS on it, it will run in real mode on one core of a quad-core, hyperthreaded, 64-bit processor. That I would consider out of date. There are algorithms and solutions to problems (ie A* or sempahores) that will continue to work into the future, but anything tied to hardware (ie an OS or bootloader) can be outdated very quickly.

Multiboot doesn't account for 64-bit processors, multiple processors, or anything that is quite common on today's computers. That does make it out of date.

neon wrote:I personally prefer my own more then Grub for my needs.

Same. My second-stage bootloader, however not really flexible, is perfect for what I need. I plan on using a configuration file for version 1.0.0 instead of hardcoded stuff so it can be used for more than just my operating system.

Multiboot doesn't account for 64-bit processors

Still, multiboot is the only real standard in the field, which makes it a lot better than having no standard. And unless your goal is to make a 64 bit OS then it will still do what it was meant to do: make it easy to boot a kernel in a high level language.

On another note, multiboot differs per architecture. Its very poor to complain about multiboot when you're trying to use the wrong standard for the wrong architecture. Its like using a wrench to cut wood - it works eventually but it was not meant for that purpose.

JohnnyTheDon wrote:

abachler wrote:Age doesnt make code outdated.

Thats not true at all.

It is most certainly true: Quicksort and heapsort are dated to the '60s. Bakery algorithm is a bit more recent but still equally valid. And everybody is still using that code over and over, for good reason. And I seriously doubt you want to call either outdated, even though they are very old indeed.

Combuster wrote:

JohnnyTheDon wrote:

abachler wrote:Age doesnt make code outdated.

Thats not true at all.

It is most certainly true: Quicksort and heapsort are dated to the '60s. Bakery algorithm is a bit more recent but still equally valid. And everybody is still using that code over and over, for good reason. And I seriously doubt you want to call either outdated, even though they are very old indeed.

Algorithms and code are not the same. Everyone is still using that algorithm over and over, for good reason. I wouldn't call either of those algorithms outdated, but i would certainly considered a 16-bit or a COBOL implementation of quick sort to be outdated. The implementation ( code ) can certainly becomes outdated.

And even to say algorithms are a golden bullet that do not age is incorrect. For example, the md2 hash function is largely outdated, due to the fact that it's security function is non-existent ( even the author agrees ). Algorithms can become obsolete by newer and "better" algorithms.

JohnnyTheDon wrote:

abachler wrote:Age doesnt make code outdated.

Thats not true at all. Would you consider the origional doom up to date? Can you say that a game like Crysis doesn't have better graphics, physics, etc?

And when it comes to operating systems, thats even less true. If you have a Core i7 and you run 16-bit DOS on it, it will run in real mode on one core of a quad-core, hyperthreaded, 64-bit processor. That I would consider out of date. There are algorithms and solutions to problems (ie A* or sempahores) that will continue to work into the future, but anything tied to hardware (ie an OS or bootloader) can be outdated very quickly.

Multiboot doesn't account for 64-bit processors, multiple processors, or anything that is quite common on today's computers. That does make it out of date.

Would you consider Unix/Linux outdated? It is older than Doom. It appears that you actualyl agree with me, that it isn't AGE that makes code outdated, but lack of useful features or perhaps lack of continued support.

NReed wrote:And even to say algorithms are a golden bullet that do not age is incorrect. For example, the md2 hash function is largely outdated, due to the fact that it's security function is non-existent ( even the author agrees ). Algorithms can become obsolete by newer and "better" algorithms.

Which was exactly my point - It is not age that makes things outdated, it's the presence or absence of better variants (which is why md2 is outdated and quicksort is not) and the validity of the underlying assumptions (which is why dos is outdated and *nix is not). And in both examples, age would disagree.

Algorithms and code are not the same.

Then lets talk about the C implementation of quicksort