Building Android for BeagleBone Black with Kernel 3.2

August 22, 2013 ezequielaceto

Note: SGX (hardware-accelerated OpenGL) is supported only in Kernel 3.2

Get source (using TI DevKit)

mkdir ~/ti-android-bbb cd ~/ti-android-bbb repo init -u git://gitorious.org/rowboat/manifest.git -m TI-Android-JB-4.2.2-DevKit-4.1.1.xml repo sync

Setup

export PATH=~/ti-android-bbb/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin:$PATH

Build U-Boot and X-Loader

cd ~/ti-android-bbb/u-boot make CROSS_COMPILE=arm-eabi- distclean make CROSS_COMPILE=arm-eabi- am335x_evm_config make CROSS_COMPILE=arm-eabi-

Build Android and Kernel with SGX On

cd ~/ti-android-bbb make TARGET_PRODUCT=beagleboneblack OMAPES=4.x make TARGET_PRODUCT=beagleboneblack fs_tarball

Creating the SD Card

mkdir ~/android-bbb-image cp ti-android-bbb/kernel/arch/arm/boot/uImage ~/android-bbb-image cp ti-android-bbb/u-boot/MLO ~/android-bbb-image cp ti-android-bbb/u-boot/u-boot.img ~/android-bbb-image cp ti-android-bbb/external/ti_android_utilities/am335x/u-boot-env/uEnv_beagleboneblack.txt ~/android-bbb-image cp ti-android-bbb/out/target/product/beagleboneblack/rootfs.tar.bz2 ~/android-bbb-image cp ti-android-bbb/external/ti_android_utilities/am335x/mk-mmc/mkmmc-android.sh ~/android-bbb-image cd ~/android-bbb-image sudo./mkmmc-android.sh /dev/sdX MLO u-boot.img uImage uEnv_beagleboneblack.txt rootfs.tar.bz2

Compiling Android with Kernel 3.8

August 22, 2013 ezequielaceto

Replace Rowboat default Kernel with Kernel 3.8

Note 1: SGX is not yet supported on Kernel 3.8 so there is no hardware-accelerated OpenGL on this release./pre>

Note 2: Consider Rowboat for BeagleBone Black was cloned at ~/rowboat-android-bbb and Kernel 3.8 is at ~/linux-dev

cd ~/rowboat-android-bbb mv kernel kernel.bkp ln -s ~/linux-dev/KERNEL kernel

Let's modify some Makefiles in order to use 'arm-linux-gnueabihf-' instead of 'arm-eabi' for compiling.
chmod 644 ~/rowboat-android-bbb/Makefile vi ~/rowboat-android-bbb/Makefile
And add a # (comment) in front of export PATH :=$(PATH):$(ANDROID_INSTALL_DIR)/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin.
Below that (new) comment add the following two lines and save
export PATH :=~/linux-dev/dl/gcc-linaro-arm-linux-gnueabihf-4.7-2013.04-20130415_linux/bin:$(PATH) export CC_PREFIX := arm-linux-gnueabihf-
Search the Makefile for references to arm-eabi- and replace them with $(CC_PREFIX). Once all the changes are saved, go on building Android with SGX support.
$ make TARGET_PRODUCT=beagleboneblack OMAPES=4.x droid -j4 (It takes more or less 2 hours on a Intel i5 with 8GB of RAM.)

BeagleBone Black and Linux Kernel 3.8 with Android support

August 22, 2013 ezequielaceto

Building Kernel 3.8 (with Device Tree)

cd ~/ git clone git://github.com/RobertCNelson/linux-dev.git cd linux-dev/ git checkout origin/am33x-v3.8 -b tmp ./build_kernel.sh
If ./build_kernel.sh fails with ‘undefined references’ to some functions in files like ‘menubox.c’ try running: sudo apt-get install libncurses5 libncurses5-dev libelf-dev libncurses5 libncursesw5-dev and then retry with ./build_kernel.sh.

Setting up Kernel 3.8.x for Android

Once in the Kernel Configuration Utility (kConfig) scroll down, and enter, ‘Device Drivers’.

Make sure the ‘Staging drivers’ are enabled, or enable them (an asterisk will appear between brackets)

Then, enter ‘Staging drivers’ -> ‘Android’. Enable all Android drivers. I recommend you to include them into the kernel, and not build them as module.

Exit ‘kConfig’ and the Kernel will begin building.

When it is done you will see something like

