Kernel -Architecture 2 Architecture

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:

- - Kernel architectural relationships - - -

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:

Independent
Platform
Model
CPU
and two peripheral layers: -ASSP and Variant.

- - Kernel source layers - - -

The following is a brief description of each layer and its purpose.

Layer 1: Independent

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.

Layer 2: Platform

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.

Layer 3: Model

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.

Layer 4: 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.

Layers 5 and -6: ASSP/Variant

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.

+ + + + + +Kernel +Architecture 2 ArchitectureThe 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:

+ + Kernel architectural relationships + + +

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:

Independent
Platform
Model
CPU
and two peripheral layers: +ASSP and Variant.

+ + Kernel source layers + + +

The following is a brief description of each layer and its purpose.

Layer 1: Independent

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.

Layer 2: Platform

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.

Layer 3: Model

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.

Layer 4: 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.

Layers 5 and +6: ASSP/Variant

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.

\ No newline at end of file