Virtual OS

A Project Report Submitted in partial fulfilment of the requirements for the Degree of
Bachelor of Technology

in Computer Science and Engineering

by

Nimisha Narayanan P K Nidhin T M Aakash Sasidharan

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

GOVERNMENT ENGINEERING COLLEGE, WAYANAD

JANUARY 2012

GOVERNMENT ENGINEERING COLLEGE W AYANAD

CERTIFICATE
This is to certify that Nidhin T M has successfully completed the mini project titled

Virtual OS towards the partial fullllment for the award of the degree of Bachelor of Technology in Computer Science and Engineering.

Project Guide

Head of Department

Oce Seal

TO

All our friends and teachers...

Acknowledgements
First of all, we would like to express our sincere gratitude to Dr. B ANIL, Principal and Mr. ANVAR A, Associate Professor and H.O.D of Computer Science Department of Government Engineering College, Wayanad for providing us an opportunity and the perfect ambience to do our project work on VIRTUAL OS. It would be our utmost pleasure to express our warm thanks to Mr. SMINESH, Project Coordinator, for his encouragement, co-operation and consent. Without him we would not have been able to accomplish our project. We are extremely grateful and remain indebted to our guide Ms. Binatha,Asst Professor in Computer Science and Engineering department, for her constant support and being a source of inspiration in the design, implementation and evaluation of the project. We are thankful to our teachers for their constant constructive criticism and valuable suggestions which beneted us a lot while developing our project. Last but not the least we would like to thank our friends and classmates who were always with us in this venture with their valuable suggestions.

Abstract
This report describes the details about the design and implementation of a Symbian OS emulator on Kubuntu Linux. The Symbian OS will be emulated with a slightly adapted version of the open source emulator QEMU. The emulator requires a Symbian OS ROM Image as input for emulating the OS. The ROM image is build with the Symbian Build System, a powerful tool for Symbian C++ codes. This projects major point focuses on steps required for building Symbian OS ROM image.

ii

Contents
Acknowledgements Abstract Keywords 1 Introduction
1.1 1.2 2.1 2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i ii vi 1
1 2

2 Analysis and Design

2.3 3.1

QEMU . . . . . . . . . . . . . . . . . . . . Creating Symbian ROM image . . . . . . . 2.2.1 Symbian OS kernel (Generic code) 2.2.2 Base Port(Hardware specic code) 2.2.3 Cross Compiler . . . . . . . . . . . 2.2.4 Symbian Build System(Raptor v2) Overall Design . . . . . . . . . . . . . . . .

3 4 4 5 5 6 6 8

3 Implementation

3.2

3.3 3.4

Tools and Languages used . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Code Sourcery's open-source ARM GCC toolchain for Symbian (GCCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 7z archiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Mercurial Hg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 How Raptor works . . . . . . . . . . . . . . . . . . . . . . . . . . What we have done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Build QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Extract Symbian kernel packages . . . . . . . . . . . . . . . . . . 3.2.3 Build the GCCE kernel-side runtime library . . . . . . . . . . . . 3.2.4 Build the kernel package . . . . . . . . . . . . . . . . . . . . . . . Build the syborg ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boot the Syborg ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

8 8 9 9 9 14 14 15 15 15 16 16

CONTENTS

iv

4 Result 5 Conclusions 6 Reference

17 24 25

List of Figures
2.1 2.2 3.1 4.1 4.2 4.3 4.4 4.5 Overall architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detailed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building Syborg ROM image . . . . . . . . . . . . . . . . . . . . . . . . . Building QEMU. . . . . . . . . . . . . . Building the kernel packages . . . . . . . ROM image failed booting with errors . QEMU booting with Syborg ROM image QEMU booting with Syborg ROM image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 16 18 20 21 22 23

Keywords
Symbian OS, Base Port, Symbian ROM image, Cross Compiler, Emulator(QEMU)

vi

Chapter 1 Introduction
1.1 Motivation

If you are someone who requires a cellphone for business use, you face a dicult decision: Rely on one phone for personal and business use, or carry two handsets around all day. The rst option means you are always potentially on call for work, while the second is just a pain. Although OS emulators like DOSBox that runs on mobile Operating Systems are available, they are not completely functional, not cost eective, not ecient considering the low power, limited memory mobile phones. DOSBox is known to emulate only old windows Operating Systems like Win98. Emulators for Game boy, and other games are available. But a Mobile OS emulator for a Mobile os is still not available. For business IT departments an ecient virtual platform for the guest os solves a big problem in the form of compatibility. Supporting content securely across dierent handsets causes a headache, but being able to rely on just one virtualized OS on every handset means only one system to support regardless of the hardware used.