Next: U-Boot for BeagleBone Black

Installing busybox (for Android) on BeagleBoard

August 14, 2013 ezequielaceto

Busybox

BusyBox provides several stripped-down Unix tools in a single executable file. It runs in a variety of POSIX environments such as Linux, and Android. Some of these tools are

ssty
su
gzip
ping
netstat
tar
arp
wc
microcom

Why is busybox necessary on a BeagleBoard running Android?

The default Android build does not have many useful tools like stty, so there it is where this swiss army knife comes to rescue.

Installing busybox

Download ‘busybox’ from http://benno.id.au/android/busybox
Connect to the board using ADB. ./adb shell
Create a busybox directory inside data. mkdir /data/busybox
Exit ADB. exit
Push the downloaded file to the board. ./adb push busybox /data/busybox/busybox
Enter Shell again. ./adb shell
And change permission in order to let any app execute busybox. chmod 777 /data/busybox/busybox

Beagleboard xM & native FTDI VCP driver

August 9, 2013 ezequielaceto

Adding the driver to the Kernel

cd ~/rowboat-android/kernel make ARCH=arm CROSS_COMPILE=arm-eabi- distclean make ARCH=arm CROSS_COMPILE=arm-eabi- omap3_beagle_android_defconfig
Up to this point everything goes as normal. Now let’s add the FTDI support as a driver (NOT as a module). FTDI published a very detailed tutorial that can be found at http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_132_Adding_FTDI_Devices_VCP_Driver_Support_to_Android.pdf.
make ARCH=arm CROSS_COMPILE=arm-eabi- menuconfig
If ‘menuconfig’ is not present in the host (Ubuntu), install it using the following code:
sudo aptitude install lib32ncurses5-dev
As the documentation presented by FTDI says, it is necessary to enable a few things:

“Device Drivers” -> “USB Support” -> pres ‘y’ over “Support for Host-side USB”
“Device Drivers” -> “USB Support” -> “USB Serial Converter support” -> press ‘y’ over “FTDI Single Port Serial Driver”

Now save this configuration and build the Kernel using
make ARCH=arm CROSS_COMPILE=arm-eabi- -j4
When connecting a FTDI device to the BB xM with this modified Kernel, you will see a ttyUSBx directory inside /dev.

Connecting the FTDI device to the Beagleboard

First of all it will be very useful to connect the Beagleboard Serial port to the host machine and establish a connection using Minicom (or something like that). Once you got there it will be very easy to see if the driver was properly included, and the device is recognized.
See the following screenshot. It shows the device console before the FTDI converter was connected and after that. The device was recognized perfectly, and ttyUSB0 was created under /dev.

A simple test from shell

If you have busybox on Android you can make a simple test in order to see if the driver is well configured (In case you don’t have busybox, you can follow my post on how to install busybox on BeagleBoard).

Connect RX and TX on the FTDI IC
Connect to board using ADB. ./adb shell
Setup ttyUSB0. /data/busybox/busybox stty -F /dev/ttyUSB0 115200
Open microcom (similar to minicom) /data/busybox/busybox microcom -s 115200 /dev/ttyUSB0
Write something and it will be echoed. If you disconnect the RX and TX, what you send it will not be echoed.

Writing to ttyUSB from C

Init the ttyUSB interface

system("/data/busybox/busybox stty -F /dev/ttyUSB0 115200");
The ttyUSB interface can also be initiated from /init.rc file at the end of “on boot” section.

Getting a File Descriptor

FILE * usbdev = fopen("/dev/ttyUSB0", "rw+");

Read and Write from the File Descriptor

char message[20]; /* buffer of data to send */ char rMessage[20]; /* receive buffer */ fwrite(message, sizeof(char), 8, usbdev); fread(rMessage, sizeof(char), 8, usbdev);

Closing the File Descriptor

fclose(usbdev);

Writing to ttyUSB from Java

Connecting to ttyUSB from Java requires a little bit of extra work. By default, a device under “dev” has permissions only for root. And if your Java app it is not running with root (or your base board is not rooted) you have to change permissions to ttyUSB0 in order to let other apps to write and read from the file (using JNI, of course).
This can be done using several methods, for example:
chmod 777 /dev/ttyUSB0

Building Android Jelly Bean (4.1.2) for Beagleboard xM

November 5, 2012 ezequielaceto

Jelly Bean on Beagleboard xM

Prerequisites

Ubuntu 12.04 LTS – AMD64

