Symbian Security Studio: October 2007

Saturday, October 27, 2007

Tracking down memory leaks

Memory management is a key point in embedded development and so it with with Symbian OS which is a lot stricter than other open operating system on this point. While this not a real big issue for a game or utility application (memory while be taken back by the system once you exit the application), it is a crucial for a background running task to avoid these leaks or the user may have to reboot his phone every other day. Note that in any case, having your application leaking some memory will prevent you from obtaining the Symbian Signed certification.

The symptom

The application works fine (well, this point is not mandatory, it may be completely bugged as well ;-) ) on the phone and emulator. But, when running it on the emulator - and only on it - an error message pops-up when you close the application:

This popup window is not really user-friendly but contain useful information: the name of the application and the address of the memory block that has been leaked. In the exemple above, the application name is Armori and the leaked block is at address 0x1416fd04.

Step 1: Get the memory segment

We are now assuming that you use Nokia / Metrowerks Codewarrior (any version / edition will do it) but Microsoft VC++ / .Net user should have all the tools required, only the screenshot will differ.

Put a breakpoint at the beginning of your AppUi ConstructL method (or of the document one if you do significant processing there). Restart your application under the debugger. You should not have modified and recompiled the code or the memory address you got in the popup probably won't be valid anymore. When the debugger stops, note the memory segment that is used by the application. If you are lucky, the memory segmend will be the same than the one you got in the error window. This is the case below where all address are in the form 0x1416yyyy:

Now open a memory window (right-click anywhere in the code window and select View Memory) and enter the memory address we are tracking. In our case, this is obviously 0x1416fd04 but this is not always the case. Here is how you can get the address to track:
take the first four digits from the memory segment (ex: the one from your AppUi instance), here 1416.
take the last four digits from the popup window (here fd04).

During my debugging process, I always had two choices and depending on the execution I had to use indifferently 0x1416fd04 or 0x1772fd04.

After entering the tracked address, the memory window shall only display some uninitialized data as the memory block has not yet been allocated by the app:

If some data is displayed in the memory window then:
you have put the breakpoint too far in the execution, put it at an earlier step of your processing
or you have made an error in the memory segment. Check the address in the memory window.

Step 2: Get the leaked data

Now, let's check what the leaked buffer contains: add a breakpoint at the beginning of your AppUi destructor and make a first run of the application. When you close the app, this breakpoint will be reached and the memory window shall display the leaked block:

I am a lucky guy: the memory dump display the name of a string found in my settings file... [1]

