* ****************************** Loongembedded ******* *************************
Author: loongembedded (Kandi)
Time: 2012.02.26
Category: wince System Development
* ****************************** Loongembedded ******* *************************
1. wince Memory Model
Figure 1 Comparison Between wince5.0 and wince6.0 memory models
Before wince6.0, the wince operating system supports a maximum of 32 processes, and each process only has 32 MB of virtual memory space, and all processes share the same 4 GB address space. In wince6.0, the kernel process occupies 2 GB of virtual memory space, and each user process has an independent 2 GB virtual memory space at the low end. The maximum number of processes supported by wince6.0 is 32000. The actual number of processes is determined by the size of the physical memory. In the earlier version of wince, the current application is executed in slot0. In wince6.0, the original slot-based allocation method is abandoned, but you can create memory as long as you need it, each has 2 GB of valid virtual memory space.
Because Virtual Memory Access is converted to physical memory access through the memory management unit MMU, the Virtual Memory code is dependent on the CPU. Arm and x86 processors use the hardware page table oemaddresstable, so the hardware can directly access the virtual memory unit. Other CPUs supported by wince use a software-converted bypass buffer TLB (translation look-aside buffer, which can be understood as page table buffer or express table) Miss handler. This requires filling in the virtual memory content.
Wince6.0 designs virtual memory management based on the following objectives:
(1) Each process has a large virtual memory.
(2) There is no limit on the number of processes.
(3) process mutual protection.
(4) Reduce the virtual memory management dependency on CPU code to a minimum.
Allocate valid virtual memory
Miss handling ).
2. wince Virtual Memory Allocation
Next, let's look at the wince6.0 virtual memory address space diagram. First, let's look at the virtual memory address space allocation in kernel mode.
Figure 2 Kernel Mode virtual memory space allocation
(1) Static ing to virtual memory, buffered, range: 0x80000000 ~ 0xa0000000, Which is 512 MB in size. The physical memory is directly accessed through the CPU cache. This is the g_ing between the physical memory and virtual memory in the g_oaladdresstable BSP ing table in the BSP package.
(2) Static ing to virtual memory, no buffer, range: 0xa0000000 ~ Oxbfffffff, with a size of 512 MB. You do not need to use the CPU cache to directly access the physical memory.
(3) virtual memory space of the kernel xip DLLs, range: 0xc0000000 ~ 0xc7ffffff. The size is 128 MB.
(4) OSS region, in the range of 0xc8000000 ~ 0 xcfffffff, 128 MB in size, is mainly used to store RAM file systems, CEDB databases, Ram-based registries, and legacy data storage (legacy data sore ).
Swap kernel virtual memory space, which is shared by all the services and drivers loaded in the kernel. The value range is 0xd0000000 ~ 0 xdfffffff, the size is 256 MB, and the other MB virtual memory space depends on the specific CPU, the range is 0xe0000000 ~ 0 xefffffff.
Swap the virtual memory space of a specific CPU, used in the trap capture area of the System Call, range: 0xf0000000 ~ 0 xffffffff. The size is 256 MB.
In user mode, the virtual memory address space is allocated as follows:
Figure 3 user mode virtual memory space distribution chart
(1) process space of each process, mainly used for executable code and data, virtual memory allocation of user heap,
The value range is 0x00000000 ~ 0x3fffffff. The size is 1 GB.
(2) User Mode DLLs code and data space, range: 0x40000000 ~ 0x5fffffff. The size is 512 MB.
(3) used for the ram-backed ing file, the range is 0x60000000 ~ 0x6fffffff. The size is 256 MB.
(4) shared system heap, range: 0x70000000 ~ 0x7fffffff. The size is 256 MB.
Only one virtual memory can be mapped at a time, and their memory cannot be accessed directly through the Virtual Memory Address of other processes. The Virtual Memory Address can only be used when the process has been allocated. For example, an application cannot call the virtualprotect function in the code to change its existing access protection.
Free (available): allocable
Reserved: the virtual address is retained and cannot be retained. But it cannot be used because it is not mapped to the physical memory.
Commit: maps to a physical address.