<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-8A00E047-3DCE-5D02-9ECE-1396DC99DA4B" xml:lang="en"><title>Kernel
Architecture 2 Architecture</title><shortdesc>The Kernel Architecture 2 component has a modular architecture
that allows ports of it to be created for different phone hardware architectures.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The parts are: </p>
<ul>
<li id="GUID-C48A58F8-0EE9-5AFB-A855-BDC97AD259E1"><p> <i>Nanokernel</i>:
this handles the most basic thread scheduling, synchronisation and timing
functions. </p> </li>
<li id="GUID-42EFCCA1-C585-5A72-B188-8B6B69B41400"><p> <i>Symbian platform
kernel</i>: this provides the kernel functionality required by Symbian platform
using services provided by the nanokernel. It contains the operating system
objects for such things as threads, processes, chunks, and inter-process communication. </p> </li>
<li id="GUID-290A7566-8CC8-538F-930D-62B85FF73E75"><p> <i>Memory model</i>:
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 OS kernel to be MMU-independent. </p> </li>
<li id="GUID-5324322B-BC5E-5D08-BD9A-DA22EC41CFF4"><p> <i>Variant DLL</i>:
this provides hardware dependent services required by the kernel, for example
timer tick interrupts and Real Time Clock access. Systems based on an ASSP
also have an ASSP DLL, which shares some of the variant DLLs responsibilities.
Board Support Packages provides variant libraries for reference hardware. </p> </li>
<li id="GUID-9B456964-8309-54FA-98C7-757D3A51958F"><p> <i>Extensions and device
drivers</i>: these are used to control peripherals and provide the interface
between peripherals and the rest of Symbian platform. </p> </li>
</ul>
<p>The following diagram shows how the place of the kernel between the low-level
user side code, such as the user library, and the device hardware: </p>
<fig id="GUID-9B3AF7EC-8339-5F92-B4BC-20DD3331F103">
<title>           Kernel architectural relationships          </title>
<image href="GUID-C842C016-0D1B-5462-8B04-49CFE941A964_d0e365435_href.jpg" placement="inline"/>
</fig>
<p>The implementation of these parts is split into code that is hardware independent,
and code that is dependent on the hardware platform. Hardware dependent code
is divided into a number of layers to aid its portability to new hardware.
The diagram below shows how the kernel source is split into four kernel layers: </p>
<ul>
<li id="GUID-6A229A4C-7FF8-55B8-8D1D-8B7AE098C7EE"><p>Independent </p> </li>
<li id="GUID-D60D5310-1A2C-5A1A-BF45-BB0F05DD5AFB"><p>Platform </p> </li>
<li id="GUID-94475D54-07DE-5F99-8A56-9C5EEBA32F5D"><p>Model </p> </li>
<li id="GUID-9B564245-E1CB-5CFC-93EB-E0F257114532"><p>CPU </p> </li>
<li id="GUID-7AB71CB5-5BF6-5F75-9C17-7EB2A9F9E40D"><p>and two peripheral layers:
ASSP and Variant. </p> </li>
</ul>
<fig id="GUID-EBB913A8-1694-5C98-B38B-1387F850CDB4">
<title>           Kernel source layers          </title>
<image href="GUID-A480F734-9EDF-5E29-AC96-039B71B22AC3_d0e365474_href.png" placement="inline"/>
</fig>
<p>The following is a brief description of each layer and its purpose. </p>
<section id="GUID-5317DC8F-56A2-4AF1-889D-D8E6F4925A0B"><title>Layer 1: Independent </title><p>This layer is about 60% of
the total source code. It provides all the basic building blocks of both the
nanokernel and the Symbian platform kernel. </p></section>
<section id="GUID-4ABDF396-D282-4DDE-975F-7AEBBBE4C0E0"><title>Layer 2: Platform </title><p>This layer is concerned with
executable images, whether on the emulator or real hardware. Only the memory
model has code in this layer. It defines two platforms: the windows emulator
and the real Symbian OS hardware. The windows emulator provides a single-process
emulation of Symbian OS using the PC’s Win32 API, for software development:
the Symbian OS hardware starts as a program running Win32 DLLs and threads,
and interfaces with Win32 services rather than hardware and devices. </p><p>Key
differences between the hardware and the emulator are: </p><ul>
<li id="GUID-109C7BE4-93C2-5848-8A4F-61474E240BAC"><p>The emulator runs in
a single process, and Symbian OS processes are emulated within this. This
means there is no memory protection between emulated Symbian OS processes. </p> </li>
<li id="GUID-40B1A70F-1813-50ED-9EA0-9DE4C4067FFB"><p>The emulator file system
maps Z: and C: to subdirectories on the user’s PC, so that programs running
under the emulator do not interfere with the majority of the PC’s file system. </p> </li>
<li id="GUID-6E52C610-8600-520F-9958-185C3BC97294"><p>Delayed function calls
(DFCs) always run immediately on the emulator. </p> </li>
</ul></section>
<section id="GUID-AA29E2F8-D6B2-4C14-B983-3CF340BA17BA"><title>Layer 3: Model </title><p>This layer provides supports for
the organisation of per process memory. Only the memory model has code at
this level. There are three types of memory model supported: </p><ul>
<li id="GUID-38ACBEB0-C5E9-5F6A-BA8F-F6E0BD4EBA90"><p> <i>Moving</i>: a single
page directory is used and page directory entries are moved between the home
and run sections at address space switch time. This is intended for ARMv4
and ARMv5 CPUs. </p> </li>
<li id="GUID-18792718-FE86-566F-A82D-7B090AC48007"><p> <i>Multiple</i>: one
page directory per process. This is intended for ARMv6 CPUs. </p> </li>
<li id="GUID-41AB60A6-4A73-5807-9A1E-A48FAC8EB157"><p> <i>Single</i>: a single
address space for the whole system. This can be used either for MMU-less CPUs
or to allow incremental porting to a new MMU-aware CPU. </p> </li>
</ul></section>
<section id="GUID-AD70D1A5-E777-4FF3-B247-4F2E94C1D3C7"> <title>Layer 4: CPU</title><p>This layer provides code which differs
according to the processor the OS is running on. The nanokernel, memory model
and Symbian platform kernel all have code in this layer. This is the layer
where assembly code belongs. Current possibilities for the CPU layer are X86
(real X86 port to PC hardware), ARM (devices) and Win32 (for the emulator). </p><p>The
nanokernel in this layer contains most of the realisation of the core CPU
architecture, such as the exception/interrupt handling, context-switching
mechanism, etc. It also contains some functionality which is conceptually
part of the independent layer, but has been assembler coded for improved performance,
for instance, DFC handling and timer handling on ARM-based hardware. </p><p>The
bottom layer of the memory model is both CPU-specific as well as specific
to the type of memory model. It presents interfaces used by the lower layers
(ASSP and variant), and by the memory model and independent layer. </p></section>
<section id="GUID-7BA28980-E4B2-4777-AB38-C25DD0B277A3"><title>Layers 5 and 6: ASSP/Variant </title><p>The variant provides
the hardware specific implementation of the control functions expected by
the nanokernel and Symbian platform kernel. </p><p>For some hardware, it may
be appropriate to separate support for a particular ASSP (Application Specific
Standard Product), an off-the-shelf integrated CPU part, so that multiple
variants can be produced using the ASSP. </p></section>
</conbody></concept>