A 64-bit OS is needed in order to build Android 4.x from source code

Dual- or Quad-core (recommended) CPU
At least 4GB of RAM
45GB of free disk space
Internet connection

Installing utils and libs

From a Terminal console execute
sudo aptitude install ia32-libs
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 openjdk-6-jdk tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386
and then
sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

Installing Oracle Java JDK

Download Oracle Java6 JDK from here (file: jdk-6u34-linux-x86.bin) to ~/Downloads
In a Terminal cnosole execute

cd ~/Downloads
cp jdk-6u43-linux-x64.bin ~/
cd ~/
chmod +x jdk-6u43-linux-x64.bin
./jdk-6u43-linux-x64.bin
sudo mv jdk1.6.0_43/ /usr/lib/jvm/

Add Oracle Java6 JDK to Ubuntu JVM list

sudo update-alternatives –install /usr/bin/javac javac /usr/lib/jvm/jdk1.6.0_43/bin/javac 1
sudo update-alternatives –install /usr/bin/java java /usr/lib/jvm/jdk1.6.0_43/bin/java 1
sudo update-alternatives –install /usr/bin/javaws javaws /usr/lib/jvm/jdk1.6.0_43/bin/javaws 1

Select Oracle Java6 JDK as default JVM

sudo update-alternatives –config javac
sudo update-alternatives –config java
sudo update-alternatives –config javaws

In this three last commands, select Oracle Java6 JDK as default, like in the example below
kimi@X-Server:~$ sudo update-alternatives --config java There are 2 choices for the alternative java (providing /usr/bin/java).
Selection Path Priority Status
————————————————————
0 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 auto mode
1 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 1061 manual mode
* 2 /usr/lib/jvm/jdk1.6.0_34/bin/java 1 manual mode
Press enter to keep the current choice[*], or type selection number: 2

Installing REPO

Repo is a tool created by Google in order to admin git repositories easyly.
In a Terminal console execute

mkdir ~/bin
export PATH=~/bin:$PATH
curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
chmod a+x ~/bin/repo

Initialize the repository

mkdir ~/rowboat-android
cd ~/rowboat-android
repo init -u git://gitorious.org/rowboat/manifest.git -m rowboat-jb-am37x.xml (JB for Beagleboard)
repo sync

If a warning telling you that there is a new REPO version appears. Stop the sync process and update

cp ~/rowboat-android/.repo/repo/repo ~/bin/repo
chmod a+x ~/bin/repo
repo sync

Once the repo is successfully synced, you will see a message like this:
* [new branch] rowboat-froyo -> rowboat/rowboat-froyo * [new branch] rowboat-gingerbread -> rowboat/rowboat-gingerbread * [new branch] rowboat-ics -> rowboat/rowboat-ics * [new branch] rowboat-jb -> rowboat/rowboat-jb * [new branch] ti-dsp -> rowboat/ti-dsp Fetching projects: 100% (261/261), done. Checking out files: 100% (8843/8843), done.out files: 10% (949/8843) Checking out files: 100% (24601/24601), done.ut files: 50% (12308/24601) Checking out files: 100% (18021/18021), done.ut files: 3% (616/18021) Checking out files: 100% (35638/35638), done.ut files: 1% (663/35638) Checking out files: 100% (2088/2088), done. out files: 6% (134/2088) Checking out files: 100% (974/974), done.ng out files: 34% (336/974) Checking out files: 100% (667/667), done.ng out files: 18% (123/667) Checking out files: 100% (2412/2412), done. out files: 4% (106/2412) Checking out files: 100% (26958/26958), done.ut files: 24% (6516/26958) Checking out files: 100% (81/81), done. Checking out files: 100% (441/441), done.ng out files: 43% (194/441) Checking out files: 100% (6505/6505), done. out files: 1% (108/6505) Syncing work tree: 100% (261/261), done.
kimi@X-Server:~/rowboat-android$

Cross compiling Jelly Bean for Beagleboard

Now we are going to modify the PATH variable in order to include the binary directory of the GCC compiler. The following command should be executed every time you open a new Terminal console and want to compile the code. Unless, you include the new PATH into your ‘.bashrc’ or ‘.bash_profile’ file.
export PATH=~/rowboat-android/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin:$PATH

X-loader