Chapter 1. Introduction

1.2

Pro ject Introduction

Virtualization or Emulation here means creation of a virtual hardware platform for the guest OS. Emulation is what we do when we try to make one system behave like or imitate a dierent system. We want to take System A (something we already have) and give it the inputs we would normally use for System B (which we may not have) and have System A produce the same results as System B. System A will be the host OS and System B will be the guest OS. Many open source Emulators supporting dierent target machines like x86, arm, etc are available in the market. QEMU(Quick Emulator) is one of the popular open source emulators. Symbian OS is a mobile operating system (OS) designed for smartphones and is created in Symbian C++. The open-source culture has penetrated the smartphone market in several ways. There have been attempts to open source both hardware and software of smartphones.In February 2010 Nokia made Symbian open source under Eclipse Public License(EPL). The popularity of the OS made us select the Symbian OS as the guest OS for emulation. Most commercial smartphones are based on open-source operating systems. These include those based on Linux, such as Google's Android, Nokia's MeeGo, etc. These Linux based OSs uses Linux as a hardware abstraction layer and use the powerful Linux kernel and the wide range of hardware drivers it supports. Inspired from our motivation we decided to develop a Symbian OS emulator for a Kubuntu Linux PC. It will be easy to port this virtual platform to a Linux based Mobile OS.

Chapter 2 Analysis and Design

From 2005, about 95 % of the mobile phones sold each year used at least one ARM processor. Open source emulators like QEMU can be used to emulate the ARM processor.

2.1

QEMU

QEMU is a generic and open source machine emulator and virtualizer. When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a dierent machine (e.g. your own PC). By using dynamic translation, it achieves very good performance. QEMU emulates full hardware platform including CPU and peripherals. QEMU converts instructions in the guest system into instructions on the host system via Tiny Code Generator (TCG). QEMU is made of several subsystems:

CPU emulator (currently x861, PowerPC, ARM and Sparc) Emulated devices (e.g. VGA display, 16450 serial port, PS/2 mouse and keyboard,
IDE hard disk, NE2000 network card, ...)

Generic devices (e.g. block devices, character devices, network devices) used to
connect the emulated devices to the corresponding host devices

Machine descriptions (e.g. PC, PowerMac, Sun4m) instantiating the emulated

devices 3

Chapter 2. Analysis and Design

Debugger User interface

Inorder to emulate the Symbian OS it has to be compiled and build to form an ROM image. The ROM image will be run by the QEMU.

2.2

Creating Symbian ROM image

Symbian OS is written in C++. The base code of the Symbian platform is structured so that generic code is separated from hardware-specic code. This means that porting Symbian to new hardware requires modication or creation of hardware-specic code only. This is what is known as a base port.

2.2.1 Symbian OS kernel (Generic code)

Symbian OS kernel consists of:

Nanokernel: this handles the most basic thread scheduling, synchronisation and
timing functions.

Symbian kernel: this provides the kernel functionality using services provided by
the nanokernel. It contains the operating system objects for such things as threads, processes, chunks, and inter-process communication.

Memory model: this provides per-process address spaces and inter-process data
transfer, and governs how memory is allocated and mapped. It encapsulates access to the hardware Memory Management Unit (MMU), allowing the nanokernel and the Symbian kernel to be MMU-independent.

Variant DLL: this provides hardware dependent services required by the kernel,
for example timer tick interrupts and Real Time Clock access. Systems based on an ASSP (Application Specic Standard Part) also have an ASSP DLL, which shares some of the variant DLLs responsibilities. Board Support Packages provides variant libraries for reference hardware.

Chapter 2. Analysis and Design

Extensions and device drivers: these are used to control peripherals and provide
the interface between peripherals and the rest of Symbian OS. For creating a Symbian ROM image a base port is required.

2.2.2 Base Port(Hardware specic code)

Base Port typically includes:

ASSP code for a specic ASIC (Application Specic Integrated Circuit) Variant code (board specic) Device drivers Media drivers
A base port does not require changes to the kernel, le server or user library. The ASSP/Variant layer provides two main functions. First, it implements a small number of hardware-specic functions that are used by the Kernel. Second, it implements common peripheral control functions that other extensions and device drivers can use. The most important of these functions is interrupt dispatching. During initialisation the ASSP/Variant must specify a dispatch function to be called for all hardware interrupts. In general, the ASSP/Variant provides control functions for hardware which is shared between multiple devices. Syborg is a baseport available for QEMU ARM devices. Syborg is required for Symbian to function on QEMU virtual hardware platform Syborg base port as well as Symbian OS is written in C++. For creating the ROM image, the source code has to be compiled and build using dierent tools. The two major tools used in building the ROM image are: a cross compiler for ARM processor and Symbian Build System/Raptor.

