
Operating System Development - Zolomon
http://wiki.osdev.org/Main_Page
======
exDM69
Doing your own toy operating system is a great learning experience and I can
recommend it to anyone who has the right hacker attitude and a little bit of
prerequisite knowledge.

OSdev is a pretty good starting point for basic resources. You'll need to
build your own GNU toolchain (gcc + binutils + gdb) for cross compiling (don't
try to use the one that ships with your OS, it will subtly fail when you don't
expect it to), get an emulator (e.g. qemu or bochs) and a bootloader to get
started. Do _not_ write your own bootloader code or try to stick to pure asm,
you'll get nowhere fast. Use the multiboot protocol so you can easily get
booted on emulators and real iron using GRUB2. Note: I assumed you want to
work on x86.

In addition to OSdev, the Intel manuals are an excellent resource. They are a
pretty nice thing to read even if you don't intend to write an OS. Although
reading through them will probably get your OS hacking itch going and you
can't stop yourself. That happened to me. The Intel manuals are here:
[http://www.intel.com/content/www/us/en/processors/architectu...](http://www.intel.com/content/www/us/en/processors/architectures-
software-developer-manuals.html/) . Volumes 1 and 3a are the most important.

And here are the humble beginnings of my hobby operating system:
<https://github.com/rikusalminen/danjeros>

~~~
planckscnst
When I read "Do not write your own bootloader...", I immediately objected
until I saw "assumed...x86". In that case, I agree. If you are going to build
an OS for ARM or MIPS, you really learn a lot if you make your own bootloader.

~~~
reginaldo
Only when you want to run it on real hardware. Most qemu targets can boot
straight from a binary blob or an ELF image (the emulator initializes the
emulated hardware and then sets the PC to the address where the blob is
loaded). Those that can't are easily modifiable to do so.

Also, U-Boot can boot a lot of things this days.

So if I were to build an OS for ARM or MIPS I would:

1) Build it on an emulator that can boot from ELF or a binary blob.

2) When it's time to run on real hardware, try to use U-Boot.

3) If that fails, write my own boot loader.

The moral of the story is: bootloaders are not my kind of fun, so I'll avoid
writing them at all costs.

~~~
gaius
Right, but you've presumably already done it once and thus extracted all
pedagogical value from it.

~~~
reginaldo
Yes, you're right. For my OS class when I was in school, instead of doing the
proposed homework, I convinced the professor to let me do a x86 OS. We were a
group of 3. I started doing everything in C with as little as assembly as
possible, but the other two decidet to do an all-assembly little monster.

At the end of the course, we had only the boot loader and a little command
interpreter, aside from FAT-12 support.

Then, much later, I messed with OS by playing with the code from the Minix
Book [1].

Last year I wrote a little emulator for a virtually unknown architecture that
can run uClinux on a modern browser (i.e., Chrome)[2].

[1] Operating System Design and Implemenation:
[http://www.amazon.com/Operating-Systems-Design-
Implementatio...](http://www.amazon.com/Operating-Systems-Design-
Implementation-3rd/dp/0131429388/ref=sr_1_1?s=books&ie=UTF8&qid=1342719082&sr=1-1&keywords=minix)

[2] <https://github.com/ubercomp/jslm32/>

------
mahmud
this and geezer's site are the OGs of OS dev. Both offshoots of alt.os.dev,
iirc, and have been around for more than a decade.

if I were messing with OS dev today I would probably study the _algorithms_ in
a friendly HLL, there are some texts that use Java. these sites are more
helpful to actual implementors, specially driver developers.

x86 architecture is terrible for pedagogy in many ways, and it's probably
harder today than it was 10 years ago, with real-mode now finally gone, except
for the first few nanos after machine boots.

~~~
exDM69
> x86 architecture is terrible for pedagogy in many ways, and it's probably
> harder today than it was 10 years ago, with real-mode now finally gone,
> except for the first few nanos after machine boots.

x86_64 is a pretty clean actually. The instruction set is pretty horrible but
rest of the moving parts are fairly consistent. Page tables, interrupt
controllers and things like that work pretty nicely through memory mapped i/o.

------
topbanana
I bought a Raspberry Pi with a view to developing a hobby OS. Turns out that
the graphics chip spec is closed and will only work with a Linux binary blob
provided by the manufacturer.

