Modifying Configuration Files
If you cloned your BSP from an existing BSP, all configuration files are already in place. However, it is important that you review the memory layout in the Config.bib file, as explained in detail in Lesson 2. The other configuration files require modifications only if you added new drivers or modified components in the BSP, as explained in Chapter 2, "Building and Deploying a Run-Time Image."
Lesson Summary
It is advantageous to start the BSP development process by cloning an appropriate reference BSP. Ideally, this BSP should be based on the same or similar hardware platform because this makes the most of tested and proven production features. Windows Embedded CE features a PQOAL architecture and Platform Builder tools that facilitate the cloning process. The goal is to create a bootable system with minimum customizations and then add additional features and support for peripheral devices as necessary.
The first component of a BSP that you might have to adapt is the boot loader, which is responsible for initializing the hardware platform and passing execution to the kernel. The second component is the OAL, which contains the platform-specific code that the kernel needs for hardware initialization, interrupt handling, and timer handling for the thread scheduler, KITL, and kernel debug output. The third part of the BSP you must adapt is the device drivers for peripheral devices. The fourth part of the BSP requiring adaptation is the configuration files that control the build process, determine the memory layout, and specify system configuration settings. If the BSP adaption is based on a reference BSP for the same processor architecture, then most of the CPU-related and memory controller-related BSP code can remain unchanged. You only need to address platform-specific code portions that focus on bringing up the hardware, rather than creating the necessary setup for the BSP.
Lesson 2: Configuring Memory Mapping of a BSP
Memory management in Windows Embedded CE has changed significantly from previous versions. In past versions, all processes shared the same 4 GB address space. With CE 6.0, each process has its own unique address space. The new system of managing virtual memory enables CE 6.0 to run up to 32,000 processes in contrast to the previous 32 processes limitation. This lesson covers the details of the new memory architecture and management, so that you can map virtual memory regions to correct physical memory addresses on the platform.
After this lesson, you will be able to:
■ Describe how Windows Embedded CE manages virtual memory.
■ Configure static memory mappings for a hardware platform.
■ Map noncontiguous physical memory to virtual memory on the system.
■ Share resources between OAL and device drivers.
Estimated lesson time: 15 minutes.
System Memory Mapping
Windows Embedded CE uses a paged virtual memory management system with a 32-bit virtual address space, mapped to physical memory by using the MMU. With 32 bits, the system can address a total of 4 GB of virtual memory, which CE 6.0 divides into the following two areas (see Figure 5-5):
■ Kernel space Located in the upper 2 GB of virtual memory and shared between all application processes running on the target device.
■ User space Located in the lower 2 GB of virtual memory and used exclusively by each individual process. Each process has its own unique address space. The kernel manages this mapping of the process address space when a process switch occurs. Processes cannot access the kernel address space directly.
Figure 5-5 Virtual memory space in Windows Embedded CE 6.0
Kernel Address Space
Windows Embedded CE 6.0 divides the kernel address space further into several regions for specific purposes, as illustrated in Figure 5-6. The lower two regions of 512 MB each statically map physical memory into cached and non-cached virtual memory. The middle two regions for kernel execute in place (XIP) DLLs and Object Store are important for the OS design. The remaining space is for kernel modules and CPU-specific purposes.
Figure 5-6 Kernel space in Windows Embedded CE 6.0
Table 5-9 summarizes the kernel virtual memory regions with start and end addresses.
Table 5-9 Kernel memory regions
| Start Address | End Address | Description |
|---|---|---|
| 0xF0000000 | 0xFFFFFFFF | Used for CPU specific system trap and kernel data pages. |
| 0xE0000000 | 0xEFFFFFFF | Kernel virtual machine, it is CPU dependent, for example this space is not available for SHx. |
| 0xD0000000 | 0xDFFFFFFF | Used for all kernel mode modules of the OS. |
| 0xC8000000 | 0xCFFFFFFF | Object Store used for RAM file system, database and registry. |
| 0xC0000000 | 0xC7FFFFFF | XIP DLLs. |
| 0xA0000000 | 0xBFFFFFFF | Non-cached mapping of physical memory. |
| 0x80000000 | 0x9FFFFFFF | Cached mapping of physical memory. |
Process Address Space
The process address space ranges from 0x00000000 through 0x7FFFFFFF, and is divided into a CPU-dependent kernel data section, four main process regions, and a 1 MB buffer between user and kernel spaces. Figure 5-7 illustrates the main regions. The first process region of 1 GB is for application code and data. The next process region of 512 MB is for the DLLs and read-only data. The next two regions of 256 MB and 255 MB are for memory-mapped objects and the shared system heap. The shared system heap is read-only for the application process, but readable and writable for the kernel.