X-loader is a small first stage boot loader derived from the u-boot base code to be loaded into the internal static ram by the OMAP ROM code. Because the internal static ram is very small (64k-32k), x-loader is stripped down to the essentials and is used to initialize memory and enough of the peripheral devices to access and load the second stage loader (U-boot) into main memory.
In order to build X-loader we will follow these steps
cd ~/rowboat-android/x-loader/ make CROSS_COMPILE=arm-eabi- distclean make CROSS_COMPILE=arm-eabi- omap3beagle_config make CROSS_COMPILE=arm-eabi- -j4
the parameter ‘-j4’ will tell the make to use up to 4 threads to build the code. If you have a dual-core/two-threads CPU, use ‘-j2’. Omitting this parameter will also compile the code, but using just a single thread (which for x-loader or u-boot is not a big problem, but the Android source code can take many hours).
The result of this process is a file named ‘x-load.bin’ on the current directory. This file should be signed with a tool called ‘signGP’ before x-loader gets into the MMC card.

Downloading Rowboat-tools for Jelly Bean

cd ~ curl http://rowboat.googlecode.com/files/RowboatTools.tar.gz > RowboatTools.tar.gz tar -zxvf RowboatTools.tar.gz

Signing x-load.bin

cp ~/RowboatTools/signGP/signGP ~/rowboat-android/x-loader/signGP cd ~/rowboat-android/x-loader ./signGP x-load.bin cp x-load.bin.ift MLO
Now we have a ‘MLO’ file which is a signed version of the binary x-loader, and this file can be used in the board.

Uboot

Uboot is a universal bootloader program that developed for the loading and starting of embedded Linux systems. Uboot essentially can load a (linux) kernel from one of several locations, and start it with corresponding arguments.
cd ~/rowboat-android/u-boot/ make CROSS_COMPILE=arm-eabi- distclean make CROSS_COMPILE=arm-eabi- omap3_beagle_config make CROSS_COMPILE=arm-eabi- -j4
The result of this process is ‘u-boot.bin’ file. And a successful build generates an output like this:
api/libapi.a post/libpost.a board/ti/beagle/libbeagle.a --end-group /home/kimi/rowboat-android/u-boot/arch/arm/lib/eabi_compat.o -L /home/kimi/rowboat-android/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/../lib/gcc/arm-eabi/4.6.x-google -lgcc -Map u-boot.map -o u-boot arm-eabi-objcopy -O srec u-boot u-boot.srec arm-eabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin kimi@X-Server:~/rowboat-android/u-boot$

Building Android, Kernel and SGX