It is now time to put breakpoints to try to find where this block has been allocated. Put some before all the treatments that you have just coded (that's why you should always try to fix a leak when you detect it) and/or various critical points of your application (the ConstructL of most important object is generally a good choice and so are the HandleCommandL and HandleKeyEventL/OfferKeyEventL primitives). In my case, I will just focus on the construction of my application as the settings file is read at the initialisation of the engine.

Restart the application under the debugger (don't forget to modify the address segment to watch in the memory window).

Step 3: Track the execution

We now have to find where the leaked block is allocated. Unless you are working on a very small application, a little bit of time and several runs of the application will be necessary. First, you should do it roughly to indentify during which phase the leak occur: during the creation of a view, during the construction of the engine, when the user request a specific action....

To do so, when you reach a breakpoint, don't try to step into each statement but just step over them and watch the change in the memory window. Nothing should happen until the faulty treament is executed and the allocated block will then appear in red:

In my case, this occured during in a custom XML parser that was used for processing the ini file:

I now know that the processing within the readXMLFile primitive caused the memory leak. I add some breakpoints in other keypoints from this primitive, in my case this will be primitives called parseElement, parseCdata and parseAttribute. I restart the whole process to check which one did allocate the buffer, etc....

Two more runs and I finally spotted the bug, and could fix it :-).

Conclusion

This article briefly introduced you one methodology that can be used to track memory leak. Symbian OS also offers some macros that can be used to track down most simple cases automatically (check Memory Leak Tool) but they cannot always be used when allocated data have to stay through the whole life of the application.

In a general manner, fixing memory leak is a complex and lengthy case. The exemple above may look simple but it is only a short summary of a real life case (one of the worst case actually for tracking leaks, as we just got a big amount of multi-platform code to port on Symbian OS and the leak occured in some callbacks triggered by a loop,etc...). It actually took me about half a day just to identify and correct this leak. So, if you spot a leak in the code you write, just fix it immediately. You will have to do this anyway and the sooner you do it the less time you will need as the leak probably occured in something you just modified.

It also may be worth reading the How to track down memory leaks document published by Forum Nokia which present some further details on the Step 1, to get the memory segment used by the application.

[1] Note that in the first memory view, the memory was filled with 0xAF bytes (meaning memory not allocated) and that most of the memory is now 0xDE bytes (memory has been correctly deallocated).

Attachment	Size
MemLeak-Code1.png	14.94 KB

> Tracking down memory leaks

On January 12th, 2006 alh (not verified) said:

Another good tip, if the memory adress is this predictable, is to at the destructor breakpoint, typecast the memory address to a CBase* in your debugger watch window.

Add a watch: (CBase*)(0x1428f900)

And, if the orphaned cell is a subclass of type CBase, you will be able to unfold it in the watch window, and see its real type.

> Tracking down memory leaks

On January 21st, 2006 Anonymous said:

Hi Eric,

Indeed a good article, only one thing in mind.

When i access the internet (wap etc..) through "Services" on the emulator it gives alloc error on exit.

Similarly any app that accesses the internet gives alloc errors on exit on the emulator (but not on device).

Why so?

And can something be done abt such apps regarding coding so that that alloc does not come up?

Thanks.

> Tracking down memory leaks

On January 27th, 2006 Anonymous said:

Symbian Hooklogger should do the trick?

http://www.symbian.com/developer/downloads/tools.html#HookLogger

Tracking down memory leaks

On May 25th, 2007 kavita said:

Its very nice way of finding out memory leak... but i am facing some problem.

I found that leak is occuring at 0x372B0244 this address and i found that the module with memory block of same address

I did "view memory" and typed 0x372B0244 address....by putting breakpoint at all possible places...and it did not display any msg instead it showed ...i... @ ...
Nothing came in red color...

How can i find out leak...
pls tell me if u have some more tips or logics...

Thanks

Labels: Symbian Tracking down memory leaks

Thursday, October 25, 2007

Symbian OS的硬件——音频 -

Symbian OS电话里的音频子系统主要包含两种独立的音频数据流。一种是电话声音数据，另一种是多媒体数据。

电话里这两种至关重要的用例要求有良好的音质和长时间通话的能力。专用于声音数据的数字音频总线用来保证这些需求。

在Symbian OS电话上实际使用的原始硬件音频格式是16位的脉冲编码调制(pulse code modulated, PCM)数据。声音的质量范围介于通话时的单声道8kHz和音乐播放时的立体声48kHz之间。

PCM音频硬件可以很简单，只要求很少的设置以保证音量和选择正确的输出路径。然后所要做的全部工作把数据按照所要求的速率填充到硬件——DMA硬件很便于完成这种任务。如果数据传输发生了延迟，音频硬件将立即产生抖动、重叠不连续等现象。

2.9.1 电话音频
电话声音数据在通话中是最基本的元素。在解决因长距离的卫星传输所产生的滞后问题而让用户有高质量通话的基础上，在声音延迟上还有严格的限制。为了保证做到这点，系统设计者为通话期间的低延迟响应和低电量消耗而优化了控制软件和硬件路径。

BP包含不通过Symbian OS执行声音频带音频处理的DSP。通话期间，Symbian OS将运行于低电模式，只是在显示器需要更新时才被唤醒。

正常的通话将在模拟音频电路中结束。这个电路里包含从模拟到数字和从数字到模拟的转换器，这种转换器被连接到麦克风和扬声器。使用蓝牙(BT)耳机时，PCM数据通过蓝牙耳机自己的专用接口被直接传输到BT模块中。

Symbian OS需要额外的音频路径以把系统声音融合到正在进行中的通话音里。这是为了处理诸如短信提示音、低电和第二个来电等事情。传递通过IPC连接到BP发送的原始音频数据，就可以完成这种声音的融合，在BP里，DSP将系统声音混合进音频流里。

2.9.2 多媒体音频
系统里除语音数据之外而产生的声音中，多媒体音频是很普通的一个部分。主要的多媒体声音有：

• 具有多种格式的铃声

• 提示来短信的警告

• 闹钟和日程表产生的提示

• 视频电话

• MP3播放

• 录音机记录的声音

• 视频的收集和播放

在系统的高层，由Symbian多媒体框架(MMF)进行控制，以支持媒体播放器、文件格式和插件。

多媒体设备框架(Multimedia Device Framework, MDF)将包含多媒体数字信号编解码器，多媒体数字信号编解码器将在PCM数据与设备驱动层的DevSound之间提供传输服务。

视频电话(Video telephony, VT)是个特殊的例子，因为这种情况下的实时音频数据不通过Symbian OS传输。电话中的音频部分将与视频一起形成64kb/s的数据流。VT电话系统必须分离到达的数据流，解码音频和视频部分，然后同步地进行播放。这项工作由专用硬件或者DSP来完成，它需要全部的200MHz ARM CPU以运行多媒体数字信号编解码器。

音频系统的主要复杂性是音频源和接收器数量的不断增长，以及它们可能被连接的方式。比如，目前的电话有多媒体耳机、扬声器、蓝牙和调频收音机。如果硬件不能混合并路由所有可能组合中的每一个音频源，就有可能产生问题。现在的一些音频用例还不能相互兼容，而是要求相互中断。

Symbian OS的硬件——液晶显示器(LCD)

Symbian OS电话的主要显示器是彩色的液晶显示器。显示器的工作是把流缓冲里的像素转化为我们可以看见的图像。

根据屏幕的大小进行了优化后，Symbian电话的显示器根据用户接口软件层有几种普通的尺寸。最普通的方案是用于Series 60电话上的176×208像素和用于UiQ上的240×320像素。

流缓冲是连续的物理内存上的一块区域，它足够大，以包含和最终要显示的数据同样大小的一串像素。

在初始化期间，基端口为流缓冲保留内存空间并保证MMU用写通缓存(write-through)对它进行映射。16bpp QVGA显示器上的流缓冲将需要160KB(320×240×2)的RAM.

依赖于所存储的容器，像素有几种常见的格式。当前大部分移动电话使用的是565格式，这种格式上每个像素是16个比特位。所谓的565格式，即16个比特位的头5位表示红色，中间6位表示绿色，后五位表示蓝色——提供了65,535种(216)唯一的颜色：

15 → 11 10 → 5 4 → 0

RED GREEN BLUE

使用完全18-bpp显示器的电话开始普遍起来，它们显示262,144色。Symbian OS不支持18位的字，而是在32位的字里使用24-bpp表示法。有一种aRGB 8888格式，这里的a是空值或者是一个alpha值。在这种格式里，LCD控制器会丢弃每个颜色字节的后两个比特位：

31 → 24 23 → 16 15 → 8 7→0

alpha RED GREEN BLUE

移动电话显示器有两种截然不同的类型，即无声的和只能的。无声显示器不包含任何控制电子器件，它的像素由SoC上的LCD控制器直接驱动。而智能显示器包含自己的LCD控制器、用于流缓冲的存储器和回接到SoC的中速带宽接口。

每秒钟内，SoC里的无声显示器控制器必须把显示器映像的新拷贝输出60次左右，以维持LCD上的图像。

只要显示器是开着的，60Hz的更新要求控制器不断地使用DMA从内存中传输数据。使用IRAM作为流缓冲有助于减少电量消耗和显示器的带宽代价。就像我前面所说的，60Hz更新速率的16位QVGA每秒需要8.78MB数据，展望未来，全32位VGA显示器需要的数据将是这个数字的八倍。

智能显示器的接口在两方面进行了优化：当局部发生变更时，增加了对显示器的更新；当多媒体视频或游戏有要求时，提供全带宽操作。对于局部更新，要更新的屏幕区域使用智能2D DMA引擎传输进显示器接口里。

通过移除大部分时候都会发生的全带宽更新需求，智能显示器节省了电量。它们的内部电路也为了正确地匹配显示器特性而进行了优化。对于空闲时只想显示时钟的电话，智能显示器也有额外的低电模式。这时候只要求局部的显示器刷新以及显示有限的色彩。

Symbian OS的硬件——直接存储器访问(DMA)

DMA被Symbian OS用来减轻高带宽存储器到外设的数据传输上的负担，从而允许CPU去执行其他的任务。对于给定的外设，DMA可以减少1%的中断负担，节省电源并增加了外设接口的实时健壮性。

在第十三章，外设支持，将描述支持DMA的EKA2软件框架是怎样和不同的DMA硬件及设备驱动一起被使用的。

DMA引擎是总线管理者外设，它可以被编程以在外设和存储器之间移动大量的数据，并且不需要CPU的干涉。

多通道DMA引擎可以一次处理一个以上的数据传输。有多少个需要DMA的外设端口，Symbian电话的SoC就应该有多少个通道，一个额外的以支持存储器到存储器的数据拷贝的通道也是有用的。

DMA通道传输可以通过对控制寄存器进行编程来启动，控制寄存器带有设定命令、传输大小、目标RAM的物理地址和先入先出外设等信息。传输的数据将是由外设接口控制的硬件数据流，而外设总是慢于系统RAM。

在从存储器到外设的传输中，DMA引擎会一直等待，直到外设发出已准备好接收数据的信号。引擎随后将往DMA内部缓冲读进一批数据，通常是8、16或32字节，然后再把数据写入到先入先出外设。在一批数据全部传输完成之后，会产生一个完成中断，通道则将增加读地址以为下一批数据传输做好准备。

在每次传输的最后产生中断的DMA引擎是单缓冲的。CPU必须处理这个中断，并在有数据溢出之前把下一个DMA传输进行重新排队。音频接口有一个由它的FIFO深度和功耗率决定的实时响应窗口。DMA 中断服务程序(ISR)必须在这个时间内完成，以避免数据下溢。比如，对于16位立体声音频，这个时间可能是160μs.

引擎可以在多个通道寄存器之间进行切换，在当前的传输正在进行的时候，通过这些通道寄存器的一个复制装置，双缓冲DMA引擎允许框架排队等候下一个传输。双缓冲使实时响应窗口的时间增加到和一次完整传输的持续期一样长，比如，对于一个4KB的音频传输缓冲，时间大约是20ms.

集散(scatter-gather)DMA引擎增加了另一个精巧并具有可编程性的层。DMA命令列表被汇编进RAM里，随后通道通过把第一个命令加载进引擎获知去处理这个表。在每个传输的末尾，DMA引擎将加载下一个命令——直到它处理完了所有的命令。当DMA在处理的时候，新的命令可能被添加或更新进列表里，所有理论上我们的音频传输的模型是永远不应该停止运行的。

集散引擎有利于把数据传输进RAM由页表(fragmented pages)组成的虚拟存储器系统里。也有利于复杂的外设交互，在这些交互里，需要通过读寄存器把读数据的操作分散开。NAND控制器要求512字节的数据，以及随后的16字节元数据和为每个进入的块读取ECC寄存器。

通过使用DMA，节省了电量，因为CPU在传输数据期间可以是空闲的，DMA操作不要求中断或指令以传输数据，而且DMA引擎可以根据外设和存储器系统的性能特性进行调节。

Wednesday, October 24, 2007

Symbian OS的硬件——片上系统System-on-Chip(SoC)_缓存

2.2.5 缓存
每个Symbian 电话上使用的CPU都要求有缓存以获得最优性能。缓存的工作是通过持有最近被访问的数据和指令的本地拷贝，把快速的CPU和慢速的内存系统进行隔离。

ARM CPU具有Harvard结构，它有单独的指令和数据端口，相应地就有单独的指令缓存和数据缓存(ICache，DCache)。

缓存借助执行代码重复的本地特征工作。在一个循环里的代码将执行同样的指令，并访问同样的或是类似的数据结构。只要CPU的视图在内存里一致，它不关心数据位于何处——是在RAM里，还是在缓存里。然而，内核不缓存内存映射的外设，因为控制软件对读写外设寄存器有严格的顺序要求。

缓存在cache line里被组织起来，cache line通常包含从一个来自于32字节对齐地址的32个字节数据，以及一个存储这个源地址的标签。一个16KB的缓存将包含512条line。

当CPU请求数据，缓存则确认是否有与请求的地址匹配的line。如果有，请求的数据立即被返回——这个被称为高速缓存命中。如果缓存不包含请求的数据，则产生一个高速缓存未命中。之后，从内存系统将有一个cache line去填充请求的数据，而且随后CPU继续执行。为了确保新cache line的空间，旧cache line将被从缓存里回收。

缓存效率通过它的命中率来衡量——即缓存命中次数与总访问次数的比率。在Symbian OS上，ICache的命中率大约是95%，DCache的命中率是90%。

在高命中率的情况下，CPU能够以接近最快的速度运行，而不用受到内存系统的拖累。这对性能，尤其是对电池寿命来说，都是很美妙的，因为相对于外部内存访问而言，缓存命中只要求很少的电能消耗。

Line填充的操作为内存系统进行了优化，以从内存芯片上吸取顺序发送模式的优点。

一旦MMU被建立起来，缓存也被激活了，它所有的操作将自动执行，而且系统可以更快地运行。EKA2仅需要在缓存必须被擦除时发布缓存控制命令。这可以由以下的某一个原因导致：

● 内存映像在上下文切换时发生了改变

● 新的代码被加载或者现存的代码被丢弃

● 自修改代码的产生

● 从缓存中使用了DMA

2.2.5.1 虚拟和物理缓存
通过MMU和缓存，CPU被从系统总线隔离开，那么，它们的顺序在Symbian OS上就有了冲突(参见图2.3)。

图2.3 虚拟和物理缓存

当CPU被直接连接到缓存，缓存则使用虚拟地址，并且它依次告诉MMU在系统总线上生成物理地址(图2.3的左部)。

一个物理寻址的缓存将被直接连接到系统总线，而且通过真实的物理地址被索引。从虚拟到物理的查询则在MMU侧发生，这种查询位于CPU和缓存之间(图2.3的右部)。

2.2.5.1 ARM v5虚拟缓存
在ARM v5和更早期的系统里，MMU位于CPU和缓存之外，这导致了缓存在MMU的虚拟内存域的内部工作。

在这种设计里，所有存储在缓存里的数据都用虚拟地址进行索引，因而当CPU使用虚拟地址请求数据时，不会为了缓存命中而发出MMU翻译的请求。如果缓存未命中，MMU就被唤起以生成物理总线地址。这种设计减少了MMU的工作量并且节省了电能。

虚拟缓存的不利方面是在每次内核在修改页表时必须清空的部分。内核可以通过丢弃的方式使ICache失效，但它必须把DCache里的脏数据清空到内存系统里去。

不幸的是，当执行线程内上下文转换时，Symbian OS移动内存模型要修改虚拟地址映像。这意味着可能要消耗掉很多毫秒的缓存清空是必需的，这就导致了系统性能上的重大损失。在7.2.1节，会看到Symbian OS使用独特的被调用固定进程来减小这种缓存清空。

2.2.5.3 ARM v6物理缓存
ARM结构的第六版引入了全新的MMU，它有新的页表布局、物理缓存、进程应用空间标识符(ASID)，并支持2级缓存和IO内存空间。

ARM v6的CPU，比如在1136上，总是在缓存上使用物理地址。这就要求MMU更好地工作以执行每个来自于CPU核心的从虚拟地址到物理地址的查询请求。这项工作通常借助TLB查询。

这种方案的优点在于缓存与物理内存映像是一直同步的，而与虚拟映像的变化无关。该方案还在上下文切换的过程中避免了缓存清空。

为了更好地提升性能，v6 MMU模型引入了应用空间标识符，被称为ASIDs。每个ASID有自己的4KB或8KB PDE，以供地址空间底部的1GB或2GB使用。改变ASID将立刻换出这个地址空间。

就如我将在7.4.2节所解释的，EKA2为每个它创建的进程分配了一个ASID，这导致了更快的上下文切换。

2.2.5.4 指令缓存(ICache)
ICache包含最近被执行的指令，以备它们被复用。ICache里的指令不能被修改，因而可以认为它是只读设备。

当发生缓存未命中，一个line需要被回收的时候，它马上被新的指令重写。这是允许的，虽然它是只读的而且不能修改。在从系统中取下代码的时候，为了保证派生码或自修改码的一致，缓存清空操作是唯一必须的。

为 THUMB指令集编译的代码有一个优势，那就是在ICache上可以适应两倍于ARM的指令。这有助于弥补它在稍慢的性能方面的劣势。

2.2.5.5 数据缓存(DCache)
当CPU在读数据时，DCache以与ICache一样的方式工作。在缓存里命中的数据被马上返回，而未命中的数据则将从主存上取得，并取代最近被清空line。

数据相关的复杂性被写进了DCache和把它返回给内存的联合策略中。

对于write-through模式的缓存，每次CPU写数据，它都将通过write buffer马上被写出到内存，如果有命中数据则更新缓冲过的拷贝。

write-through缓存保证了内存总是与缓存保持一致。Cache line回收和缓存清空操作不需要往内存回写任何数据，但要允许可以在任何时候丢弃line。

不利方面是系统总线必须支持CPU全速写数据，而且缓存只在读的时候才有效。

Symbian OS为LCD frame buffer使用write-through caching，以保证在显示器上有稳定的像素。因为有了write buffer，写入新像素数据将稍稍获得速度上的提升，而且read–modify–write操作在缓存的作用下将是半自动的。但是，把整个Symbian OS都在write-through cached系统上运行，性能要降低30%以上。

为了在读写时完全利用DCache，Symbian OS使用了一种称为copy-back的方案。命中了的写操作保留在缓存里，在缓存里它们有可能被再次重写。通过在回收的时候才写一次数据，Copy-back大大减少了写操作产生的负担。

被修改的Cache line用dirty bit进行标记，通常两个dirty bit用于一对half line。在回收cache line的时候读取dirty bit的值，被标记了的half line要通过write buffer写回内存。half line用于减少未修改的数据产生写操作，因为未被修改的数据可以被忽略。

清除copy-back缓存上的全部内容需要消耗一些时间，这是因为这些内容可能都已经被修改。

Symbian OS的硬件——闪存(Flash memory) -

Symbian 电话使用闪存作为它们存储系统代码和用户数据的主要场所。闪存是可编程可电子擦除的硅基非易失性存储介质。

闪存的使用是通过与它的物理操作进行绑定实现的。单独的比特位只能从1态转化为0态。将一个比特位存为1态要求擦除整个闪存块或闪存片段，通常是64KB。往一个0态的比特位写入不会产生任何结果。

闪存有两种主要的类型：

闪存有两种主要的类型：NOR和NAND。这个名字涉及到它们基本的硅栅设计。通过文件系统的选择，这两种闪存类型在Symbian OS电话里都得到很好的利用。第九章，文件服务器，将讨论文件系统更多的细节。

内嵌系统代码和应用对于Symbian应用程序来说就是一个很大的只读驱动器，被称为Z:盘。这个复合的文件系统是由芯片内执行(XIP, execute in place)代码和在要求时从只读文件系统(ROFS，Read Only File System)加载的代码构成。Z:盘有时候被称为ROM映像。

用户数据和安装的应用程序位于内部的可写的C：盘上。C：盘用两种不同的文件系统中的一种实现，这两种文件系统是：用于NOR的LFFS (Flash Translation Layer)或者NAND顶部的闪存转换层(FTL)之上的标准FAT文件系统。

当今典型的Symbian电话为代码和用户数据使用32或64MB的闪存——这是全部的ROM预算。

Symbian使用很多技术以减小电话内代码和数据的大小，比如THUMB指令集、预连接XIP映像、压缩的可执行包、强调减少代码大小的压缩数据格式和编码规范等。

2.4.1 NOR闪存
NOR闪存用于存储由CPU直接运行的XIP代码，它被连接到SoC上静态的内存总线上，可以像RAM一样随机寻址。如果闪存定位于0物理地址，即0x00000000，那么ARM CPU可以从NOR Flash直接启动。

对于用户数据，Symbian使用了NOR闪存顶部的LFFS(Log Flash File System)。这个文件系统被优化了，以获得NOR 闪存的特性中的优点。在第九章文件系统里，我描述了LFFS的细节。

NOR闪存允许无限次地写入同样的数据块，将比特位的1态转化为0态。为了增加速度，闪存经常有一个32到64字节的写缓冲，这些缓冲允许并行地写入一些字节。带缓冲的写操作需要耗时50到600微秒，这个时间取决于闪存中已有数据及要写入的数据的位模式。全0或全1是最快的，类似于0xA5A5这样的模式就是慢速的了。

擦除NOR片的操作是慢速的，需要半秒钟一秒的时间。但是擦除过程可以被挂起并在稍后被重新启动——LFFS使用这个特色在后台执行要删除数据的清除，同时处理前台请求的响应。

完整的写和擦除操作将更新闪存内的状态寄存器，也可能产生一个外部中断。如果没有外部中断，CPU将需要使用高速定时器，以向闪存查询完成事件。

通过使用有边读边写(Read–While–Write)能力的NOR闪存，建造一个包含XIP代码和LFFS数据的NOR部件的Symbian OS电话是可能的。

2.4.2 NAND闪存
NAND闪存被看作是基于块的磁盘，而不是随机可寻址的内存。与NOR不同，它没有任何地址线，因此在内存映像中是不可见的。这就意味着代码不能直接从NAND执行，而是必须先拷贝到RAM里。相对于NOR设备而言，这使得在NAND电话中需要额外的RAM。NAND闪存的写速度大约比NOR闪存快10倍。

电话不能直接从NAND启动。这种情况下，进程要求一系列相互依赖的启动装载器，因而更复杂了，最终ROM上一些兆字节的核心Symbian OS映像被装载进RAM，这些映像将在这里执行。

NAND也先天地没有NOR可靠。坏块的产生会使操作中的比特位受到影响。为了减轻这种影响，在每页数据设计了错误校验码(Error Correction Code，ECC)，通常是512字节。每次读的时候，ECC被重新计算，它和当前存储的ECC值之间的差异被用来修正运行时的单个位错误。多个位错误不能被发现，这个页就会被认为是坏页。

相对于NOR，即使是考虑到额外必需的RAM，NAND的低价使它对庞大的电话市场很有吸引力。

NAND闪存部件使用专用接口被绑定到SoC上，这种接口通过8位或16位总线直接连接到NAND芯片的引脚。接口块包含计算读写ECC的电路，它为数据传输使用DMA接口。

NAND接口使用数据页往NAND闪存里读写数据。小块NAND设备使用512字节的页，而大块设备使用2048字节的页。数据以块进行擦除，块将包含32或64个页。

Symbian OS的硬件——随机存储器 (RAM) -

RAM是系统内所有活动数据的根据地，而且正在执行的代码通常也是在RAM上。RAM的品质决定了你同步运行的应用程序的类型和数量，RAM的访问数度也影响着它们的性能。

一个Symbian OS电话会有8或64MB的RAM。OS本身需要适量的RAM，而总的需求则由预期的用例决定。多媒体需要在百万像素的摄像机和视频记录上大量的RAM。如果使用了NAND闪存，兆字节的代码必须被拷贝进RAM里，这不像在适当的地方执行的NOR闪存。

RAM芯片在电话总成本中是很重要的一个部分，这既体现在金钱上，也体现在用来维持它的状态所消耗的额外的电能上。

不仅仅CPU向存储子系统提交很高的要求，所有的主要外设总线都要从RAM读写数据。它们的要求和相互的竞争在设计期间都要考虑到。设计出考虑了带宽和延时实际用例，必须了解提交到存储系统的要求。

2.3.1 移动同步动态随机存储器（Mobile SDRAM）
最近几年，内存厂商们已经开始专门为移动电话市场生产RAM，称之为LOW POWER或Mobile SDRAM.

这种内存已经为低电耗的要求和100MHz左右的低速接口进行了优化，普通PC上接口的速度是它的四倍。

移动内存有另外的特性以帮助维护电池生命。关闭电源模式可以允许内存控制器在不需要外部控制电路的情况下禁用RAM部分。

DRAM内的数据必须被周期性的更新以维护它的状态。空闲时，DRAM使用自刷新电路来完成这个工作。Temperature Compensated Self Refresh(TCSR)和Partial Array Self Refresh(PASR)被用来减少空闲时的电能消耗。TCSR和PASR的结合可以将监视电流从150减少到115μA.

2.3.2 内部RAM(IRAM)
嵌入到SoC内的内存被称为内部RAM，它比主存小得多。

从NAND Flash引导系统的时候，核心装载器代码从NAND的第一个块被拷贝到RAM。对于这些代码来说，IRAM以其简单的启动过程而成为理想的目标。一旦核心装载器从IRAM上开始运行，它将初始化主RAM，以使核心OS映像可以被解压并拷贝到主RAM上。

IRAM可以作为一个内部流缓冲器使用。LCD控制器驱动非智能显示器每秒需要重复读取整个流缓冲器60次。因此，16位QVGA显示器每秒需要8.78MB数据。通过把流缓冲器移进IRAM里，系统可以节省大量电能和主存带宽。专用的IRAM流缓冲器可以为LCD访问做进一步的优化以减少电能的需求。

IRAM作为SoC上多个处理间的草稿本或者消息箱也是很有用的。

要注意把少量代码放进IRAM里不会提升这些代码的执行速度，因为ICache已经在更快更好地做这项工作。

Symbian OS的硬件——片上系统System-on-Chip(SoC)_ARM、内存管理单元(MMU) - Welcome to My Blog - CSDNBlog

2.2.3 ARM
ARM已经进行了20多年基于RISC的CPU，并且成功地授权世界上所有的半导体厂商把它包含进他们自己的SoCs里去。Intel已经授权了第五版的ARM体系结构以建造软件兼容的XScale微处理器。

随着ARM连续开发了几代CPU，他们添加进了一些新的指令和特性，也剥离一些很少用到的旧特性。带有额外字母的ARM结构版本号，定义了特性集和指令集，以及MMU的操作，缓存和调试。

Symbian OS要求CPU支持ARM v5TE或更高的版本。ARM v5TE是所有Symbian软件的基线指令集。为了保证在多种电话上的兼容性，应用程序代码必须使用ARM v5TE指令。(目前的EKA1电话使用ARM v4T结构。)

ARM v5TE意味着什么呢？它是具有THUMB指令集和加强DSP指令集的ARM结构的第五版。ARM v5TE指令集的定义可以在ARM Architecture Reference Manual²中找到。

²ARM Architecture Reference Manual, 2nd edn by David Seal. Addison-Wesley Professional.

ARM核心和当前与Symbian OS电话工程兼容的SoCs包括：

Core Architecture SoC

ARM926 v5TE Philips Nexperia PNX4008

ARM926 v5TE Texas Instruments OMAP 1623

Xscale v5TE Intel XScale PXA260

ARM1136 v6 Texas Instruments OMAP 2420

THUMB是在v4T结构中被引进的。它是ARM指令集的16位子集，被设计出来以解决全32位指令的恶劣代码密度的共同RISC问题。通过使用16位解码方案，THUMB编译的代码大约只相当于ARM的70%，但它只需要另外25%的代码去完成这项工作。使用BLX指令进行模式转换，THUMB和ARM代码可以在同一个系统上相互作用。

Symbian OS上大部分的代码都是作为THUMB编译的，这是因为ROM的大小与Symbian OS电话的成本密切相关。内核是为ARM构筑的，以提升性能，而且它还要求一些THUMB中没有包含的指令，比如用来访问MMU和CPU状态控制寄存器的协处理器指令。应用程序的代码也可以通过把ALWAYLS_BUILD_AS_ARM添加到应用程序的MMP文件中而为ARM构筑。Symbian为算法的代码作这些工作，因此，比如为ARM编译的JPEG解码器运行速度要提高30%。

增强的DSP指令使得更高效的16位信号处理算法的实现可以使用一个ARM CPU。这些指令并不会在普通的模块代码中被使用，而且在Symbian OS上执行时几乎不会产生冲突。

2.2.4 内存管理单元(MMU)
Symbian OS在开放OS之内要求一个完整的内存管理单元协调和强制执行对虚拟内存的使用。我在第七章，内存模型，讨论MMU的使用。

MMU位于CPU和系统总线之间，它把软件使用的虚拟地址转换为硬件所能理解的物理地址。在每次内存访问的时候，这种查找必须发生。

MMU把扁平且连续的物理内存分割为页面，通常这些页面都很小，只有4KB，虽然也有更大的64KB的页和1MB的片段(section)。

Symbian OS虚拟内存表把分散的物理内存页重新排列到清晰有序的虚拟内存空间。重排信息通过使用页表被压缩到MMU里。页表是一种层次形的数据，它以一种稀疏的风格编码整个4GB的虚拟地址空间。在ARM系统上，页表有两个层次，即页目录和页表。

在相似情况下，当一个物理地址由总线控制器解码，一个虚拟地址之内的位域被MMU解码到内存页里去，会被解码为页目录、页表和索引。7.2.1节解释了这部分的细节。

位 31->20 19->12 11->0
地址解码头12位映像到页目录中间8位映像到页表底部12位是页内的偏移量

虚拟地址编码为小的页

每次内存访问MMU都要执行从虚拟地址到物理地址的查找，以取得总线地址并验证页操作的合法性。根据虚拟地址查找物理地址的过程称为“走读(walking)”页表。这一过程需要花费一些时间访问两次内存，即读取页目录和紧随其后的读取页表。

为了增加地址翻译的速度，最新的MMU缓存在一个翻译后援缓冲器(Translation Look-aside Buffer, TLB)里查找结果。如果在TLB里找不到从虚拟到物理的查找，MMU会使走读表的硬件执行一次新的虚拟查找，而且它会把结果存储到一个TLB条目里。

如果页表发生了改变，TLB也必须被清空。在上下文转换、调试期或上传代码的时候，会发生这种情况。

启动时，CPU将使用物理地址运行，并且引导代码会构筑页表的初始化设置。当MMU开始工作了，CPU会切换到虚拟内存操作，并为内核引导的时序作准备。

Symbian OS的硬件——片上系统System-on-Chip(SoC)_物理内存映像、中央处理单元(CPU) - Welcome to

SoCs还有另外两个称呼：针对定制芯片的专用集成电路ASICs (Application-specific Integrated Circuits)和针对商业领域的专用半导体部分ASSP(Application-specific Semiconductor Parts)。所有的这三个术语都不是很精确，而且可以被相互取代。所有主要的硅片公司都设计制造了SoCs：Texas Instruments有一个称为OMAP的产品家族，Intel也有他们自己的XScale系列处理器。图2.2显示了一个典型的System-on-Chip设计。

图2.2 片上系统

SoC里面的每个子组件都是一个智能性能(IP)块，这些块通过工业的标准接口连接到互联总线。IP块可以通过很多途径进行授权，最著名的IP授权公司是ARM有限公司，该公司授权ARM CPU核心。

例子所示的SoC是由ARM926 CPU驱动的，可用于Symbian OS和多媒体数字信号编解码器的DSP。这两个核心都是系统总线上的重要部分，而系统总线是高速低延迟的32位总线，它被连接到DRAM控制器。系统总线和存储控制器把所有的数据访问都集中到主存里，所以它们必须被设计成能提供高带宽和低延迟的传输，以避免过度地拖累CPU或者降低了它高效的性能。

DMA引擎和LCD控制器是另外的重要总线，它们都通过同样的总线访问存储器。其他的外设被称为从属总线——它们不能直接访问存储器，而是通过它们的主总线以命令和数据的形式来满足它们的要求。这些从属块被串联成两个外设总线，一个用于高速DMA设备，另一个用于简单的低带宽外设。

外设总线通过总线桥被连接到系统总线。因为外设总线通常运行速度慢于系统总线，因此必须由总线桥翻译不同的总线格式并平衡速度差。良好的SoC设计会关注这些桥以保证CPU可以快速地访问关键的时控或高带宽外设。

Steve Furber的ARM System-on-Chip Architecture ¹ 一书里有更多关于ARM SoCs的信息。

2.2.1 物理内存映像
总线和它们的连接决定芯片的物理地址映像——32位编址就有4GB的寻址空间。对于软件，Symbian OS使用CPU的内存管理单元(MMU)把芯片地址空间布局的实体重映像到相应的虚拟地址空间上。

例如，系统总线控制器会把4GB的SoC地址空间划分成一些大的区域。只需解码首部的三位，就可以产生八块区域，每个区域有512MB空间大小：

随后，这些大区域会被进一步划分成更小的区域。

对于安装在DRAM Bank0上32MB的RAM，如果25到28地址位没有被硬件解码，

剩下的480MB地址空间会包含RAM上的内容的别名，通常会是这样：

外设总线区域由外设进行进一步的划分。上述例子中SoC上的每个快速外设都为它们的寄存器组提供有64KB的地址。

实际上，每种ASSP都有不同的物理地址空间，而且大部分不会被使用，往不使用的空间上读写会导致一个总线错误。

一个良好的设计里，所有重要总线角色都要有相应的内存映像，消除翻译物理地址的需求，并且减少发生错误的可能性。

通常，CPU会访问系统中的所有外设，然而其他重要角色只拥有其从属角色的可见性。LCD控制器需要从内存中取得流数据，直接内存存储引擎则在快速外设和内存之间工作。

引导代码使用物理地址映像设置MMU，直接内存存储引擎和其他重要总线角色不包含它们自己的MMU。它们只理解物理地址，而且在这些设备上编码的软件必须在使用之前把虚拟地址翻译回它们的物理地址。

2.2.2 中央处理单元(CPU)
Symbian OS要求有一个具有高性能和低电耗的32位微处理器。它必须采用Little-Endian模式，有完整的MMU，用户和管理者模式，以及有中断和异常机制。ARM的设计很精确地符合这些要求，当写作本书的时候，所有的Symbian OS电话都有一个基于ARM的CPU，世界上80%的移动电话也采用这种CPU。

下面依次来看看这些需求：

高性能是一个与电池供能设备相关的术语。现在的Symbian电话CPU时钟在100到200MHz之间，比起PC上平均3GHz的速度要慢一个数量级，但是它们消耗的能量却少了三个数量级。未来的应用要求CPU的速度峰值能达到300到400MHz。

低电耗是Symbian OS手机上所有组件的设计要求。在设计CPU的时候，要进行工程学上权衡取舍，而且要加进去一些特性以制造出最有能效的核心。精益求精的硬件设计，所选择的电路时钟以及独特的多种低电模式：空闲、休眠、睡眠、深睡眠和退出，换来了电源的节省。在第十五章，电源管理，我将讨论Symbian OS为电源管理所提供的从硬件到软件框架的映像。

基于CPU提供的用户和管理者模式，MMU允许用户内存的虚拟化。EKA2为应用程序构造了一个强大的执行环境，每个应用程序有它自己受保护的内存区，并且与其他的应用程序相隔离。应用程序代码受限制地在用户模式执行，而内核代码使用管理者模式，只受到很少的限制，其中就包括来自它的虚拟内存映像的限制。在第七章，内存模型，我描述了Symbian OS提供的内存模型。

异常是改变核心指令流的CPU事件。中断异常由正在寻求关注的外设抛出。软件中断作为从用户模式到管理者模式的控制转换而被使用。如果代码试图访问没有被映像的内存，MMU将产生一个数据终止。而当CPU跳转到没有被映像的代码地址时，MMU将产生一个预取终止。第六章，中断和异常，有关于中断和异常的更多信息。

Symbian OS的硬件——手机的内部 - Welcome to My Blog - CSDNBlog

本章探讨Symbian OS运行的硬件：移动电话，也就是称为设备平台的东西。我将分析运行Symbian OS所必需的核心硬件，同时希望帮助你认识到造就了世界级Symbian手机的设计方案的卓越性。与此同时，我还希望你将获得对Symbian OS运行环境的深入理解。

在EKA2模拟器上运行Symbian OS的信息，在开发期间将使用的平台，都位于贯穿本书的上下文环境中。这些材料的目的是让你知道模拟器和手机硬件之间的哪些相似性值得信赖，而哪些差异又必须加以区分。

2.1 Symbian OS手机的内部
首先，也是最重要的，Symbian OS手机是一部有良好声音效果和优越的电池寿命的电话。另外，Symbian OS手机通常是一个为有趣新颖的软件提供机会的开放平台。为了达到这个目标，要求有特殊设计的硬件，在关键用例上足够高效的性能以及对低电耗的苛刻要求。

观察Symbian OS手机的设计，可以看到有两个补充的处理区域，即被称为Modem的基带处理器(BP)移动无线电接口，以及在Symbian OS之下运行用户接口和高层代码的应用处理器(AP)。周围的这些区域是组成了手机的一系列外围设备：电池、显示器、扬声器、SIM等等。

图2.1 普通的双芯片方案

图2.1显示了一种普通的双芯片(two-chip)解决方案，这里的BP和AP都是独立的有高速进程间通信(IPC)连接起来的系统。这种方案是3G手机所倾向的，因为它可以重用现存的软件和硬件子系统。

AP和BP组成的双域系统相互隔离了来自对方处理器的需求，BP需要严格的实时软件，周期的能源管理并且提供网络安全。AP希望在两种模式下运行——在用户与手机进行交互时有足够的电源，而没有操作时处于深睡眠静默状态。AP代码包含支持内置应用和第三方代码的框架和库。

Symbian手机整体的品质依赖于通过IPC在两个域之间建立的严格的耦合，以及它们在完成音频和电源方面的任务时协作的能力。

设计Symbian OS手机的硬件要求对终端用户的用例的清晰理解，和这些需求对设计的依赖，以及对电源管理持续自始至终的关注。

2.1.1 基带处理器(BP)
基带处理器是手机中声音和数据的调制解调器。它包含了2.5G和3G电话上使用的无线电通信所需要的所有电子器件，DSP运行解码信息的算法，还有CPU则运行通话控制栈，它还和网络基站协作并且与AP进行通信。

BP上的软件叫做电话栈，简称为栈。栈是一个复杂的代码系统，这些代码随着不断发展的电话标准和它们的类型认证体制也在同步增长。一个典型的栈包含2到8MB代码，并要求多达2MB的可用RAM以支持其执行。GSM通话被规划为一个4.6ms的时间片，在一个时间片里，所有的通话活动在下一个时间片开始之前必须完成。这就要求有实时操作系统环境。它被调谐并测试以满足在最坏的声音和数据通话负载情况下的严格要求。

BP电源管理高效地优化以达到最长的通话时间和空闲时间，并且时时保持与网络的连接。当电话是空闲的时候，BP把自己置于省电模式，仅仅每隔两秒被唤醒去监听寻呼信道，以接收来电和短信。

IPC到AP的接口已经从早期Symbian电话简单的串行端口发展到10Mb/s的多路连接。这种连接可以使用五个双向信道以支持电话控制，系统控制，包数据，流数据和BP调试。

音频数据通过专用数据音频总线被路由到BP或从BP路由出来，直接到达音频硬件。通过绕过AP，这种总线提供通话期间的最小延迟，同时还可保证实时性能和低电耗。如果声音电话数据绕过IPC到达AP，将发生额外的缓冲，AP将面临实时负担，电耗也将增加。

BP控制包含秘密代码和网络认证所要求的算法的SIM卡。

AP和BP组成的双域系统提供了很多技术和工程学优点，包括可重用设计，稳定性和安全性。这些以额外的芯片、物理大小和全面的电源消耗为代价而获得的。

进一步整合中端手机中的AP与BP部分，在经济上存在着巨大压力。在设计实例中，从在一个ASIC上制造出多个核心(它们主要是共享内存资源)，到全面整合电话栈与Symbian操作系统，各种情况应有尽有。在最后一种情况下，电话栈与Symbian操作系统共存于同一CPU上，该情况下会出现许许多多软件整合方面的问题。

大家都知道，基带处理器和它们成熟的电话栈是主要的主题，而且关于它们，可以用几本书来描述。

2.1.2 应用处理器(AP)
应用处理器位于Symbian OS电话的心脏，被包含在一块单独的硅片上的AP是SoC的一个例子。它有一个ARM的CPU，内存，显示器和音频接口，多媒体加速器和很多其他的外设。我将关注这些组件，它们的集成和它们之间怎样互联。

Tuesday, October 23, 2007

Symbian OS Internals——Symbian OS模拟器 - Welcome to My Blog - CSDNBlog

1.3.4.1 设计目标

模拟器有两个主要的用处——开发Symbian OS软件和演示这个软件。

第一个用例对内核服务提出了更多的要求，所以我们专注于什么时候草拟出需求。在最高级别上，它给我们提供模拟器的两个关键需求：

1、它需支持在主机平台上使用标准工具进行开发和调试。

2、它应当尽可能真实地提供Symbian OS在目标硬件上的模拟。

这些需求看上去是有冲突的，因为第一个需求要求使用主机平台(直到现在，基本上还是Windows)里的实体，但它并不以同样的形式存在于“真实的”Symbian OS上，比如：

1、代码级别的调试要求目标代码存储于标准Windows可执行文件里，这些文件可被Windows调试器识别的，而且通过标准Windows装载器导入。

2、调试多线程软件要求Windows调试器识别那些线程，这意味着我们应当把被模拟的线程实现为Windows线程。

最后，我们决定了实现EKA2模拟器，并把它作为EKA2内核的一部分，而没有试图让Symbian OS内核API工作于Win32 APIs之上。我们尽可能少地使用了Windows，以在模拟器和真实的手机之间共享最多的Symbian OS代码和行为。

实际上，看看图1.3，比较运行于真实设备和Win32模拟器上的代码，会发现大量的共同之处。它们都包含同样的核心内核代码，从Symbian OS内核到微内核。在更底层，专用体系结构，即微内核层，我们模拟成“Win32” CPU，而不是ARM CPU或者X86 CPU。这意味着对于不同的处理器来说是一个高效的接口。比如，模拟器有与真实设备上几乎同样的线程和调度。

图1.3 重用模拟器代码

不过，内存模型在模拟器和真实手机上就完全不同了。在模拟器上，它一直是内存模型的特殊形式，它知道在创建进程时要载入的不同的映像文件。这些都是标准的Win32 PE 可执行文件，这就满足了前面的代码级别调试的需求。理论上，这个方法使得我们在Windows上实现模拟比在硬件平台上更简单。

1.4 总结
我希望这章已经给了你Symbian OS内核在设计和历史方面的概览。下面，我应当把Symbian OS作为真实硬件的平台来看一看了。

Symbian OS Internals——设计方案_抢占式内核、微内核、模块性、设计局限

现在，我将谈一谈我们在EKA2中采用的设计方案和它们如何帮助我们实现我们设定的目标。

1.3.3.1多线程抢占式内核

为了减少线程执行期，我们把EKA2设计成多线程的，允许低优先级的内核操作被高优先级的内核操作抢占。

EKA2有五个线程，它们是：

1、Null Thread——空转(idles)CPU，重组(De-fragments)RAM。这个线程也被叫做Idle Thread

2、管理者线程——清理被杀死的线程和进程(killed threads and processes),提供异步对象的删除

3、DFC 线程0——为comms、主板和数字转换器等通用设备驱动运行DFC

4、DFC线程1——运行微内核时钟队列

5、计时器线程——运行Symbian OS的相对和绝对计时器(After(),At())

在第三章，线程、进程和库，我将深入描述这五个线程的目的。

内核多线程的本质也有助于我们达到另一个目标——使设备驱动编写者的工作变得更简单。你常常想从另外的操作系统移植设备驱动，但是EKA1的单线程设备驱动模型意味着移植一个多线程的设备驱动不是一项简单的工作——你往往必须从零开始设计驱动。在EKA2，设备驱动可以利用DFC线程0，或者根据需要创建自己的线程。有了这些机制，在其它操作系统上的设计可以被重用，而且现在移植也更简单了。

1.3.3.2微内核

我们选择了拥有一个独立的微内核，因为这样做有以下优点：

1、非常少而且可预测的中断及线程执行期。这是因为只有微内核可以关闭中断和执行重调度 (有很多关于这方面的异常，但它们在这里不重要)。Symbian OS内核和内存模型的大部分，运行的时候都是开中断而且允许优先权抢占。因为微内核仅提供了一个简单的小片段，我们很容易决定要为了它而关闭中断和进行重调度的那个最长的执行期。

2、更好更简单的模拟。Windows下运行的Symbian OS模拟器有很多和实际设备一样的代码，这意味着这种情况下的模拟比EKA1模拟器上所做到的更真实。

3、支持单核电话。微内核允许在Symbian OS和它的PIM软件之外运行一个RTOS和它的GSM信号栈，1.3.2.4节讲述了这方面的更多细节。

1.3.3.3 模块性

新内核增加的模块性使得把操纵系统移植到新的ASSP更为容易了。大部分的专用处理器代码在微内核上，而且存储器和MMU的差异被限制在内存模型上。

得益于内存模型，利用直接内存模型往新的CPU结构上移植操作系统的前期步骤，以及进行了大量的调试后切换到移动或多态模型等这些工作就很容易。它允许你通过很少很简便的步骤就能移植操作系统。

1.3.3.4 设计上的局限性

设计实时性能在EKA2导致了两个局限性：

1.为了保证确定性的中断执行期，我们不能允许无限数量的中断服务程序绑定到一个中断资源上，而在EKA1中这样做是可能的。现在，一个中断上只绑定一个中断服务程序ISR(interrupt service routines)。

2.为了保证有限的上下文转换次数，我们必须限定一个线程里最多只能有八个块，在EKA1里这个数字是没有限制的。(块是Symbian OS里内存分配的一个基本对象——第七章内存模型将讲述这方面的更多细节。)

有一点很重要，那就是并不是所有的EKA2服务都被限制为实时的，比如：内存的分配和释放就没有这样的限制。第十七章，实时性，将讨论这个问题。

Symbian OS Internals——设备驱动、扩展、EUSER、文件服务器、窗口服务器和软件

1.3.2.7设备驱动

在Symbian OS上，你使用设备驱动控制外设：驱动提供这些外设和Symbian OS其余部分之间的接口。只要愿意，你也可以采用跟分离ASSP和变量相似的方式分离设备驱动，即提供与硬件无关的逻辑设备驱动，和与硬件有关的物理驱动，或者PDD(物理设备驱动器)。

设备驱动可能运行在客户端线程或内核线程：我们新的多线程内核设计使得从其他的操作系统往Symbian OS上移植设备驱动变得更加容易。

Symbian为很多类型的外设提供标准LDD(比如多媒体设备、USB控制器和串行通信设备)，然而，手机厂商通常为定制硬件开发他们自己的接口。

从EKA1到EKA2，设备驱动已经发生了相当大的变化。更多的细节，可以看第12章，驱动和扩展。

1.3.2.8扩展

扩展不过是内核被引导时自动启动的设备驱动，所以可以把它们看成是扩展内核功能的一种方式。比如，崩溃调试器是一个内核扩展，在你需要的时候可以把它包括进ROM或者在不需要的时候把它从ROM中剔除出去，而且你还不需要重新编译内核。

我上面所讨论过的变量和ASSP是都是重要的扩展，在引导进程的初期，内核就载入它们。在载入它们之后，内核继续引导直到最终启动了规划器并执行到管理者线程，管理者线程初始化其它所有的内核扩展。这些晚期被载入的扩展对内核本身的操作来说并非必不可少，但一般都用于执行硬件组件的早期初始化，并且固定地为LCD、DMA、I2C和串行总线控制器等设备提供可用的服务。

最后被初始化的内核扩展是EXSTART，它负责载入文件服务器。在第十六章，引导进程，我将讨论系统引导的更多细节。

1.3.2.9 EUSER

用户库，即EUSER，为它的客户端提供了三种主要的功能：

1、完整地执行用户端的类库方法，比如字符串和描述符类的大部分方法(描述符是字符串的Symbian OS版本)。

2、访问内核函数以请求内核代表用户线程执行特权访问，比如检查时间或者现场设定。

3、访问内核函数以请求内核代表用户线程操纵它自己的内存，比如创建线程或载入一个库。

每个Symbian OS内核都通过EUSER库取得对内核服务的访问。但我们在EKA1和EKA2之间维护的一些接口，导致了对应有的作者产生一些障碍。

1.3.2.10文件服务器

文件服务器是一个允许用户模式线程操纵驱动器、目录和文件的用户模式服务器。第九章，文件服务器，提供了更多的细节。

1.3.2.11窗口服务器

窗口服务器是在所有的Symbian OS应用间共享屏幕、键盘和指示器的用户模式服务器。第十一章窗口服务器，提供了更多的细节。

1.3.2.12软件分层

我们也可以从软件分层的观点来看待Symbian OS的体系结构，见图1.2。

如果你熟悉EKA1，你会发现EKA2的分层与它有点不同。但是，当我们往下看，从代码在所有平台上共享的大部分通用独立层，到大部分专用可变层——它们的代码为特定开发板(development board)或特定手机上的特定ASIC编写，则它们有更多的相似之处。

我们把它上面的四层叫做“内核层”，下面两层叫做“串行层”。后面的这些形式构成手机厂商在把Symbian OS移植到新硬件时所实现的主板支持包的主要部分。它也组成了引导程序、设备驱动和扩展。

图1.2 内核分层

独立层组成了大约60%的内核源代码。它提供了微内核和Symbian OS内核的基本组成，即——微线程、线程、进程、数据块、客户端/服务器等等。这些基类被更低层的类继承，从而为Symbian OS运行于其上的特定硬件提供实现。

平台层参与可执行映像——Symbian OS是运行在模拟器上还是在真实的硬件上，因此，它也有另一个名字，即映像层。只有内存模型在该层上有代码，它提供了两个实现，即用于硬件设备的EPOC和用于模拟器的WIN32。

所有的每进程驻留内存组织管理都在模型层实现，而且，也只有内存模型在这个层次上由代码。内存模型提供了四种不同的实现——Moving，Multiple，Direct，Emulator。第七章，内存模型，将深入讨论这四个问题。

根据Symbian OS所运行的处理器，CPU层有不同的代码；这部分属于汇编代码。微内核、内存模型和Symbian OS内核都在这个层上有代码。在写代码的时候，Symbian提供三种可能的CPU层——X86(到PC硬件的端口)，ARM(手机)和Win32(用于模拟器)。

内存模型的CPU层有专用CPU和MMU的代码以及专用的内存模型代码，这些代码对内存模型的类型也是专用的。微内核的CPU层包含了核心CPU结构的大部分知识——异常和中断怎样被捕获，哪一个寄存器需要被保存到上下文转换环境里等等。Symbian OS内核的CPU层上的一部分代码是独立层机能，它被编成汇编代码以改善性能。

变量层提供了微内核和Symbian OS内核所期望的控制函数的专用硬件实现。就像上面提到的，手机厂商可以在往新硬件移植的时候选择把该层分离到ASSP或者变量里去。

该变量层也提供硬件抽象层函数的专用硬件实现，虽然这些可能在内核或扩展中被同等地实现。

在第五章，内核服务，我将解释每层暴露给其他层的服务。

Symbian OS Internals——内存模型、个性层、扩展和变量

1.3.2.3 内存模型

在EKA2里，我们把关于ASIC内存结构的设想限定在一个模块中，就是内存模型。从而内存管理模型封装了重要的MMU(存储器管理单元)差异，比如一个缓存是被虚拟标记还是被实际标记，也就是：到底存不存在MMU。在EKA1里，关于内存和MMU的设想遍布于整个操作系统，这样，使得生产一个基于没有MMU的ASIC的手机比较困难。但EKA2的到来使得它变得容易得多，既然内存模型允许以不同的形式访问内存，那么改变这个结果就相应地容易了。

Symbian目前提供四种不同的内存模型：

1、直接内存模型(没有MMU)；

2、移动内存模型(类似于EKA1)；

3、多重内存模型(用于实际标记缓存的ASIC，比如Intel的X86和以后的ARM内核)；

4、模拟器内存模型(用于运行在Windows上的Symbian OS模拟器)；

内存模型提供低级别(low-level)内存管理服务，比如每进程寻址空间和内存映射。它在调度器有要求的时候执行上下文转换并参与进程内数据传输。

内存模型也帮助创建进程，作为由文件服务器装载的可执行映射的实例，并且它也参与促成进程内数据传输。

如果有兴趣在内存模型上有更多发现，请查看第七章：内存模型。

1.3.2.4 个性层

我们设计微内核以提供刚好够用的功能集来运行GSM信号栈。之后的想法是允许手机厂商在单处理器上即能运行他们自己的信号栈，也能运行他们的个人信息管理(PIM)软件，相比双处理器方案而言可以节省可观的费用。

大部分手机厂商为现有的诸如Nucleus或者μITRON等RTOS写了自己的信号栈。这些信号栈意味着时间和金钱上相当大的投资，而手机厂商要把它们移植到微内核上也将产生很大的耗时——这里还没有考虑肯定会增加的其它一些缺陷。

因此，我们设计的微内核允许第三方编写个性层。个性层是跨越微内核为客户端软件提供RTOS API的一个模拟层。个性层将把RTOS调用翻译成微内核调用，以取得同样的结果。在这种方式下，我们允许为这样的RTOS写的源代码运行在Symbian OS之下，这些代码可以有一些小的改动或者没有改动。

要获得关于个性层的更多细节描述，以及微内核对它的支持，请查阅第十七章：实时。

1.3.2.5 ASSP/可变扩展

移动设备上的CPU和大部分硬件外设往往实现在一个通常称为ASSP (Application-Specific Standard Product)的半导体设备集成电路上。为了减少材料上的花费和电话的大小，现在比较流行的做法是往ASSP上增加不断增多的组件，这将在同一个硅包上包括堆叠RAM和Flash组件，或者把组件合并到硅层里去。这些组件的例子有：一个用于声频/视频处理的DSP(Digital signal processor)，专用的图形处理器和运行GSM或者CDMA通信栈的电话基带处理器。

我们提及ASSP之外的任何硬件组件时，都把它们当作可变的特定组件。代表性的组件有：Flash和RAM存储设备、显示设备、基带和蓝牙单元。它们通常使用半导体供应商指定的总线结构和互联接口与处理器连接，并且互连，也可以通过更标准的通信线，比如USB和串行UART。ASSP也有意MMC卡检测和触摸屏笔点击中断线等定制功能提供可配置的GPIO(general purpose I/O)线。

因此，在Symbian OS里，ASSP/可变扩展提供了内核所需要的依赖硬件的服务，比如计时器滴答中断和实时时钟访问。在EKA1时期，我们把ASSP集成到内核里，而且在下节中描述的独立的可变层是托管的。这使得往ASSP进行新的移植时不需要重新编译内核，因此，在EKA2中我们已经把ASSP从内核中完全地分离出去。当然，这意味着如果你要移植EKA2，将不必在每次调整硬件的时候重新编译内核。

1.3.2.6 变量

在EKA2里，我们不强制你如同我们在EKA1中所做的的那样必须在ASSP和变量间进行区分。如果你愿意，你可以提供一个单独的变量DLL。然而，如果你把OS移植到一系列相似的ASIC，你可能选择分离，把实现一系列范性ASIC的代码放到ASSP扩展中，而实现特殊ASIC的代码放到变量DLL里。比如，在Symbian里，Intel SA1100 ASSP有两个变量，即Brutus和Assabet。

Symbian OS Internals——Symbian OS内核结构

Symbian OS Internals——Symbian OS内核结构
基于这些设计目标，我们设计了这个操作系统，在高层次上看，它的结构就像图1.1所示。在本书中可以看到内核的主要构成。我也包括了另外两个通常被认为是操作系统部分的主要系统组件，这就是在本书中将提到的文件服务器和窗口服务器。本书中将提到这两个部分并介绍其基本功能。

1.3.2.1 微内核

微内核的主要功能是提供简便的管理者模式线程，以及对操作进行调度和同步。我们把它命名为微内核，是因为它提供的服务要比大部分的嵌入式实时操作系统(RTOSes)要单纯得多。不过，我们仍然很谨慎地采用了那些服务以足够支持GSM信号栈。

微内核是所有中断最初的处理器，然后它将大部分的中断传递到变量层进行分发。微内核也提供简单的计时功能，比如微内核计时器(NTimer)API——它在指定数量的滴答(tick)后发送一个回调信号，还有睡眠API(NKern::Sleep)——它使当前线程等待指定数量的滴答。

上述的简单同步对象就是微内核的互斥量和微内核信号量。它们都禁止一个以上线程等待它们。

最后，微内核还提供了滞缓函数调用(Defered Function Calls，DFCs)和被奇特命名的立即滞缓函数调用(Immediate Defered Function Calls，IDFCs)。如果想找到更多相关信息，请翻到第六章，中断和异常。

必须提及一个EKA2区别于EKA1的重要差异，那就是微内核和Symbian OS内核都不链接到用户库EUSER。相反地，微内核使用它自己的功能函数库，并且也对内核的其他部分和设备驱动开放这些函数库。

另外一个与EKA1的主要差异与我刚讨论过的那个问题有点关系：EKA2不支持内核侧的退出机制，这意味着错误通过返回一个错误码被反馈——或者使线程panic。

大部分时间里，微内核是抢占式的。它运行的时候常常不被锁定并且可以设置中断，但是我们必须阻止其他的线程在一些代码区中运行，比如线程状态的改变和访问等待列表。我们把这些临界区设计得尽可能的短，并且让它们只能被有限次地执行，其目的是为了维护确定的实时性能。我们通过阻止抢占把临界区保护在微内核里——这是可能地，因为这些临界区很短。通常，我们使用被当成系统锁的互斥量把临界代码保护在Symbian OS内核和内存模型里，但是微内核使用互斥量的唯一场合，就是在移动内存模型上保护调度器的寻址空间开关。

微内核的局限性是什么呢？主要的就是它不执行动态内存分配；也就是它不能分配和释放内存。在所有的微内核操作中，它假定内存已经被操作系统的其他部分预分配了。

1.3.2.2 Symbian OS 内核

Symbian OS内核提供了Symbian OS所需要的内核功能，它建立在简易进程和微内核提供的服务的基础上，以提供更多的对象，比如用户模式线程，引用被计数对象和句柄，动态装载库，交互线程以及其他的一些对象。

这些对象还包括一些更复杂的异步对象：Symbian OS信号量和互斥量。Symbian OS信号量是标准的计数信号量，它支持多个等待的线程并根据优先级释放等待的线程。Symbian OS互斥量可以完全嵌套的，一个线程可以同时获得多个资源的互斥量，也可以多次获得同一资源的互斥量。它也支持优先级继承：如果所有等待线程的最高优先级高于独占资源的线程的一般优先级，那么独占资源的线程继承等待线程的最高优先级。

比起微内核，Symbian OS内核允许动态内存分配。它提供一个内核内存分配器——即内核堆，使用内存模型实体提供的低级别内存服务的。Symbian OS完全是MMU不可知论者，我们把所有关于内存的假设都隔离到内存模型里，下面的章节将详细描述这个问题。

Symbian OS内核完全是抢占式的：一个中断可以导致它在执行期的任何时刻重新进行任务调度，甚至在上下文转换期间也可以这样做。这意味着Symbian OS内核可能在线程的持续期间不产生任何作用。

我们使用微内核提供的系统锁互斥量保护多数Symbian OS内核的基本部分，比如：

(i)D线程对象的状态。当Symbian OS线程通过信号量和互斥量相互影响时，它们要经历被系统锁保护起来的状态转换。

(ii)大部分Symbian OS同步对象的状态：IPC(服务和会话)，信号量，互斥量，消息队列，发布和订阅所有权。

(iii)当系统锁被设置时句柄集可读但不可写。所有拥有句柄的可执行函数在翻译系统锁的时候都设置了系统锁。

Symbian OS Internals——设计目标

Symbian OS Internals——设计目标

在开始设计EKA2的时候，我们给自己制定了一些约束。我们确定了不想抛弃掉的EKA1中的某些部分，这就意味着我们想保证新的内核仍然可以做到以下几点：
1、遵循嵌入式OS的传统
2、适合资源受限的环境
3、模块化：由微内核和用户端服务器组成
4、兼容多种芯片集
5、健壮，可以容忍糟糕的代码
6、完整，保证用户数据的安全
接着，我们制定了新的目标。主要的目标是：新的核心将是实时的，并且提高了整体性能。我们决定如果能在新的操作系统上运行一个GSM协议栈，这个目标就可以达到。一个好处，而且是一个有价值的好处，是这个核心将具备更好的支持高带宽活动比如通讯和多媒体的能力。这个目标可分解为几个子目标和需求：
1、用户线程响应中断的反应时间小于等于1ms
2、核心进程响应中断的反应时间小于等于500μs
3、快速的互斥量操作(Fast mutex operations)
4、必要时，系统调用的时间长度是已确定的
5、系统调用是抢占式的
6、基于信号量(semaphore)和互斥量(mutex)的优先级队列
7、高分辨率的计时器
接着，我们还考虑了其他可以使这个系统更优化的措施，并提出了下列方案：
1、易于移植——虽然EKA1在设计上已经实现了可移植性，但为了更简单地将这个系统移植到新的硬件上，我们还可以再进一步。
2、对恶意代码(而不仅仅是写得很糟糕)的免疫力。
3、支持单核——内嵌的和用户应用代码可以在同一个处理器内核上运行。
4、为开发和调试提供更好的模拟器，这个模拟器可以更真实地模拟硬件环境。
5、更易于编写设备驱动。
当我们考虑这些设计目标的时候，我们知道在设计中有一个很重要的约束，那就是与EKA1的ESUER类库的兼容性。EUSER是所有Symbian OS应用到内核的接口，而且存在很多这样的EUSER类库。

Symbian OS Internals —— OS的概念

Symbian OS Internals —— OS的概念

让我们从对操作系统OS的一个基本定义开始吧：

操作系统是一种基本软件，它控制它所运行的计算机上所有的操作。操作系统负责管理硬件——控制系统中的多种硬件部分，并将它们组合到一起。OS也负责管理软件，比如，装载Email 客户端和电子数据表等应用。

操作系统通常是在计算机启动时载入到计算机内存中的第一个软件。然后，OS通过载入设备驱动和应用程序以运行启动进程。计算机上的其他所有软件，都要依赖操作系统为它们提供诸如磁盘存储、内存管理、任务调度和用户接口等服务。

Symbian OS有一个比其他许多操作系统都更加模块化的设计。比如，磁盘服务通过文件服务器来执行，屏幕和用户输入设备则通过窗口服务器来管理。然而，有一个可被认为是操作系统核心的部分，那就是负责内存管理、任务管理和任务调度的部分。这个部分就是内核——EKA2。

世界上有很多各负特色的操作系统，我们用一些形容词来描述Symbian OS和EKA2的独特性吧：

Symbian OS和EKA2是模块化的。如前所述，操作系统的功能通过独立的模块提供，而不是在一个集成电路单元中。EKA2更加模块化，通过图1.1也可以看到这点。

EKA2是单用户的。在Symbian OS的手机上没有多用户的概念，这和Windows、Mac OS X或传统的主机操作系统是不同的。

EKA2是多任务的。它的CPU时钟在多个线程间切换，手机用户就感觉到有多个应用程序在同时运行。

EKA2是抢占式的多任务OS，EKA2不依赖一个线程为了另一个线程放弃自己的CPU时间，而是从定时器滴答内重新进行线程调度。

EKA2是基于优先级的采用优先级继承的多任务OS，EKA2基于线程优先级分配CPU时间，当低优先级的线程持有它所需要的互斥量的时候，EKA2会尽可能减少高优先级的线程的延迟时间。

EKA2是实时的，它的服务是有限的，这保证了可以在一个可知的时间内完成这些服务。

EKA2可以是基于只读存储器的操作系统。

EKA2适宜于开放但是资源受限的环境。EKA2是为手机设计的，因此比起开放的桌面操作系统如Windows和Linux，它只需要很少的一些主要的资源，比如内存、电源和磁盘。

Symbian OS Internals——EKA2的历史

在软件工程中，内核设计是最令人激动的一种机遇。在80年代的8位和16位服务于Psion和PDA的内核设计后，EKA2是对32位Symbian内核结构的重构。

Psion’s Organiser发行于1984年，它基于8位处理器，并且仅支持内置的应用程序。对于这样的设备而言，必需的内核用于系统引导和系统设备管理，而且在8位内核和中间件或应用程序间，也没有清晰的区别。

1986年，Psion发行了8位的提供基于交互式OPL语言扩展的Organiser II。这时候，提供足够高效的内存管理对OS就变得重要起来，比如支持交互式语言。

主要的变革开始于90年代，Psion发行了一系列的新版本，包括Laptop，Clamshell Organizer和Industrial Organizer，它们都是基于单操作系统的。16位的EPOC内核被绑定到Intel 8086结构，并且支持扩展，编写这些应用程序不仅可以使用OPL语言，而且也可以使用EPOC OS上的原生C API——它开放了OS以支持任何第三方应用的编写。

这种开放对内核提出了更多要求。首先，它必须形成文档并向第三方开发人员提供。假如有些应用写得很糟糕：内核将必须提供内存保护，以使它们产生的Bug不影响其他的程序，更要保证它们不使整个OS发生崩溃。应用程序要求有成熟的内存管理来管理它们自己的工作区内存。在资源受到严格管理的机器上，大量的事件驱动服务必须高效地执行。所有的这些问题都提交到了8086的分段式内存模型平台，这种平台同时还要面对能够让PC程序员在将来乐于接受的挑战。

因此，16位的EPOC内核必须处理今天的EKA2仍然也要处理的大量请求，因为它的配置介于嵌入式实时系统和传统的比如Windows桌面系统之间。它类似于嵌入式RTOS，但比RTOS更大，因为它支持丰富的功能并且对第三方应用开放。同时，它类似于桌面型系统（开放的、也使用8086结构），但它又更小，因为它可用的内存和电源等资源比桌面型系统更少。

对于EKA2的诞生，两个更深远的变革是必需的。

EPOC32，形成于1994年，发布于1997年的Psion’s Series5 PDA中。它的内核采用EKA1的配置，继承了16位EPOC内核的优良品质，同时还增加了一些重要的特性。首先，由于采用8086的分段内存结构，EKA1完全是32位的，EPOC可以尽量避免那种因设计的不合理而产生的崩溃。其次，EKA1内核诞生于硬件的种类和革新都很丰富的年代，这使它与被绑定到80186总线结构上的16位EPOC不同。基本结构的差异，使得很多的实现细节发生了改变，但EKA1与16位的EPOC还是有本质上的相似性。

就在那时，我职业生涯中最值得骄傲的时刻在我的卧室里发生了。那时，团队中其他都不在办公室，所以我在家里工作了了一个星期，我近乎疯狂地努力，试图在他们回来之前第一次成功引导内核。最后，在星期五的下午，空线程终于打印出来了它的调试信息——EKA1诞生了。

显然，EKA1并不是故事的终结。支持事件驱动编程的Symbian OS系统很有效率，但它不提供实时的保证。它的内核设计得很健壮——以支持用户个人数据的PDA产品——这是基本的目标。当Symbian OS开始专注于处理移动电话的需求时，提供实时处理的支持就显得很重要了。

还有其他的一些因素在影响着EKA2。在EKA1的环境下进行实时硬件移植的经验表明，EKA1模块的边界不太好确定，这就给移植工作带来了困难。有些端口，只需要很小的一点驱动上的改变，但在实现上，却要求重构内核。

所以，新的内核结构在设计之初就区别于最初的32位EPOC内核，它被命名为EKA2(EPOC Kernel Architecture 2)，这个命名暗示了EKA1是它的先驱。

EKA2的设想形成于1998年，而且渐渐地被推向市场。到2003年，Symbian主要的授权用户和半导体供应商都承诺在未来的产品中采用EKA2。

写这本书是为了向用户提供新实时内核的详细说明，并向读者介绍设计和实现这个内核的软件工程师对它的理解。

本章作为本书的基础，它应该让你对新实时内核的整体体系结构有一个良好的理解，同时理解我们对设计选择的论证。我也将对模拟器的设计有所涉及，然后在本书的稍后部分返回这个主题，更详细地介绍它。

Reading given number of bytes with RSocket::Read()

Introduction
If your network Symbian program just blocks forever mysteriously, or you just want a simple piece of code to demonstrate how to use socket in Symbian. This story is for you.

The expedition
Very often, we want to read a given number of bytes from a network when, for example, the message body length is known after reading the header. Symbian RSocket provides two groups of reading methods, RecvOneOrMore() with a scheme for reading some and returning as soon as possible and Recv()/Read() with a scheme for blocking until the maximum length of the buffer descriptor is fully filled. Both the schemes can fulfill our requirement. With RecvOneOrMore, we can make a loop to keep reading and counting the returned bytes until the sum is not less than the desired message length. Obviously, this method is not efficient enough. We may prefer to allocate a descriptor with a given maximum length and use Recv()/Read() to get the work done in one call. The example is as follows:

RSocketServ socketServ;
RSocket socket;
RSocket listener;
User::LeaveIfError(socketServ.Connect());
CleanupClosePushL(socketServ);
User::LeaveIfError(listener.Open(socketServ,
KAfInet,KSockStream, KProtocolInetTcp));
User::LeaveIfError(listener.SetLocalPort(80));
User::LeaveIfError(listener.Listen(1));
TRequestStatus status;
TBuf8<256> buffer;
socket.Open(socketServ);
listener.Accept(socket, status);
User::WaitForRequest(status);
......
TBuf8<256>data;
socket.Read(data,status);
User::WaitForRequest(status);
......
The listener object listens at port 80, once an incoming connection is accepted; another RSocket object socket reads the data from the network as shown in the last three lines. Here, 256 bytes are read before the code can continue.

This is not the end of the story because while we are coding, we usually have no idea if it must be 256. The number of bytes to be read can be known only at run time. But the size of the stack based descriptor TBuf must be set before compilation. Unfortunately, I couldn't find any piece of example code that solves this problem in SDK document or Google. I tried to use the heap based alternative, HBufC, whose size can be set at run time. HBufC is not modifiable. But RSocket::Read method requires a modifiable descriptor. This can be overcome by using the method HBufC::Des(). This gives a good introduction to the Symbian descriptor system. The code is modified as follows:

TPtr8 gDataPtr(NULL,0);
UInt32 msglen;
//... assign value to msglen ...
HBufC8* buffer = HBufC8::NewL(msglen);
gDataPtr.Set(buffer->Des());
socket.Read(gDataPtr,status);
User::WaitForRequest(status);
It works as expected. But is it correct? I thought so before it took me a whole day to find out why sometimes the program just blocks forever. For example, when the value of msglen is 137 and when you check buffer->Des().MaxLength() of the newly allocated buffer, you get a value of 140! The RSocket::Read method checks only the MaxLength and tries to fill it. It keeps waiting for the 3 bytes that never exist even when the desired 137 bytes have already been received.

Why the MaxLength is 140 and not 137? Because “the maximum length of the heap cell in which the HBufC was allocated is used to set the maximum length of the returned TPtr", as Tip9 of descriptor-tips says. The size of the heap cell only guarantees that it can contain the size given by the user, but not equal to it! 137 is not word-aligned, so the system allocates 140 instead.

I can’t imagine that the Symbian descriptor system doesn’t provide any solution for such a simple problem to the RSocket::Read’s requirement. However, I am too exhausted to dig for it. I finally chose a non-Symbian favour by maintaining a C-style array.

TUint8 *buf=new TUint8[msglen];
gDataPtr.Set(buf,0,msglen);
blank.Read(gDataPtr,status);
User::WaitForRequest(status);
Of course, now I have to take care of releasing the array space myself.

I'll appreciate if any Symbian expert can give us an official solution. My expedition has to stop here before I can’t help deleting my Symbian SDK and install double copies of Java and .NET.

Friday, October 19, 2007

Symbian OS Overview

Symbian OS
Website: http://www.symbian.com
Company/
developer: Symbian Ltd.
Source model: Shared
Supported platforms: ARM (can be emulated on x86)
Kernel type: Real time
Default user interface: S60 platform, UIQ
Working state: Current

Symbian OS is a proprietary operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors.

Symbian is currently owned by Nokia (47.9%), Ericsson (15.6%), Sony Ericsson (13.1%), Panasonic (10.5%), Siemens AG (8.4%) and Samsung (4.5%). While BenQ has acquired the mobile phone subsidiary of Siemens AG the Siemens AG stake in Symbian does not automatically pass to BenQ – this will need the approval of the Symbian Supervisory Board.

Contents
1Design
2Competition
3Structure
4History
4.1Psion
4.2EPOC16
4.3EPOC OS Releases 1–3
4.4EPOC Release 4
4.5EPOC Release 5 aka. Symbian OS 5
4.6ER5u aka. Symbian OS 5.1
4.7Symbian OS v6.0 and 6.1
4.8Symbian OS 7.0 and 7.0s
4.9Symbian OS 8.0
4.10Symbian OS 8.1
4.11Symbian OS 9.0
4.12Symbian OS 9.1
4.13Symbian OS 9.2
4.14Symbian OS 9.3
4.15Symbian OS 9.5
5Open Source Software for Symbian 9.1
5.1Utilities
5.2Game emulation
5.3Multimedia
6Security and malware
7Openness
8Devices that have used the Symbian OS
9Developing on Symbian OS
10See also
11Notes and references
12External links

Design
Symbian OS, with its roots in Psion Software's EPOC, is structured like many desktop operating systems with pre-emptive multitasking, multithreading, and memory protection.

Symbian OS's major advantage is the fact that it was built for handheld devices, with limited resources, that may be running for months or years. There is a strong emphasis on conserving memory, using Symbian-specific programming idioms such as descriptors and a cleanup stack. Together with other techniques, these keep memory usage low and memory leaks rare. There are similar techniques for conserving disk space (though the disks on Symbian devices are usually flash memory). Furthermore, all Symbian OS programming is event-based, and the CPU is switched off when applications are not directly dealing with an event. This is achieved through a programming idiom called active objects. Correct use of these techniques helps ensure longer battery life.

All of this makes Symbian OS's flavor of C++[citation needed] very specialised. However, many Symbian OS devices can also be programmed in OPL, Python, Visual Basic, Simkin, and Perl – together with the Java ME and PersonalJava flavors of Java.

Competition
SymbianOS EKA2 also supports sufficiently-fast real-time response that it is possible to build a single-core phone around it- that is, a phone in which a single processor core executes both the user applications and the signalling stack. This is not a feature that is available from Linux or Windows CE. This has allowed SymbianOS EKA2 phones to become smaller, cheaper and more power efficient[citation needed].

Statistics published July 2006 showed that Symbian OS had a 67% share of the 'smart mobile device' market, with Microsoft having 15% and RIM having 6%.[1]

Structure
At its lowest level lie the base components of Symbian OS. This includes the kernel (EKA1 or EKA2 – see the 'History' section), and the user library which allows user-side programs to request things of the kernel. Symbian OS has a microkernel architecture, which means that the minimum necessary is within the kernel. It contains a scheduler and memory management, but no networking or filesystem support. These functions are provided by user-side servers. The base layer includes the file server, which provides a fairly DOS-like view of the filesystems on the device (each drive has a drive letter, and backslashes are used as the directory delimiter). Symbian OS supports various filesystem types including FAT32 and Symbian OS-specific NOR flash filing systems. The filesystem is generally not exposed to the user through the phone user interface.

Immediately above base are a selection of system libraries. These take all shapes and sizes, including character set conversion, a DBMS database, and resource file handling.

Further up, the software is not so readily arranged into a stack.

The tone or style of this article or section may not be appropriate for Wikipedia.
Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.

There is a large networking and communication subsystem, which has three main servers – ETEL (EPOC telephony), ESOCK (EPOC sockets) and C32 (responsible for serial communication). Each of these has a plug-in scheme. For example ESOCK allows different ".PRT" protocol modules, implementing different types of networking protocol scheme. The subsystem also contains code that pertains to short-range communication links too, such as Bluetooth, IrDA and USB.

There is also a large volume of 'User Interface (UI) Code'. For the most part actual user interfaces are maintained by third parties. However the base classes and substructure are contained within the Symbian OS. This component is known as UIKON. The Symbian OS also contains the graphics, text layout, and font rendering libraries.

An application architecture provides for standard application types, embedding, and file and data recognition. There is also a selection of application engines for popular smartphone applications such as calendars, address books, and task lists. A typical Symbian OS application is split up into an engine DLL and a graphical application – the application being a thin wrapper over the engine DLL. Symbian OS provides some of these engine DLLs.

There are, of course, many other things that do not yet fit into this model – for example, SyncML, Java ME providing another set of APIs on top of most of the OS and multimedia. Quite a few of these are frameworks, and vendors are expected to supply plug-ins to these frameworks from third parties (for example, Helix player for multimedia codecs). This has the advantage that the APIs to such areas of functionality are the same on many phone models, and that vendors get a lot of flexibility, but means that phone vendors need to do a great deal of integration work to make a Symbian OS phone.

Symbian OS device manufacturers also get supplied with an example user interface layer called TechView. This is very similar to the user interface from a Psion Series 5 personal organiser, so isn't particularly similar to any given phone user interface, but provides a basis to start customisation. It is also the environment in which a lot of Symbian OS test code and example code runs.

History

Psion
In 1980, Psion was founded by David Potter.

EPOC16
Psion released several Series 3 devices from 1991 to 1998 which used the EPOC16 OS, also known as SIBO.

EPOC OS Releases 1–3
The Series 5 device, released in 1997, used the first iterations of the EPOC32 OS.

EPOC Release 4
Oregon Osaris and Geofox 1 were released using ER4.

In 1998, Symbian Ltd. was formed as a partnership between Ericsson, Nokia, Motorola and Psion, to explore the convergence between PDA's and mobile phones.

EPOC Release 5 aka. Symbian OS 5
Psion Series 5mx, Series 7, Psion Revo, Psion Netbook, netPad, Ericsson MC218 were released in 1999 using ER5.

ER5u aka. Symbian OS 5.1
The first phone, the Ericsson R380 was released using ER5u in 2000. It was not an 'open' phone – software could not be installed. Notably, a number of never-released Psion prototypes for next generation PDAs, including a Bluetooth Revo successor codenamed Conan were using ER5u. The 'u' in the name refers to the fact that it supported Unicode.

Symbian OS v6.0 and 6.1
Sometimes called ER6. The first 'open' Symbian OS phone, the Nokia 9210, was released in 2001.

Symbian OS 7.0 and 7.0s
First shipped in 2003. This is an important Symbian release which appeared with all contemporary user interfaces including UIQ (Sony Ericsson P800, P900, P910, Motorola A925, A1000), Series 80 (Nokia 9300, 9500), Series 90 (Nokia 7710), Series 60 (Nokia 3230, 6600, 7310) as well as several FOMA phones in Japan.

Symbian OS 7.0s was a version of 7.0 special adapted to have greater backwards compatibility with Symbian OS 6.x, partly for compatibility between the Communicator 9500 and its predecessor the Communicator 9210.

In 2004, Psion sold its stake in Symbian. The same year, the first worm for mobile phones using Symbian OS, Cabir, was developed, which used Bluetooth to spread itself to nearby phones. See Cabir and Symbian OS threats.

Symbian OS 8.0
First shipped in 2004, one of its advantages would have been a choice of two different kernels (EKA1 or EKA2). However, the EKA2 kernel version did not ship until Symbian OS 8.1b. The kernels behave more or less identically from user-side, but are internally very different. EKA1 was chosen by some manufacturers to maintain compatibility with old device drivers, while EKA2 offered advantages such as real-time response. 8.0b was deproductized in 2003.

Symbian OS 8.1
Basically a cleaned-up version of 8.0, this was available in 8.1a and 8.1b versions, with EKA1 and EKA2 kernels respectively. The 8.1b version, with EKA2's single-chip phone support but no additional security layer, was popular among Japanese phone companies desiring the real-time support but not allowing open application installation.

Symbian OS 9.0
This version was used for internal Symbian purposes only. It was deproductised in 2004. 9.0 marked the end of the road for EKA1. 8.1a is the final EKA1 version of Symbian OS.

Symbian OS has generally maintained reasonable binary compatibility. In theory the OS was BC from ER1-ER5, then from 6.0 to 8.1b. Substantial changes were needed for 9.0, related to tools and security, but this should be a one-off event. The move from requiring ARMv4 to requiring ARMv5 did not break backwards compatibility.

A Symbian developer proclaims that porting from Symbian 8.x to Symbian 9.x is a more daunting process than Symbian says.[2]

Symbian OS 9.1
Released early 2005. It includes many new security related features, particularly a controversial platform security module facilitating mandatory code signing. Symbian argues that applications and content, and therefore a developers investment, are better protected than ever, however others contend that the requirement that every application be signed (and thus approved) violates the rights of the end-user, the owner of the phone, and limits the amount of free software available. The new ARM EABI binary model means developers need to retool and the security changes mean they may have to recode. S60 platform 3rd Edition phones have Symbian OS 9.1. Sony Ericsson is shipping the M600 and P990 based on Symbian OS 9.1. The earlier versions had a fatal defect where the phone hangs temporarily after the owner sent hundreds of SMS'es. However, on 13 September 2006, Nokia released a small program to fix this defect.[3]

Support for Bluetooth 2.0 (was 1.2)

Symbian OS 9.2
Released Q1 2006. Support for OMA Device Management 1.2 (was 1.1.2). S60 3rd Edition Feature Pack 1 phones have Symbian OS 9.2. Nokia phones with Symbian OS 9.2 OS: Nokia N75, Nokia N76, Nokia 6120 Classic, Nokia E90, Nokia N95, Nokia 5700

Symbian OS 9.3
Released on 12 July 2006. Upgrades include improved memory management and native support for Wifi 802.11, HSDPA, Vietnamese language support.

Symbian OS 9.5
Announced in March 2007, it introduced demand paging. Applications should launch up to 75% faster. Native support for mobile digital television broadcasts in DVB-H and ISDB-T formats and also location services. Additionally, SQL support is provided by SQLite.

Open Source Software for Symbian 9.1
The following Open Source software has been rewritten for Symbian 9.1:

Utilities
PuTTY, a telnet/ssh client
Internet Radio
Ruby Programming Language
SymTorrent, a bittorrent client
Symella, a gnutella client
Python interpreter
Apache HTTP Server, a web server

Game emulation
ScummVM

Multimedia
OggPlay – Audio player with ogg vorbis audio format support
Symbian has announced PIPS (PIPS Is POSIX on Symbian) which may increase the number of Open Source projects written for Symbian 9.1.

Security and malware
Main article: Mobile virus
Symbian OS has been subject to a variety of viruses, the best known of which is Cabir. Usually these send themselves from phone to phone by Bluetooth. So far, none have taken advantage of any flaws in Symbian OS – instead, they have all asked the user whether they would like to install the software, with somewhat prominent warnings that it can't be trusted.

However, of course, the average mobile phone user shouldn't have to worry about such things, so Symbian OS 9 is adopting a capability model. Installed software will theoretically be unable to do damaging things (such as costing the user money by sending network data) without being digitally signed – thus making it traceable. Commercial developers who can afford the cost can apply to have their software signed via the Symbian Signed program. Currently, developers also have the option of self-signing their programs. However, the set of available features is smaller, and certain operators have opted on fully disabling certificates other than the Symbian Signed certificates.

Some other hostile programs are listed below, but all of them still require the input of the user to run.

Drever.A is a malicious SIS file trojan that attempts to disable the automatic startup from Simworks and Kaspersky Symbian Anti-Virus applications.
Locknut.B is a malicious SIS file trojan that pretends to be patch for Symbian S60 mobile phones. When installed, it drops a binary that will crash a critical system service component. This will prevent any application from being launched in the phone.
Mabir.A is basically Cabir with added MMS functionality. The two are written by the same author, and the code shares many similarities. It spreads using Bluetooth via the same routine as early variants of Cabir. As Mabir.A activates it will search for the first phone it finds, and starts sending copies of itself to that phone.
Frontal.A is a SIS file trojan that installs a corrupted file which causes the phone to fail at reboot. If the user tries to reboot the infected phone, it will be permanently stuck on the reboot, and cannot be used without disinfection – that is, the use of the reformat key combination which causes the phone to lose all data. Being a trojan, Frontal.A cannot spread by itself – the most likely way for the user to get infected would be to acquire the file from untrusted sources, and then install it to the phone, inadvertently or otherwise.
Another virus comes as an audio file. It saves itself in the sound clips folder as disco.mid.[citation needed]

Openness
Symbian is not Open Source software. However, phone manufacturers and other partners are provided with parts of its source code. The APIs are publicly documented and up to Symbian 8.1 anyone could develop software for Symbian OS.

Symbian 9.1 introduced capabilities and Platform Security framework. To access certain capabilities, the developer has to digitally sign their application. Basic capabilities are user-grantable and developer can self-sign them, more advanced require certification and signing via the Symbian Signed program; which uses independent Test Houses and/or phone manufacturer approval. For example file writing is a user-grantable capability, and access to Multimedia Device Drivers require phone manufacturer approval. TC TrustCenter ACS Publisher ID certificate required from developer for signing application with Test House. Signing application with Test House is not free, Symbian Signed provides free certification and signing for freeware application via the mobile software publisher Cellmania.

Despite appearing to be designed with the GNU Public License in mind, the free freeware signing is not actually compatible with the GPL. It requires the addition of a notification informing additional restrictions on the software above and beyond the terms of the GPL (that it is "freeware and may not be sold"). The addition of such restrictions by anyone other than the copyright holder would constitute a violation of the terms of the GPL.

Devices that have used the Symbian OS
On November 16, 2006, the 100 millionth smartphone running the OS was shipped.[4]

Ericsson R380 (2000) was the first commercially available phone based on Symbian OS. As with the modern "FOMA" phones, this device was closed, and the user could not install new C++ applications. Unlike those, however, the R380 could not even run Java applications, and for this reason, some have questioned whether it can properly be termed a 'smartphone'.
Nokia 9210 Communicator smartphone (32-bit 66 MHz ARM9-based RISC CPU) (2001), 9300 Communicator (2004), 9500 Communicator (2004) using the Nokia Series 80 interface
UIQ interface:
Used for PDAs such as Sony Ericsson P800 (2002), P900 (2003), P910 (2004), P990 (2005), W950 (2006), M600 (2006), P1 (2007), W960 (2007), Motorola A920, A925, A1000, RIZR Z8, RIZR Z10, DoCoMo M1000, BenQ P30, P31 and Nokia 6708 using this interface.
Nokia S60 (2002)
Nokia S60 is used in various phones, the first being the Nokia 7650, then the Nokia 3650, followed by the Nokia 3620/3660, Nokia 6600, Nokia 7610, Nokia 6670 and Nokia 3230. The Nokia N-Gage and Nokia N-Gage QD gaming/smartphone combos are also S60 platform devices. It was also used on other manufacturers' phones such as the Siemens SX1, Sendo X, Panasonic X700, Panasonic X800, Samsung SGH-D730, SGH-D720 and the Samsung SGH-Z600. Recent, more advanced devices using S60 include the Nokia 6620, Nokia 6630, the Nokia 6680, Nokia 6681 and Nokia 6682, a next generation N series, including the Nokia N70, Nokia N72, Nokia N73, Nokia N75, Nokia N80, Nokia N90, Nokia N91, Nokia N92, Nokia N93 and Nokia N95, and the enterprise (i.e. business) model E series, including the Nokia E50, Nokia E60, Nokia E61, Nokia E62, Nokia E65, and Nokia E70. For an up to date list, refer to the Symbian S60 website.
Nokia 7710 (2004) using the Nokia Series 90 interface.
Fujitsu, Mitsubishi, Sony Ericsson and Sharp phones for NTT DoCoMo in Japan, using an interface developed specifically for DoCoMo's FOMA "Freedom of Mobile Access" network brand. This UI platform is called MOAP "Mobile Orientated Applications Platform" and is based on the UI from earlier Fujitsu FOMA models.

Developing on Symbian OS
There are multiple platforms, based upon Symbian OS, that provide an SDK for application developers wishing to target a Symbian OS device – the main ones being UIQ and S60. Individual phone products, or families, often have SDKs or SDK extensions downloadable from the manufacturer's website too. The SDKs contain documentation, the header files and library files required to build Symbian OS software, and a Windows-based emulator ("WINS"). Up until Symbian OS version 8, the SDKs also included a version of the GCC compiler (a cross-compiler) required to build software to work on the device.

Symbian OS 9 uses a new ABI and so requires a new compiler – a choice of compilers is available including a new version of GCC (see external links below). In terms of SDKs, UIQ Technology now provides a simplified framework so that the single UIQ SDK forms the basis for developing on all UIQ 3 devices, such as the Sony Ericsson P990 and Sony Ericsson M600.

Symbian C++ programming is commonly done with an IDE. For previous versions of Symbian OS, the commercial IDE CodeWarrior for Symbian OS was favoured. The CodeWarrior tools were replaced during 2006 by Carbide.c++, an Eclipse-based IDE developed by Nokia. Carbide.c++ is offered in 4 different versions: Express, Developer, Professional, and OEM, with increasing levels of capability. Full featured software can be created and released with the Express edition, which is free. Features such as UI design, crash debugging etc. are available in the other charged for editions.

Visual Basic, VB.NET, and C# development for Symbian were posible through AppForge Crossfire, a plugin for Microsoft Visual Studio. March 13, 2007 AppForge ceased operations, Oracle purchased the intellectual property, but announced that they do not plan to sell or provide support for former AppForge products going forward.

There is also a version of a Borland IDE for Symbian OS. Symbian OS development is also possible on Linux and Mac OS X using tools and techniques developed by the community, partly enabled by Symbian releasing the source code for key tools. A plugin that allows development of Symbian OS applications in Apple's Xcode IDE for Mac OS X is available.[5]

Once developed, Symbian OS applications need to find a route to customers' mobile phones. They are packaged in SIS files which may be installed over-the-air, via PC connect or in some cases via Bluetooth or memory cards. An alternative is to partner with a phone manufacturer to have the software included on the phone itself. The SIS file route is more difficult for Symbian OS 9.x, because any application wishing to have any capabilities beyond the bare minimum must be signed via the Symbian Signed program.

Java ME applications for Symbian OS are developed using standard techniques and tools such as the Sun Java Wireless Toolkit (formerly the J2ME Wireless Toolkit). They are packaged as JAR (and possibly JAD) files. Both CLDC and CDC applications can be created with NetBeans. Other tools include SuperWaba, which can be used to build Symbian 7.0 and 7.0s programs using Java.

Nokia S60 phones can also run python scripts when the interpreter is installed, with a custom made API that allows for Bluetooth support and such. There is also an interactive console to allow the user to write python scripts directly from the phone.

Labels: Symbian OS Overview