The Kernel Architecture 2 component has a modular architecture that allows ports of it to be created for different phone hardware architectures.
The parts are:
Nanokernel: this handles the most basic thread scheduling, synchronisation and timing functions.
Symbian platform kernel: 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.
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 platform 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 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 platform.
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:
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:
The following is a brief description of each layer and its purpose.
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.
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 platform hardware. The windows emulator provides a single-process emulation of Symbian platform using the PC’s Win32 API, for software development: the Symbian platform hardware starts as a program running Win32 DLLs and threads, and interfaces with Win32 services rather than hardware and devices.
Key differences between the hardware and the emulator are:
The emulator runs in a single process, and Symbian platform processes are emulated within this. This means there is no memory protection between emulated Symbian platform processes.
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.
Delayed function calls (DFCs) always run immediately on the emulator.
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:
Moving: 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.
Multiple: one page directory per process. This is intended for ARMv6 CPUs.
Single: 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.
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).
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.
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.
The variant provides the hardware specific implementation of the control functions expected by the nanokernel and Symbian platform kernel.
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.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.