Symbian OS internals-memory model, personality layer, extensions and variables

1.3.2.3 Memory Model
In eka2, we define the ASIC memory structure in a module, that is, the memory model. Therefore, the memory management model encapsulates important MMU (Memory Management Unit) differences. For example, whether a cache is virtual or actually marked, that is, whether or not MMU exists. In eka1, memory and MMU assumptions are distributed throughout the operating system, making it difficult to produce a Mobile Phone Based on an ASIC without MMU. But the arrival of eka2 makes it much easier. Since the memory model allows access to the memory in different forms, it is easier to change this result accordingly.

Symbian currently provides four different memory models:

1. Direct Memory Model (without MMU );

2. Mobile Memory Model (similar to eka1 );

3. Multi-Memory Model (used to mark the cached ASIC, such as Intel x86 and later ARM kernel );

4. simulator Memory Model (used for the Symbian OS simulator running on Windows );

The memory model provides low-level memory management services, such as addressing space and memory ing for each process. It performs context conversion when the scheduler has requirements and participates in data transmission in the process.

The memory model also helps to create processes as executable ing instances loaded by the file server and also facilitates data transmission in the process.

If you are interested in more memory models, see Chapter 7 memory models.

1.3.2.4 personality Layer

We designed the microkernel to provide enough function sets to run the GSM signal stack. The idea is to allow mobile phone manufacturers to run their own signal stacks and their personal information management (PIM) software on a single processor, compared with the dual-processor solution, it can save considerable costs.

Most mobile phone manufacturers write their own signal stacks for existing RTOS such as nucleus us or μitron. These signal stacks mean a considerable investment in time and money, mobile phone manufacturers will also spend a lot of time porting them to the microkernel-there are still some other defects that will definitely be added here.

Therefore, the microkernel we designed allows a third party to write the individual layer. The personality layer is a simulation layer that provides RTOS APIs for client software across the microkernel. The personality layer translates RTOS calls into microkernel calls to achieve the same results. In this way, we allow the source code written for such RTOS to run under the Symbian OS, which can be slightly modified or not modified.

For more details about the personality layer and how the microkernel supports it, see Chapter 17th: Real-Time.

1.3.2.5 ASSP/variable extension

CPUs and most hardware peripherals on mobile devices are often implemented on a semiconductor device integrated circuit, usually called ASSP (application-specific standard product. To reduce the cost of materials and the size of the phone number, it is now popular to add an increasing number of components to ASSP, which will include stacked Ram and flash components on the same silicon package, or merge the components into the silicon layer. Examples of these components include a digital signal processor for audio/video processing, a dedicated graphics processor, and a telephone baseband processor running a GSM or CDMA Communication stack.

When we mention any hardware components other than ASSP, we regard them as variable specific components. Representative components include Flash and ram storage devices, display devices, baseband and Bluetooth units. Generally, they connect to the processor using the bus structure and interconnection interface specified by the semiconductor supplier, and can also communicate with the processor through more standard communication lines, such as USB and serial UART. ASSP also intends to provide configurable gpio (general purpose I/O) lines for custom features such as mmccard detection and touch screen click disconnection.

Therefore, in Symbian OS, the ASSP/variable extension provides the hardware-dependent services required by the kernel, such as timer ticking interruption and real-time clock access. During the eka1 period, we integrated ASSP into the kernel, and the independent variable layer described in the next section is hosted. This makes it unnecessary to re-compile the kernel when porting to ASSP. Therefore, we have completely separated ASSP from the kernel in eka2. Of course, this means that if you want to port eka2, you do not have to re-compile the kernel every time you adjust the hardware.

1.3.2.6 Variables

In eka2, we do not force you to distinguish between ASSP and variables as we do in eka1. If you want to, you can provide a separate variable DLL. However, if you port the OS to a series of similar ASIC, you may choose to separate and put the code that implements a series of model ASIC into ASSP extension, the code for implementing the special ASIC is put into the variable DLL. For example, in Symbian, Intel sa1100 ASSP has two variables: Brutus and assabet.

========================================================== ======================================

Note: This article is translated by bequan from Symbian press's Symbian OS internals: Real-Time Kernal programming book. Anyone who needs to repost or reference, please first contact bequan via email (a-pangu@163.com or symbianchn@gmail.com), can be reposted or referenced after obtaining permission, otherwise it is deemed as infringement. When reprinting or referencing, please indicate the above translation information in the article.