In order to build Android, its kernel and SGX (which provides the Hardware Acceleration needed by Android 3.x+)
cd ~/rowboat-android make TARGET_PRODUCT=beagleboard OMAPES=5.x -j4
(This step takes aprox. 1 hour)
If this commad successed you will see something like this on the console
Installation complete!
cat install.sh >install
chmod a+x install
make[1]: Leaving directory `/home/kimi/rowboat-android/hardware/ti/sgx’
If you don’t see an output like this, try running the command without “-j4”.
If everything is Ok, then it’s time to create the root filesystem and compress it into a tar.gz file. (20 minutes. aprox)
cd ~/rowboat-android make TARGET_PRODUCT=beagleboard fs_tarball -j4

Building Kernel and Android separately

It is possible to build the kernel and Android separately, and this is recommended once you have done a full build and you have modified only a small part of the code.

Builing the Kernel

cd ~/rowboat-android/kernel make ARCH=arm CROSS_COMPILE=arm-eabi- distclean make ARCH=arm CROSS_COMPILE=arm-eabi- omap3_beagle_android_defconfig make ARCH=arm CROSS_COMPILE=arm-eabi- uImage -j4
This will generate ‘uImage’ (kernel image) in “~/rowboat-android/kernel/arch/arm/boot”

Builing Android

cd ~/rowboat-android make TARGET_PRODUCT=beagleboard droid -j4
Again, in order to create the root filesystem, run
cd ~/rowboat-android make TARGET_PRODUCT=beagleboard fs_tarball

Creating a bootable SD-Card

Once x-load, Uboot, kernel and Android are built, it’s time to create a bootable SD-Card with all this files.

Boot arguments

Edit boot arguments for am37x.
cd ~/RowboatTools/am37x/mk-bootscr gedit boot.scr
Change mem=256M with mem=448M. This will increase the amount of RAM available in Android for applications.
Generate boot script
./mkbootscr

Putting all together

Format the SD Card into a single FAT32 partition. A +4GB SD Card is recommended, while the minimum amount of memory is 2GB.
mkdir ~/rowboat-image cp ~/rowboat-android/kernel/arch/arm/boot/uImage ~/rowboat-image cp ~/rowboat-android/u-boot/u-boot.bin ~/rowboat-image cp ~/rowboat-android/x-loader/MLO ~/rowboat-image cp ~/RowboatTools/am37x/mk-bootscr/boot.scr ~/rowboat-image cp ~/rowboat-android/out/target/product/beagleboard/rootfs.tar.bz2 ~/rowboat-image cp ~/RowboatTools/am37x/mk-mmc/mkmmc-android.sh ~/rowboat-image
Execute the script
cd ~/rowboat-image sudo ./mkmmc-android.sh /dev/sdb MLO u-boot.bin uImage boot.scr rootfs.tar.bz2
Change /dev/sdb with the path for your SD Card
If you don’t see anything executed on the console, may be mkmmc-android.sh has a hidden char that generates problem. Try opening the file with gEdit and copying the content to another file, for example mkmmc.sh. Then make that file executable and try again.

Ready!

Now you are ready to extract the SD Card, insert it into the Beagleboard and run Android. Be patience, the first start up can take several minutes. The second time you start up Android it takes minutes more or less.

Performance

Some SD Cards show a very poor performance. Most Kingston micro SDHC cards have this performance issue. San Disk micro SDHC or Sony micro SDHC are recommended.

Known issues

mmc0: error -110 whilst initializing SD card

Your are using a SDHC Card affected by preemption model in Kernel 2.6. Look to this post about loading “rootfs” from USB . This avoids the bug, and gives more performance & storage space.

SVN Tip

January 24, 2012 ezequielaceto

//search and delete .svn
find . -depth -name .svn -exec rm -fr {} ;

I want to boot my Kernel on a real machine

October 23, 2011 ezequielaceto

Testing and running the Kernel with QEMU is nice, it is faster for developing but it is not what we want. We want to run things in real hardware.
#mtools echo "drive c: file="`pwd`/bootable.img" partition=1" > ~/.mtoolsrc
#create an image dd if=/dev/zero of=bootable.img count=088704 bs=512 mpartition -I c: mpartition -c -t 88 -h 16 -s 63 c: mformat c: mmd c:/boot mmd c:/boot/grub
#copy grub bootloader mcopy grub/grub-0.94-i386-pc/boot/grub/stage1 c:/boot/grub mcopy grub/grub-0.94-i386-pc/boot/grub/stage2 c:/boot/grub mcopy grub/grub-0.94-i386-pc/boot/grub/fat_stage1_5 c:/boot/grub
#grub echo "(hd0) bootable.img" > bmap printf "geometry (hd0) 88 16 63 n root (hd0,0) n setup (hd0)n" | /usr/sbin/grub --device-map=bmap --batch
#copy menu.lst to bootable.img mcopy menu.lst c:/boot/grub/

mcopy kernel.bin c:/boot/grub/
We can test this image using qemu like this
qemu -hda bootable.img
Then, the image can be burned into a pendrive using ‘dd’ or ‘usb-imagewriter’

sudo apt-get install usb-imagewriter (in order to install the GUI Tool)
sudo dd if=bootable.img of=/dev/sdX (where sdX is the pendrive location into /dev)

Monolithic or Micro Kernels

October 23, 2011 ezequielaceto

Small differences

The Kernel is that tiny but very important part of the Operating System that acts as bridge between the applications and the low level resources of the computer.When your computer boots, after the boot loader is executed, the Kernel is called. I/O operations and Memory are the most important abstractions of the Kernel, and if the Kernel can run in several processors, it is also important the CPU abstraction.
There are two types of Kernels those called “monolithic kernels” and “microkernels”. The first one embedded all the OS services inside the Kernel. May be this is the easier Kernel to implement, but if there is a bug in some part of the code, it will probably crash the Kernel. Microkernels takes a different approach. Why implementing a monolithic Kernel is not a bad idea? Because this type of kernels are faster, they may have less bugs, and the compiled version may be smaller. And this is the approach used in traditional Unix-like systems. So, it’s not a bad idea.
Microkernels implements minimal OS services, like memory management, multitasking or process communications, but leaves other services like networking outside the kernel, and those services should be implemented in the user space area. This kind of kernels are easier to maintain, and you can load and unload a module without restarting the kernel. But generally the kernel occupies a lot of memory, and bugs are harder to fix.

The Kernel as an abstraction layer between hardware and software

Starting from Scratch… (It's a nice day for writing a Kernel)

October 23, 2011 ezequielaceto

As most of us wished when we were kids, I also wanted to have my own OS. In those days, when I was nearly 12, it was not easy to find somebody that teaches me how to write an operating system, also, it was very difficult to find access to Internet or even a BBS. Now things a little bit easier, and may be I can my dream come true.
The first thing I will point out is… “I will not create a boot loader”. And this is a crucial decision. GRUB is good enough in order to let things prepared so my kernel can run properly.
Creating a kernel, either a monolithic or a microkernel, involves dealing in some point with assembly code. But as modern computers are plenty of resources like RAM and disk, it’s better to reduce the amount of assembly code. That’s why the only thing I will write in assembly right now, it’s my start up code. Why? Because there are some things that needs to be set like, “excuse me, this code is 32-bit”, and “please CPU, stop running”. That is why I will create an assembly file that defines a global function that calls the kernel’s main.
File: xkernel_boot.asm%include "grub.inc" ; GRUB comes to rescue!
[BITS 32] [global start] [extern _k_main] ;the kernel's main is a function defined in a cpp file.

start: call _k_main ;starts the kernel cli ; disables CPU's interrupts hlt ; stops the CPU
File: grub.inc;; this is for building a multiboot header ;; a multiboot header must exist for GRUB ;; to load the kernel

MULTIBOOT_PAGE_ALIGN equ 1<<0 MULTIBOOT_MEMORY_INFO equ 1<<1 MULTIBOOT_AOUT_KLUDGE equ 1<<16 MULTIBOOT_HEADER_MAGIC equ 0x1BADB002 MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_MEMORY_INFO | MULTIBOOT_AOUT_KLUDGE MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
When the boot loader executes this piece of code, it will call the k_main defined in kernel.cpp. Writing a kernel in C++ is a bit harder than in C. Because the fact that it’s done in C++ doesn’t mean that you can use all the languages improvement in a kernel. For example, there is no “new” or “delete”, not even try/catch or dynamic casting. If you want this operations in the kernel, you have to implement the standard C++ library. (TIP: this features can be switched off when compiling and linking)
So what’s the advantage of making a Kernel in C++? Making it object oriented!
File: xkernel.cpp/* XKernel :: by Ezequiel L. Aceto */ // main does not take any argument in the kernel
int k_main() { std::cout << "XKernel" << std::endl; //TODO: implement kernel... return 0; }
Let’s compile!
g++ -c *.cpp -ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions
-ffreestanding A freestanding environment is one that may not have stdlib, and may not have a main
-nostdlib No stdlib
-fno-builtin Don’t recognize built-in functions that do not begin with `__builtin_’ as prefix.
-fno-rtti Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (`dynamic_cast’ and `typeid’).
-fno-exceptions Compile with no exceptions support

