My first OpenBeOS build

by Daniel Reinhold, 23 Jun 2002


Recently, David Reid reported that the OpenBeOS kernel source tree had been amended to fit its new environment after forking from NewOS. The jam scripts had been written, tweaked, and tested, and the new kernel was now capable of being built. He even included a picture of his computer booting from the freshly created floppy.

While I was happy to report this, I hadn't actually tried to do a build myself. So I thought I'd give it a shot. I'm happy to say that it went very well. The process was quite smooth and didn't take too long. Fortunately, my new computer had no problem booting from the OpenBeOS floppy disk created, so the adventure was a complete success for me. But there is no guarantee that this will be true for everyone -- some machines out there may not be properly detected by the kernel. Of course, over time, we will develop a list of compatible hardware.

Fresh from victory, I decided to write up a set of directions for how to go about building the sources. While I'm at it, I'll make a few comments about where this leaves us, and where we have to go. Hopefully, others will be encouraged to try this as well. Btw, in case it is not obvious from my comments below, these directions are only for those building from BeOS.

Update the source tree

The first thing you will want to do is make sure that you have the latest source code downloaded from the CVS repository. The Dev Central section of the website contains a zip of a (BeOS) cvs binary. If you don't already have this program, download it and copy the binary to '/boot/home/config/bin'.

To update locally, open a new Terminal window and run the following commands:

cvs login
cvs -z3 co -P openbeos
At the login prompt, just press ENTER. This will download the latest versions of files in the CVS repository to your current directory (will be '/boot/home' when you first start up Terminal). If you already had files there, this will only update the latest versions. If this is the first update, it may take awhile to download them all.

Assuming that you ran the cvs commands from the '/boot/home' directory, you should now have a '/boot/home/openbeos' directory containing the latest source tree.

Run jam

The next step is to run jam. This program (analogous to make) is what we use to build the binaries from the source files. As with cvs, you can find the binary for jam (as a zip) in the Dev Central section of the website. As before, copy the binary to '/boot/home/config/bin'.

To run jam, use the following commands in the same Terminal window:

cd openbeos
In the openbeos directory will be a file called Jamfile. The jam program will open this file, and execute the commands contained therein. This top-level jam file contains references to other jam files in subdirectories below. As these jam files are executed in turn, the entire source tree is traversed and the binaries created.

If jam encounters any errors -- i.e. in some jam script, a problem prevents a particular target from being built -- an error message will be printed. However, the program will not abort. It will proceed to the next jam file to be processed, etc. It is quite robust.

Yes, rebuilding the entire tree will take awhile. Relax, have a cup of coffee, read that email you've been meaning to get to, etc., and then check back on the build progress from time to time. Here's a sample of the output that I got running jam:

$ jam
sources/test/kits/app/Jamfile: No such file or directory
don't know how to make distro/x86.R5/beos/system/lib/
...found 918 target(s)...
...updating 358 target(s)...
...can't find 1 target(s)...
...can't make 1 target(s)...
MkDir1 objects
MkDir1 objects/x86.R5
MkDir1 objects/x86.R5/os
MkDir1 objects/x86.R5/os/kits
MkDir1 objects/x86.R5/os/kits/app
C++ objects/x86.R5/os/kits/app/Cursor.o
C++ objects/x86.R5/os/kits/app/Handler.o
C++ objects/x86.R5/os/kits/app/Invoker.o
C++ objects/x86.R5/os/kits/app/Looper.o
C++ objects/x86.R5/os/kits/app/MessageFilter.o
C++ objects/x86.R5/os/kits/app/MessageQueue.o
C++ objects/x86.R5/os/kits/app/TokenSpace.o
MkDir1 objects/x86.R5/os/kits/interface
C++ objects/x86.R5/os/kits/interface/Alert.o
C++ objects/x86.R5/os/kits/interface/Box.o
C++ objects/x86.R5/os/kits/interface/Button.o
C++ objects/x86.R5/os/kits/interface/CheckBox.o
[... many more lines below omitted ...]

While running jam, I encountered a number of warnings (mostly missing function prototypes), but the only errors came from a couple of apps in the Preferences subdirectory -- consequently, binaries were not created for them. But the remainder of the source tree compiled with no problems.

Create boot floppies

When jam finishes with the build, you will see some directions (from the Kernel scripts) for creating boot floppies. Here's the end of the jam output, with the 'dd' command invoked to create the boot floppy:

