Beruflich Dokumente
Kultur Dokumente
A Project Report Submitted in partial fulfilment of the requirements for the Degree of
Bachelor of Technology
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
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.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
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
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.
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
2.2
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.
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.
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.
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.
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.
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 3 Implementation
3.1 Tools and Languages used
3.1.1
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.
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
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"
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
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
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
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
Chapter 3. Implementation
15
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.
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
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
3.4
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
Chapter 4. Result
21
Chapter 4. Result
22
Chapter 4. Result
23
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