From this point on, it is always useful to create some functions that handles the video card, in order to write chars, clean the screen. Let’s name the video driver XKernel_SVC (Simple Video Controller) cpp and h.
Then we compile all the files using the same command we used for compiling the xkernel.cpp. As you may noticed, we have an assembly file which should also be compiled. For this purpose you will need ‘nasm’ (Netwide Assembler’) which is a general purpose x86 assembler.
nasm -f aout xkernel_boot.asm -o xkernel_boot.o
Then, the Linking process starts. But a Linker script will be used in order to simplify the process.
OUTPUT_FORMAT("binary") ENTRY(start) SECTIONS { .text 0x100000: { code =.;_code =.;__code=.; *(.text) .=ALIGN(4096); }
.data: { data =.;_data =.;__data=.; *(.data) .=ALIGN(4096);
}
.bss: { bss =.;_bss =.;__bss=.; *(.bss) .=ALIGN(4096);

} }
Then we link:
ld -T linker.ld -o xkernel.bin xkernel_boot.o xkernel.o xkernel_svc.o
This will cause a few errors, like “undefined reference to ‘std::ios_base::Init::Init()'” or “undefined reference to ‘__dso_handle’. This errors are caused by unimplemented c++ features. In order to solve this, let’s make a few changes.
File: icxxabi.h
#ifndef _ICXXABI_H #define _ICXXABI_H
#define ATEXIT_MAX_FUNCS 128
#ifdef __cplusplus extern "C" { #endif
typedef unsigned uarch_t; struct atexit_func_entry_t { /* * Each member is at least 4 bytes large. Such that each entry is 12bytes. * 128 * 12 = 1.5KB exact. **/ void (*destructor_func)(void *); void *obj_ptr; void *dso_handle; }; int __cxa_atexit(void (*f)(void *), void *objptr, void *dso); void __cxa_finalize(void *f); #ifdef __cplusplus }; #endif