~~~
mtgx
You might want to try that Exynos 4/Mali 400 $130 development board that was
in the news recently (O-DroidX was the name I think). I know some developers
were working on the open source driver for ARM's Mali GPU's, called "Lima".
You might get more documentation for Mali from ARM as well.

Edit:

[http://www.hardkernel.com/renewal_2011/products/prdt_info.ph...](http://www.hardkernel.com/renewal_2011/products/prdt_info.php)

<http://limadriver.org/>

~~~
topbanana
Thanks. Mali had caught my eye before, as it's used on this board:
[http://gooseberry.atspace.co.uk/?page_id=31#ecwid:category=0...](http://gooseberry.atspace.co.uk/?page_id=31#ecwid:category=0&mode=product&product=12061571)

~~~
mtgx
Right. This might interest you as well, then:

[http://www.cnx-software.com/2012/07/17/hackberry-
allwinner-a...](http://www.cnx-software.com/2012/07/17/hackberry-
allwinner-a10-development-board-with-1gb-ram/)

~~~
topbanana
It does - I'll keep an eye on this. Many thanks

------
gaius
Interesting, but very Intel-centric, the name of the site should probably
reflect that. Anyone doing this stuff for fun would probably have a lot more
fun on a 68k or MIPS or ARM.

~~~
exDM69
> Interesting, but very Intel-centric, the name of the site should probably
> reflect that. Anyone doing this stuff for fun would probably have a lot more
> fun on a 68k or MIPS or ARM.

OSdev is very x86 centric. However, x86_64 is not as bad as you seem to imply.
The instruction set is horrible but it's not like you're going to mess with
assembly a lot anyway. Memory management units and interrupt controllers, etc
are the important bits and they're just fine in x86.

I get a great satisfaction of being able to boot into my toy operating system
on the hardware I normally use. And that is an x86. Running inside an emulator
or a dev board with dangling wires is not half as fun.

~~~
throwaway_95014
Dealing with both timekeeping and interrupts on x86 systems is _awful_. Anyone
that thinks that the x86 interrupt architecture is "just fine" has rocks in
their head.

~~~
exDM69
Yeah, it has it's hairy parts but it still doesn't deserve all the bashing it
gets. I found the LAPIC and IOAPIC controllers okay to deal with, I guess
there are better ones but multi-core interrupt handling is a complex matter so
you can't expect the hardware to be very simple either. Some of the legacy
parts are quite hairy, but you can work your way around them quite quickly.

------
pagejim
The list of reference books [1] on the site is quite formidable. Each book in
that list deserves a lot of time to do justice to the content they have in
them and the hard work/experience authors have put in.

Anyway, even if you start developing your own OS, you may not end up writing
the whole of it all by yourself. Most people get a lot of help from outside
and that is not at all bad, infact it has already proved itself to be the way
to go by the open source Operating systems that are around today.

[1] <http://wiki.osdev.org/Books>

------
richardk
Been dabbling with OS stuff for a while now, looking at xv6 sources and using
Tanenbaum's Minix book.

Have got to say I'm very excited about this site, it looks incredibly useful.

------
pooriaazimi
My friend created a toy OS several years ago (he wrote it in C, then
"manually" translated it to binary). He said to me
<http://www.osdever.net/tutorials/index> is a good site. I don't know about
it, but if you're interested, chick this site out too.

------
krollew
This site is great and contains so much information. Unfortunately it's hardly
meaningful part of knowledge you need to write any modern OS. Unfortunately,
because it's realy good fun to do stuff like that. It's quite hard to enjoy
for a long time creating stuff that even you would not use.

~~~
tikhonj
I don't know, I've had a lot of fun making stuff I wouldn't use. Designing and
implementing things (programming languages rather than OSes in my case) is
more fun than actually using them :).

Not planning to use your project also gives you a certain freedom. You can do
all sorts of crazy and impractical things just for fun. My language lets you
change the precedence of operators at runtime. It's a stupid feature that
would only cause misery in the real world, but I'm not writing my project for
the real world :).

That said, it is also fun to write things people actually use. In fact, just
having users or using your own program yourself makes up for having to deal
with boring issues, annoying corner cases and reality in general.

------
vitomd
I really recommend the irc channel #osdev (freenode). When I was making my os,
I get stuck many times and debugging an OS is pure pain (I used bochs) but
some people on #osdev help me to find the bugs and learn in the process.

