Figure 5-7 Process space in Windows Embedded CE 6.0
Table 5-10 summarizes the virtual memory regions in user space with start and end addresses.
Table 5-10 Process memory regions
| Start Address | End Address | Description |
|---|---|---|
| 0x7FF00000 | 0x7FFFFFFF | An unmapped buffer for protection between user and kernel spaces. |
| 0x70000000 | 0x7FEFFFFF | Shared heap between the kernel and processes. |
| 0x60000000 | 0x6FFFFFFF | Memory-mapped file objects that do not correspond to an actual physical file, mainly for backward compatibility with applications that used RAM-backed map files for inter-process communication. |
| 0x40000000 | 0x5FFFFFFF | DLLs loaded into the process and read-only data. |
| 0x00010000 | 0x3FFFFFFF | Application code and data. |
| 0x00000000 | 0x00010000 | CPU-dependent user kernel data (read-only for user processes). |
Memory Management Unit
Windows Embedded CE 6.0 requires the processor to provide a memory mapping mechanism to associate physical memory with virtual memory, up to a maximum of 512 MB of mapped physical memory. Figure 5-8 shows an example with 32 MB of flash memory and 64 MB of RAM mapped into the cached and non-cached static mapping regions of the kernel. On ARM-based and x86-based platforms, the memory mapping relies on a user-defined OEMAddressTable, whereas on the SHx-based and MIPS-based platforms, the mapping is directly defined by the CPU. The Memory Management Unit (MMU) is responsible for managing the physical-to-virtual address mappings.
Figure 5-8 Physical-to-virtual memory mapping example
The kernel initializes the MMU and creates the necessary page tables during system startup. This processor-specific part of the kernel depends on the architecture of the hardware platform. For implementation details, refer to the Windows Embedded CE private code, located in subdirectories per processor type under %_PRIVATEROOT%\Winceos\Coreos\Kernel.
Statically Mapped Virtual Addresses
The virtual memory regions depicted in Figure 5-8 are statically mapped virtual addresses to emphasize the fact that they are defined at startup time and the mapping does not change. Statically mapped virtual addresses are always available and directly accessible in kernel mode. It is noteworthy, however, that Windows Embedded CE also supports static mapping at runtime by means of CreateStaticMapping and NKCreateStaticMapping APIs. These functions return a non-cached virtual address mapped to the specified physical address.
Dynamically Mapped Virtual Addresses
The kernel can also manage the mapping of physical-to-virtual addresses dynamically, which is the technique used for all non-static mappings. A driver or DLL loaded into the kernel through LoadKernelLibrary can reserve a region of virtual memory in the kernel address space by calling VirtualAlloc and then map the virtual address to a physical address by creating a new page-table entry through a call to VirtualCopy. This is a common technique to map virtual addresses to the registers or frame buffers of peripheral devices in order to perform input/output operations. If the mapped buffer is no longer needed, the device driver or DLL can call VirtualFree to remove page-table entry and free the allocated virtual memory.
Memory Mapping and the BSP
You must customize two elements to include information about static memory mappings in a BSP:
■ Config.bib file Provides information about how the system should use the different memory regions on the platform. For example, you can specify how much memory is available for the OS, how much can be used as free RAM and also reserve memory for specific needs.
■ OEMAddressTable Provides information about the memory layout of the underlying platform, as discussed in Lesson 1. The memory specified in Config.bib should also be mapped in the OEMAddressTable.
Mapping Noncontiguous Physical Memory
As mentioned in Chapter 2, "Building and Deploying a Run-Time Image," you must define a single contiguous region in the RAMIMAGE memory region for the operating system in the MEMORY section of the Config.bib file. The system uses this definition to load the kernel image and any modules you specified in the MODULES and FILES sections. You cannot define multiple RAMIMAGE regions, yet the OAL can extend the RAMIMAGE region and provide additional noncontiguous memory sections at runtime.
Table 5-11 summarizes important variables and functions to extend the RAM region.
Table 5-11 Variables and functions to extend the RAM region
| Variable/Function | Description |
|---|---|
| MainMemoryEndAddress | This variable indicates the end of the RAM region. The kernel sets this variable initially according to the size reserved for the operating system in the Config.bib file. The OAL OEMInit function can update this variable if additional contiguous memory is available. |
| OEMGetExtensionDRAM | The OAL can use this function to report the presence of an additional region of noncontiguous memory to the kernel. OEMGetExtensionDRAM returns the start address and length of the second region of memory. |
| pNKEnumExtensionDRAM | The OAL can use this function pointer to report the presence of more than one additional region of memory to the kernel. This mechanism supports up to 15 different noncontiguous memory regions. If you implement the pNKEnumExtensionDRAM function pointer, then OEMGetExtensionDRAM is not called during the startup process |
Enabling Resource Sharing between Drivers and the OAL