[... many more lines above omitted ...]
Cc objects/x86.R5/os/kits/kernel/boot/bootmaker.o
Link objects/x86.R5/os/kits/kernel/boot/bootmaker
Cc objects/x86.R5/os/kits/kernel/boot/bin2h.o
Link objects/x86.R5/os/kits/kernel/boot/bin2h
Cc objects/x86.R5/os/kits/kernel/boot/bin2asm.o
Link objects/x86.R5/os/kits/kernel/boot/bin2asm
Cc objects/x86.R5/os/kits/kernel/boot/makeflop.o
Link objects/x86.R5/os/kits/kernel/boot/makeflop
KernelStaticLibraryObjects objects/x86.R5/os/kits/kernel/libm.a
BuildKernel objects/x86.R5/os/kits/kernel/kernel.x86

Kernel linked!

KernelFloppyImage floppy.x86

*         Kernel build completed!               *
*    Boot image for a 1.44M floppy created      *

Floppy image is floppy.x86
The following command will write it to a floppy on BeOS
  dd if=floppy.x86  of=/dev/disk/floppy/raw bs=18k

...failed updating 4 target(s)...
...skipped 3 target(s)...
...updated 352 target(s)...
$ dd if=floppy.x86 of=/dev/disk/floppy/raw bs=18k
23+1 records in
23+1 records out	

Booting into OpenBeOS

With your fresh boot floppy in hand, you are now ready to try your first boot into OpenBeOS. If your computer is not compatible for some reason, the boot process will freeze at some point and go no further. Hopefully that won't happen, and you will see a screen similar to the one below. This is a mockup of the boot screen I get after booting on my second (new) computer.

Bootup Screen

stage2 bootloader entry.
memsize = 0xff80000, in_vesa 0, vesa_ptr 0x0
CPU: family 6 model 11 stepping 1, string 'GenuineIntel'
CPU at 1195768966 Hz
smp: apic @ 0xfee00000, i/o apic 0xfec00000, total 1 processors detected
jumping into kernel at 0x80009210
init: Welcome to OpenBeOS!

Open source thesis that thousand of eyes looking thu the code
increases software quality is completely wrong. The amount of
bugs per line of code is an universal constant. The bazaar
model only achieves a quick bug turnover.

init: spawned shell, pid 0x3
Welcome to the OpenBeOS shell
> ls
2 files found
> hostname

When the computer boots, it tries to read the first boot sector (the first 512 bytes) from the floppy disk and execute the commands found there. In the case of our kernel, this first stage code merely loads and jumps to the second stage bootstrap, called 'stage2'. You can see the stage2 loader being entered on the screen output.

After this, the hardware is checked and some basic data about what was found is displayed. Here we see that I have a single Intel (genuine, hehe) processor running at 1.2GHz and with 256MB memory onboard.

The last message from the stage2 bootloader is that the kernel is being entered. By this time, all the kernel objects have been created and intialized (rootfs, devfs, virtual memory) and the first program is ready to run. The first program loaded is 'init', which prints out a welcome message, runs another program called 'fortune' that displays a humorous quote, then spawns the command shell. Notice how the text color goes a bit darker as we exit the bootstrap and enter the kernel.

From there, I ran 'ls', one of the few commands available in the native shell. Then I ran 'hostname', a program just recently added by David Reid. Hmmm, my computer seems to have a very interesting hostname... ;-)

What next?

Well, the most obvious shortcoming is the lack of a disk-based file system. The kernel is currently running with everything loaded into memory. The sample apps included have any needed files loaded at boot time in the rootfs (e.g. you can find the fortunes data file at '/boot/etc/fortunes'). As long as we can only load what fits onto a floppy, we won't have much to run.

Naturally, this will change as soon as we have BFS finished and integrated with the kernel. The BFS team is quickly approaching beta status as I write this. However, the integration with the kernel, via the VFS (virtual file system) layer, will have to be redone (the NewOS VFS is not quite compatible with the BeOS layer). This is very tricky work, as is all kernel programming, but at least the interface is fairly well understood.

Once the VFS layer is complete, we can move to the next stage and create CDs to install the OS components onto the hard disk. This will, of course, involve creating a new BFS partition (or overwriting a previous one). That will be a very important (and exciting) milestone. And when we can install the entire OS... well, that's going to be sweet!