2.2.3 Cross Compiler

A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is run. Cross compiler tools are used to generate executables for embedded system or multiple platforms. Dierent cross compilers for

Chapter 2. Analysis and Design

compiling C++ codes to executables for ARM platform are available like RVCT(ARM RealView Compilation Tools), GCCE, Carbide C++ etc are available. ARM RVCT compiler is the default one packed with Symbian SDKs. It is a proprietary tool requiring license key for compilation. GCCE from CodeSourcery is a free compiler that can build the kernel. GCCE may be obtained from CodeSourcery's website.

2.2.4 Symbian Build System(Raptor v2)

The Raptor build system is used for building Symbian platform C++ applications, packages, or indeed the entire platform. Raptor can run on both Windows and Linux, and works with Symbian OS v9.4 and later (only). Raptor is written in Python and Gnu Make (with supporting Bash shell scripting) with XML conguration les. Also, there is a small number of supporting tools written in C (Talon and the Descrambler). Raptor's make les are only compatible with Gnu Make 3.81. The Raptor conguration les are all in XML. Essential dependencies for development are

Python - preferably Python 2.6.4. Gnu Make 3.81 Gnu Compiler Collection C/C++ Core utils/GNU Tools Appropriate compilers to build for the target platform(s) (e.g. ARM RVCT or
GCCE)

2.3

Overall Design

Symbian baseport (Syborg) required for Symbian to function on QEMU virtual hardware platform

Baseport comprises of ASSP/Variant code as well drivers and kernel extensions Code above baseport is common between Simulator and other target hardware

Chapter 2. Analysis and Design

Figure 2.1: Overall architecture

Figure 2.2: Detailed architecture

Chapter 3 Implementation
3.1 Tools and Languages used

3.1.1

Code Sourcery's open-source ARM GCC toolchain for Symbian (GCCE)

GCCE from CodeSourcery is a free cross compiler that can build the kernel. CodeSourcery G++ Lite edition delivers command-line only tools supporting ARM targets, including:

GNU C and C++ compilers GNU assembler and linker C and C++ runtime libraries GNU debugger
Used for compiling the C++ source codes for the ARM architecture.

3.1.2 7z archiver
7z is a compressed archive le format that supports several dierent data compression, encryption and pre-processing algorithms. The source code for Symbian OS kernel is available as compressed 7z archives. To extract the archive les 7z archiver is needed.

Chapter 3. Implementation

3.1.3 Mercurial Hg
Mercurial is a cross-platform, distributed revision control tool for software developers. Mercurial in simple words is for handling open source repositories available in the Internet. The Symbian Build System is cloned through mercurial.

3.1.4 Python
Python is an interpreted, object-oriented, high-level programming language with dynamic semantics. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for Rapid Application Development, as well as for use as a scripting or glue language to connect existing components together. Symbian Build System is dependent on Python.

3.1.5 How Raptor works

Raptor consists of essentially four main parts: Shell script/batch le command-line interface, Python Code, FLMs (Function-Like Makeles) and XML Conguration les.

Shell Script
The purpose of the shell scripts is to set the correct environment for the build. The main environment settings required are HOSTPLATFORM and HOSTPLATFORM_DIR. These determine the locations of various host utilities. For Linux, this means the bundled versions of Bash, Gnu Make, Python, Talon, PVM and PVMGMake.