#endif
File: icxxabi.cpp
#include "./icxxabi.h"
#ifdef __cplusplus extern "C" { #endif
atexit_func_entry_t __atexit_funcs[ATEXIT_MAX_FUNCS]; uarch_t __atexit_func_count = 0;
void *__dso_handle = 0; //Attention! Optimally, you should remove the '= 0' part and define this in your asm script. int __cxa_atexit(void (*f)(void *), void *objptr, void *dso) { if (__atexit_func_count >= ATEXIT_MAX_FUNCS) {return -1;}; __atexit_funcs[__atexit_func_count].destructor_func = f; __atexit_funcs[__atexit_func_count].obj_ptr = objptr; __atexit_funcs[__atexit_func_count].dso_handle = dso; __atexit_func_count++; return 0; /*I would prefer if functions returned 1 on success, but the ABI says...*/ }; void __cxa_finalize(void *f) { uarch_t i = __atexit_func_count; if (!f) { /* * According to the Itanium C++ ABI, if __cxa_finalize is called without a * function ptr, then it means that we should destroy EVERYTHING MUAHAHAHA!! * * TODO: * Note well, however, that deleting a function from here that contains a __dso_handle * means that one link to a shared object file has been terminated. In other words, * We should monitor this list (optional, of course), since it tells us how many links to * an object file exist at runtime in a particular application. This can be used to tell * when a shared object is no longer in use. It is one of many methods, however. **/ //You may insert a prinf() here to tell you whether or not the function gets called. Testing //is CRITICAL! while (--i) { if (__atexit_funcs[i].destructor_func) { /* ^^^ That if statement is a safeguard... * To make sure we don't call any entries that have already been called and unset at runtime. * Those will contain a value of 0, and calling a function with value 0 * will cause undefined behaviour. Remember that linear address 0, * in a non-virtual address space (physical) contains the IVT and BDA. * * In a virtual environment, the kernel will receive a page fault, and then probably * map in some trash, or a blank page, or something stupid like that. * This will result in the processor executing trash, and...we don't want that. **/ (*__atexit_funcs[i].destructor_func)(__atexit_funcs[i].obj_ptr); }; }; return; }; for ( ; i >= 0; ) { /* * The ABI states that multiple calls to the __cxa_finalize(destructor_func_ptr) function * should not destroy objects multiple times. Only one call is needed to eliminate multiple * entries with the same address. * * FIXME: * This presents the obvious problem: all destructors must be stored in the order they * were placed in the list. I.e: the last initialized object's destructor must be first * in the list of destructors to be called. But removing a destructor from the list at runtime * creates holes in the table with unfilled entries. * Remember that the insertion algorithm in __cxa_atexit simply inserts the next destructor * at the end of the table. So, we have holes with our current algorithm * This function should be modified to move all the destructors above the one currently * being called and removed one place down in the list, so as to cover up the hole. * Otherwise, whenever a destructor is called and removed, an entire space in the table is wasted. **/ if (__atexit_funcs[i].destructor_func == f) { /* * Note that in the next line, not every destructor function is a class destructor. * It is perfectly legal to register a non class destructor function as a simple cleanup * function to be called on program termination, in which case, it would not NEED an * object This pointer. A smart programmer may even take advantage of this and register * a C function in the table with the address of some structure containing data about * what to clean up on exit. * In the case of a function that takes no arguments, it will simply be ignore within the * function itself. No worries. **/ (*__atexit_funcs[i].destructor_func)(__atexit_funcs[i].obj_ptr); __atexit_funcs[i].destructor_func = 0; /* * Notice that we didn't decrement __atexit_func_count: this is because this algorithm * requires patching to deal with the FIXME outlined above. **/ }; }; };

#ifdef __cplusplus }; #endif
Icxxabi will solve the errors related with __dso_handle and __cxa_atexit, but not with Init() and static initialization and destruction. For solving this error, it is necessary to implement local static variables, and as an extra feature, the ‘new’ and ‘delete’ operator.