Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 7
Текст из файла (страница 7)
For example:1. Source-level debugging requires that the object code is stored instandard Windows executable files that the Windows debugger canrecognize and that are loaded via the standard Windows loader2. Debugging multi-threaded software requires that the Windows debugger recognize those threads.
This means that we should implementemulated threads as Windows threads.In the end, we decided to write the EKA2 emulator as a port of the EKA2kernel, rather than trying to make the Symbian OS kernel API work overWin32 APIs. We used Windows as little as possible so as to share themaximum amount of Symbian OS code (and hence behavior) betweenthe emulator and real mobile phones.Indeed, if you look at Figure 1.3 and compare the code that runs ona real device to the code that runs on the Win32 emulator, you willfind a great deal in common.
Both systems contain the same core kernelcode, from the Symbian OS kernel and the nanokernel. At the lower,architecture-specific, levels of the nanokernel, we have an emulated‘‘Win32’’ CPU rather than an ARM CPU or an X86 CPU. This means thatthe emulator is effectively a port to a different processor. For example, theemulator has processes and scheduling that are almost identical to thoseon a real device.16INTRODUCING EKA2Symbian OSKERNELsoftwareremainsthe sameSymbian OSKERNELmemorymodelnanokernelmemorymodelnanokernelARMMMU-specificmemory modelARM CPU-specificnanokernel andkernelemulator-specificmemory modelemulator-specificnanokernel andkernelhardwareSymbian OSWindowsHost OS:WindowsARM processorFigure 1.3Emulator code re-useThe memory model, however, is completely different on the emulatorand a real mobile phone.
On the emulator, it is always the specialemulator memory model, which has knowledge of the different imagefiles that are loaded to create processes. These are standard Win32 PE EXEfiles, and so we satisfy our earlier requirement for source-level debugging.In theory, this approach could make it easier for us to implement anemulator on platforms other than Windows.1.4 SummaryI hope that this chapter has given you a good overview of the history anddesign of the Symbian OS kernel. Next I shall look at Symbian OS as aplatform for real device hardware.2Hardware for Symbian OSby Jason ParkerIf it draws blood, it’s hardware.UnknownThis chapter explores the hardware that Symbian OS is designed to runon: a mobile phone. This is often known as the device platform.
I’llexamine the core hardware that is needed to run Symbian OS, and tryto help you to appreciate the design choices that underlie a world-classSymbian phone. With this knowledge, I hope that you will also gain adeeper insight into the operating environment of Symbian OS.Information on running Symbian OS on the EKA2 emulator, the platform that you will use during development, is placed in context throughoutthe book. The aim of this material is to let you see where you can rely onthe similarities of the emulator to your phone hardware, and where youneed to be aware of the differences.2.1 Inside a Symbian OS phoneSymbian OS phones are designed first and foremost to be good telephones,with quality voice calls and excellent battery life.
On top of that, SymbianOS phones are usually open platforms that provide opportunities forinteresting and novel software. Achieving these goals requires hardwaredesigned specifically for the task, high enough performance in the keyuse cases and an obsession for low power usage.Looking into Symbian OS phone design, there are two complementarycomputing domains, the mobile radio interface of the baseband processor(BP), also known as the modem, and the application processor (AP),which runs the user interface and high-level code, under Symbian OS.Surrounding these domains is a collection of peripherals that make upthe product: battery, display, speakers, SIM card and more.Figure 2.1 depicts a common two-chip solution, where the BP andthe AP are self-contained systems, with a high speed inter-processor18HARDWARE FOR SYMBIAN OS(antenna)LCDBasebandProcessorInter ProcessorCommunication(Modem)ApplicationProcessor(Symbian)1 2 34 5 67 8 9(microphone)SIMPower and audio(loudspeaker)Figure 2.1 A common two-chip solutioncommunication (IPC) link between them.
This is the preferred designfor 3G phones, in which each domain can re-use existing software andhardware sub-systems.The two-domain system of AP and BP isolates each processor from theother’s requirements. The BP requires hard real-time software, periodicpower management and provides security for the network. The APexpects to operate in two modes – full power when a user is interactingwith the phone, and a deep sleep idle when nothing is happening. TheAP code contains the frameworks and libraries for built-in applicationsand third-party code.The overall quality of the product comes from the tight couplingbetween the two domains over the IPC, and their ability to co-ordinatethe shared responsibilities of audio and power.Designing hardware for Symbian OS phones requires a clear understanding of the end-user use cases, the performance requirements thatthese put on the design, and a continual focus on power management.2.1.1Baseband processor (BP)The baseband processor is the voice and data modem for the phone.
Itcontains all the electronics required for the radios used in 2.5G and 3Gtelephony, a DSP to run the algorithms to decode the information, and aCPU to run the call control stack, which co-ordinates with the networkbase stations and communicates with the AP.INSIDE A SYMBIAN OS PHONE19The software on the BP is called the telephony stack, and known asthe stack for short.
The stack is a complex system of code that has grownin step with the evolving telephony standards and their type certificationregimes. A typical stack will contain between 2 and 8 MB of code, andrequire up to 2 MB of working RAM to execute. GSM calls are scheduledto a 4.6 ms time frame, in which all of the call activity needs to have completed before the start of the next frame.
This requires a real-time operatingsystem (RTOS) environment. It is tuned and tested to meet the stringenttiming requirements under worst-case loads of voice and data calls.BP power management is highly optimized for maximum call time andidle time, whilst still being connected to the network. When the phone isidle, the BP can put itself into a deep power-saving mode, only wakingup every two seconds to listen to the paging channel for an incoming callor message.The IPC interface to the AP has evolved from simple serial ports inearly Symbian phones to 10 Mb/s multiplexed links.
This link could usefive bi-directional channels for telephony control, system control, packetdata, streamed data and BP debug.Audio data is routed to and from the BP through a dedicated digitalaudio bus, directly to the audio hardware. This bus provides minimallatency with guaranteed real-time performance and lower power consumption during a call by bypassing the AP. If voice call data was passedover the IPC to the AP, additional buffering would be incurred, a real-timeload would be placed on the AP, and power consumption would go up.The BP controls the SIM card, which contains the secret codes andalgorithms required for network authentication.The two-domain system of AP and BP provides many technicaland engineering benefits, including design re-use, stability and security.
These come at the cost of additional chips, physical size, and overallpower consumption.There are strong financial pressures towards the closer integration ofthe AP and BP domains for mid-tier phones. Example designs range frommultiple cores on one ASIC, sharing memory but little else, up to the fullintegration of the telephony stack and Symbian OS.
In this last case, thetwo co-exist on the same CPU, with all of the software integration issuesthat this incurs.As you can see, baseband processors and their sophisticated telephonystacks are major topics that already fill several books on their own.2.1.2 Application processor (AP)The application processor is at the heart of a Symbian OS phone.Contained on a single piece of silicon, the AP is an example of aSystem-on-Chip.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