Python Code
Python code is referred to as the "front end" of Raptor. Its main roles are

 Metadata parsing: parse build information les (bld.inf's) and MMP les,
including preprocessing etc

 Tool checking: check that specied tools are available and recent enough to
work well with Raptor

 Perform exports: copies out all header les from bld.inf's.

Chapter 3. Implementation

10

 Writing out Raptor's makeles  Writing out XML log les  Passing log les to lter modules to provide customisable output
Plugin Filter
The output from Raptor comes from a number of sources such as the Python interpreter, the make process, child processes of make etc. Raptor's architecture is carefully constructed to ensure that output is valid XML, and the full XML output is always present. However, the full XML output is not always needed. For example, for the terminal output the full XML is far too verbose. Thus, Raptor includes a plug-in lter feature. As the name suggests, these are dynamically loaded at runtime (hence "plug-in") and their purpose is to sieve (hence "lter") the XML output. The lters are Python classes that implement a certain interface. Specically, this interface is dened by the following class: class Filter(object):
class Filter(object): def open(self, params): return False def write(self, text): return False def summary(self): return False def close(self): return False def formatError(self, message): return "sbs: error: " + message + "\n" def formatWarning(self, message): return "sbs: warning: " + message + "\n"

which is dened in $SBS_ HOME/python/lter_ interface.py. Any class that

Chapter 3. Implementation

11

implements this interface it referred to as a lter. You may have as many lters as you wish in any Python module, as long as their names are unique. $SBS_ HOME/python/plugins/lter_ logle.py. As you might expect, these lters are for terminal output and log le output. You may use any number of lters at a time specifying them with the lters option - this option is case-insensitive so it will nd FilterTerminal even if you specify lterterminal. The mechanism works by passing output as it arrives in the Python interpreter's buer to each lter and letting it do something with that output. For the log le lter, this is to simply write the data to the log le. In the case of terminal lter, the output is ltered and much is thrown away to produce informative build output like this example from > sbs -b simple/bld.inf -c armv5
compile compile compile compile compile compile compile compile compile compile compile compile compile compile target target : simple/test1.c++ : simple/test.cpp : simple/test2.cxx : simple/test3.Cpp : simple/test4.cc : simple/test5.CC : simple/test6.C++ : simple/test.cpp : simple/test1.c++ : simple/test2.cxx : simple/test3.Cpp : simple/test4.cc : simple/test5.CC : simple/test6.C++ [armv5\_urel] [armv5\_urel] [armv5\_urel] [armv5\_urel] [armv5\_urel] [armv5\_urel] [armv5\_urel] [armv5\_udeb] [armv5\_udeb] [armv5\_udeb] [armv5\_udeb] [armv5\_udeb] [armv5\_udeb] [armv5\_udeb] [armv5\_urel] [armv5\_udeb]

: epoc32/release/armv5/urel/test.exe : epoc32/release/armv5/udeb/test.exe

no warnings or errors Run time 20 seconds sbs: build log in /home/user/sdk-01/epoc32/build/Makefile.2009-11-30-13-26-41.log \par

Function-Like Makeles (FLMs)

As their name implies, function-like makeles are used like functions: a list of

Chapter 3. Implementation

12

variables is set for that makele and then that FLM is included. This is similar to many other programming languages, where functions dene their arguments and these are set before the function is run. When Make parses the Makele_all, as it parses the included makeles it evaluates all the variables and then expands them for the included the FLM. To see this, here is a cut-down extract of Makele_all.default from a Windows build:
call C:/raptor/lib/flm/e32abiv2exe.flm SBS_SPECIFICATION:=simple.mmp SBS_CONFIGURATION:=armv5_urel COMPONENT_META:=C:/raptor/test/smoke_suite/test_resources/simple/bld.inf COMPONENT_NAME:= COMPONENT_LAYER:= PROJECT_META:=C:/raptor/test/smoke_suite/test_resources/simple/simple.mmp DATE:=C:/raptor/win32/cygwin/bin/date.exe DUMPBCINFO:= GNUMAKE38:=C:/raptor/win32/mingw/bin/make.exe GNUCP:=C:/raptor/win32/cygwin/bin/cp.exe GNUCAT:=C:/raptor/win32/cygwin/bin/cat.exe GNUMKDIR:=C:/raptor/win32/cygwin/bin/mkdir.exe GNUMV:=C:/raptor/win32/cygwin/bin/mv.exe GNURM:=C:/raptor/win32/cygwin/bin/rm.exe GNULN:=C:/raptor/win32/cygwin/bin/ln.exe . . . MODULE:=simple USER_LIBS_PATH_OPTION:=--userlibpath VARIANTPLATFORM:=armv5 PLATFORM:=$(VARIANTPLATFORM) VARIANTTYPE:=urel VERSION:=10.0 VERSIONHEX:=000a0000 VFE_OPTION:=--no_vfe EXPLICITVERSION:= TARGETTYPE:=exe UID1:=1000007a include C:/raptor/lib/flm/e32abiv2exe.flm MAKEFILE_LIST:= # work around potential gnu make stack overflow

In this case, the Raptor FLM in question is C:/raptor/lib/m/e32abiv2exe.m. In

Chapter 3. Implementation

13

this build, 224 variables were set for this FLM. Internally, the FLM consists of a number of Make macros that are evaluated in the context of these variables. These produce the Make rules for a particular executable that is built from the MMP le C:/raptor/test/smoke_suite/test_resources/simple/simple.mmp. The make macros expand to rules to build the specied target. These are written in Bash shell script. For example, here is an extract from $SBS_HOME/lib/m/e32abiv2.m that deal with generating the ARTARGET:
## Link-type selection: # runtime static libraries link via AR ifneq ($(ARTARGET),) # Assuming that there are no libdeps in this case because this is probably one of the # Runtime libraries which has no deps. define artarget_func $(ARTARGET): $(if $(MULTIFILE_ENABLED),$(MULTIFILEOBJECT),$(LINKOBJECTS)) $(STDCPPTAGFILE) $(if $(MULTIFILE_ENABLED),,@echo "$(STDCPPTAGFILE)" > $(VIAFILE); $(call groupin10,$(LINKOBJECTS)) ;) $(call startrule,ar,FORCESUCCESS) \ $(if $(DUMPBCINFO),&& $(FROMELF) -v $$@ > $$@.elfdump,) \ $(call endrule,ar) endef $(eval $(artarget_func)) CLEANTARGETS:=$(CLEANTARGETS) $(VIAFILE) $(if $(DUMPBCINFO),$(ARTARGET).elfdump,) endif

$$(call dblquote,$(AR)) $(ARCHIVER_CREATE_OPTION) $$@ $(if $(MULTIFILE_ENABLED),$(MULTIFILEOBJECT),$(COMMANDFILE_O

The 224 variables set for this FLM are dened by the XML interfaces discussed below.

XML conguration Raptor has two main types of XML conguration les: those
that contain "variants", "groups" and "aliases", and those containing "interfaces". These are dened in various XML les that are located in $SBS_HOME. The "variants", "groups" and "aliases" are dened in the XML les stored in $SBS_HOME/lib/cong, whereas the "interfaces" are alongside their associated FLMs in $SBS_HOME/lib/m. Note that Raptor also reads XML les from $EPOCROOT/epoc32/sbs_cong so

Chapter 3. Implementation

14

that it is possible for some "variants", "groups", "aliases" and "interfaces" to be dened there. XML conguration - Variants, Groups and Aliases Edit "Variants", "groups" and "aliases" are, very roughly, the command line values passed to the -c option and tell Raptor which congurations to build for. For example, sbs -c armv5 c armv5.test builds armv5 production and armv5 test code. These dot-separated strings such as armv5 and test can be either a "group" combined with zero or more "variants", or an "alias" combined with zero or more "variants". "Variants", "groups" and "aliases" are dened as XML tags in Raptors XML les in $SBS_HOME/lib/cong.

3.2

What we have done

3.2.1 Build QEMU

For building QEMU with SBS, Set the environment variables as follows:
export EPOCROOT=~/symbian/gcc/ export SBS_HOME=${EPOCROOT}linux_build/sbsv2/raptor export SBS_GCCE441BIN=~/gcce/bin export PYTHONPATH=${EPOCROOT}sf/adapt/qemu/symbian-qemu-0.9.1-12/qemu-symbian-svp/plugins

. Move to the directory containing python path for building QEMU

cd \textdollar {EPOCROOT}sf/adapt/qemu/symbian-qemu-0.9.1-12/qemu-symbian-svp

Build the QEMU using following command:

\par chmod +x configure ./configure --target-list=arm-softmmu --prefix=${EPOCROOT}sf/adapt/qemu/symbian-qemu-0.9.1-12

The QEMU executable, qemu-system-arm, is created in /symbian/gcc/sf/adapt/QEMU/symbianqemu-0.9.1-12/bin

Chapter 3. Implementation

15

3.2.2 Extract Symbian kernel packages

Extracted the Symbian kernel 7z archives in the /symbian/gcc using the 7z archiver: $for le in *.zip; do 7z x $le; done

3.2.3 Build the GCCE kernel-side runtime library

The kernel-side runtime library is build using Symbian Build System. First the environment variables for the raptor is set using the following commands:
export EPOCROOT=~/symbian/gcc/ export SBS_HOME=~/sbsv2/raptor export SBS_GCCE441BIN=~/gcce/bin

Move to the "compsupp" directory of the kernel for building the runtime library:
cd ${EPOCROOT}sf/os/kernelhwsrv/kernel/eka/compsupp/gcce $SBS_HOME/bin/sbs -c arm.v5.udeb.gcce4_4_1.surge -k

The -c option species the SBS the conguration to be used for building the kernel.

3.2.4 Build the kernel package

The nal stage of building the kernel package. Set the environment variables as:
export EPOCROOT=~/symbian/gcc/ export SBS_HOME=raptor/sbsv2/raptor export SBS_GCCE441BIN=~/gcce/bin

Build the kernel package with following commands.

cd ${EPOCROOT}sf/os/kernelhwsrv SBS\HOME/bin/sbs -s package_definition.xml -c arm.v5.udeb.gcce4_4_1 -k -j 4

The -k options tells the sbs that it should continue compiling even when an error occur. The -j option species the no. of jobs in parallel to be run for utilising multicore processors.

Chapter 3. Implementation

16

3.3

Build the syborg ROM

After building the kernel, syborg ROM image is to be created with SBS.
export EPOCROOT=~/symbian/gcc/ export SBS_HOME=~/sbsv2/raptor export SBS_GCCE441BIN=~/gcce/bin cd ${EPOCROOT}sf/adapt/qemu/baseport/syborg $SBS_HOME/bin/sbs -c arm.v5.udeb.gcce4_4_1

Figure 3.1: Building Syborg ROM image

3.4

Boot the Syborg ROM

Now we have to boot the ROM image with QEMU.

export EPOCROOT=~/symbian/gcc/ export PYTHONPATH=${EPOCROOT}sf/adapt/qemu/symbian-qemu-0.9.1-12/qemu-symbian-svp/plugins cd ${EPOCROOT}sf/adapt/qemu/symbian-qemu-0.9.1-12/bin ./qemu-system-arm -M ${EPOCROOT}sf/adapt/qemu/baseport/syborg/syborg.dtb -kernel ${EPOCROOT}epoc32/rom/syborg_tshell_ARMV5_udeb.img

Chapter 4 Result
Successfully build the Symbian Build System. Successfully built the adapted version of QEMU[Figure 4.1].
We have an adapted version of the QEMU. It share some the extra features not yet available in mainline QEMU. Most noticeable the support for Python peripherals (and binary separation of QEMU and its peripheral) and the skinning support to supply a landing zone for phone specic buttons etc.

Built the kernel packages[Figure 4.2]. ROM image has to be created from these
kernel packages.

Syborg ROM image is build Combining the Syborg base port and the built kernel
packages, the ROM image is built with SBS. ROM image was rst build with error in the tiny code generator[Figure 4.3].

The ROM image is made to boot[Figure 4.5] Finally the Syborg ROM image
thus created is booted up on the QEMU. Resulting in the completion of our mini project. The ROM image was booted for the rst time after working around with some errors in the tiny code generator of QEMU. Tiny code generator produces the target machine[ARM] code. When any key in the keyboard is pressed for a some time in the QEMU window, stack overow occurs in the Symbian OS side.

17

Chapter 4. Result

18

Figure 4.1: Building QEMU. Although Symbian OS was made completely open source by February 2010, by April 5, 2011, Nokia released Symbian under a new license and converted to a proprietary shared-source model as opposed to an open source project. This made the necessary resources required for our project a little tedious. But we were ablle to nd tools and portions of the resources needed for the progress of the project by googling. Main source was the symbian-dump project repository. By the end of this project we were able to study and analyze dierent kinds of tools. Tools those are involved in building the Symbian C++ codes.

Chapter 4. Result

19

The Mercurial, Symbian Build System, FLMs etc are some of them. Also we got an overall view of the Symbian OS structure and virtualization approach of emulator like QEMU.

Chapter 4. Result

20

Figure 4.2: Building the kernel packages

Chapter 4. Result

21

Figure 4.3: ROM image failed booting with errors

Chapter 4. Result

22

Figure 4.4: QEMU booting with Syborg ROM image

Chapter 4. Result

23

Figure 4.5: QEMU booting with Syborg ROM image

Chapter 5 Conclusions
This project is challenging as an undergraduate course project within such short period of time. Symbian OS turning into a Proprietary licenced system from open source made it even worse. But through this project, we came to know about some powerful tools like SBS, Mercurial, etc. Studied and analyzed the Symbian OS and virtualization with QEMU. Symbian supports variety of applications, so virtualizing symbian create a new world for smartphone users.

24

Chapter 6 Reference
Informations about Symbian Build Systems, Syborg Baseport etc was available from the site: http://www.symlab.org http://ebooktest.wikia.com Documentation for QEMU was a useful reference.

25