porting an embedded ce 6 bsp to windows...
TRANSCRIPT
Porting an Embedded CE 6 BSP to Windows Embedded Compact 7
Douglas Boling
Boling Consulting Inc.
About Douglas Boling
• Independent consultant specializing in Windows Mobile and Windows Embedded Compact (Windows CE)– On-Site Instruction
– Consulting and Development
• Author– Programming Embedded Windows CE
• Fourth Edition
Agenda
• Basic BSP Porting
• Build System changes
• Kernel Memory Map changes
• Adding MultiCore support
• Driver / Application Impacts
3
Compact 7 BSP Basics
• PBXML files the same
– Just drag and drop BSP directory to Platform in new tree
– Restart Visual Studio
• BSP directory layout same as Windows CE 6
• For like hardware, very little changes
• Platform Common layout slightly changed
– New CSP directories
– Minor additions to the .\src\common directory
Changes to BSP Common Code
• OEMinit modified slightly to support new features
– x86
• Init call to x86RebootInit
• OALMpInit
• Startup modifications
– x86
• Patch to use new OEMDeviceTable not enabled by default
• Kernel entrypoint now “KernelStart” to match the other CPUs
– Was “KernelEntry”
• PCMCIA references need to be removed
Build System Changes
• New directories used for generated files
– OLD
Platform\{BSP}\lib
Platform\Common\lib
– New
OSDesigns\{Proj}\{Proj}\WINCE700\{xxx}\CeSysgen\Platform\{BSP}\lib
OSDesigns\{Proj}\{Proj}\WINCE700\{xxx}\CeSysgen\Platcomm\lib
• New Environment variable
– SG_OUTPUT_ROOT
.\OSDesigns\{Proj}\{Proj}\WINCE700\{BSPName}_{CPU}_{WINCEDEBUG}\CeSysgen
BSP Build System Changes
• Same hardware port
– Mainly involves getting the BSP to compile
• Files impacted
– {BSP}.bat
– sources.cmn
– src\oal\oalexe\sources
– src\drivers\xxx\sources
•
New Features that Impact the BSP
• New memory manager
– Supports up to 4 GB of RAM
– Larger virtual memory space for kernel process
• Multicore support
– Up to 8 core CPUs supported
New Memory Manager
• BSP changes needed if
– More than 512 MB of physical RAM required
– To maximize the kernel virtual memory space
• Some increase of Kernel VM space happens without BSP changes
• Supported on x86 and ARM only
– MIPs is limited by the hardware architecture
Supporting More than 512 MB of RAM
• Redirect pfnGetOEMRamTable in OEMInit
PCRamTable OEMGetOEMRamTable(void)
{
// Return address of OEMRamTable.
return &g_oalRamTable;
}
void OEMInit () {
// Support more than 512 MB of RAMg_pOemGlobal->pfnGetOEMRamTable = OEMGetRamTable;
}
OEMRamTable Implementation
// Array of RAM block descriptions
RAMTableEntry RamEntry[] = {
// Physical Addr, Size, Attributes
{ 0xA0000000 >> 8, 0x20000000, 0x00000000 }
};
// -------------------------------
// OEMRamTable is a structure
// -------------------------------
const RamTable g_oalRamTable = {
MAKELONG (CE_MINOR_VER, CE_MAJOR_VER), // Version flag
1, // Count of RAM Table entries
RamEntry // Pointer to RAM table
};
Kernel Virtual Space Improvements
Kernel Virtual Space (CE 6)
Static Mapped
Cached
Static Mapped
Uncached
Kernel XIP DLLs
Object Store
Kernel VM
CPU Specific Area
Ram file system & registry
All XIP DLLs in kernel
Cached access to
physical memory
Uncached access to
physical memory
Kernel Virtual Memory
Shared by all kernel
Servers and drivers
System Trap Area
8000 0000
A000 0000
D000 0000
C000 0000
F000 0000
C800 0000
FFFF FFFF
Compact 7 Kernel Virtual Space (Compat Mode)
Static Mapped
Cached
Static Mapped
Uncached
Kernel VM
CPU Specific Area
Cached access to
physical memory
Uncached access to
physical memory
Kernel Virtual Memory
Shared by all kernel
Servers and drivers
System Trap Area
8000 0000
A000 0000
C000 0000
F000 0000
FFFF FFFF
BSP changes needed for Compatibility Mode
• None
• Kernel virtual space increases from 512 MB to 768 MB
• Compatibly mode keeps traditional mapping to physical space
– 512 MB cached virtual memory to physical memory at 0x8000 0000
– 512 MB uncached virtual memory to physical memory at 0xA000 0000
• Increase comes from removal of dedicated space
– Kernel XIP DLLs
– Object Store
Compact 7 Maximized Kernel Virtual Space
8000 0000
F000 0000
Kernel VM
CPU Specific Area
OEMAddressTable
Kernel Virtual Memory
Shared by all kernel
Servers and drivers
System Trap Area
Cached Static Mapped Area
Uncached Static Mapping Area OEMDeviceTable
FFFF FFFF
BSP changes to maximize Kernel Virtual Space
• Provides close to 1.8 GB of kernel virtual space
– Subtract virtual space needed for device mapping
• New table to describe uncached static physical space
– OEMDeviceTable
• OEMAddressTable then used to describe cached static physical space
• Tell kernel about OEMDeviceTable by inserting flag in OEMAddressTable
Using OEMDeviceTable
• First entry in OEMAddress table has tag and ptr to ODT
• OEMDeviceTable organization
– Like OEMAddressTable, last entry contains all zeros
g_OEMAddressTable:
dd CE_NEW_MAPPING_TABLE, pOEMDeviceTable, 0
dd {FirstVirtAddr}, {FirstPhyAddr}, {Size}
dd {SecondVirtAddr}, {SecondPhyAddr}, {Size}
g_OEMAddressTable:
// Virtual Addr, Phys Addr >> 8, Size, Attributes
dd {FirstVirtAddr}, {FirstPhyAddr}>>8, {Size}, {attr}
dd {NextVirtAddr}, {NextPhyAddr}>>8, {Size}, {attr}
dd 0, 0, 0, 0
Symmetric Multiprocessing Support
• Kernel supports 8 cores
• Takes advantage of new multicore embedded CPUs
– x86, ARM
• No single thread lockup scenarios
– Much more stable systems
• CPU core management API provided
Multiple Core Demonstration
4 cores under load
One core handling a
runaway thread
BSP Support for Multicore
• Mandatory support the following functions
// Called by the kernel before multiprocessing is enabled.
// Runs on the master CPU and starts up all other CPUs.
BOOL OEMMpStartAllCPUs(PLONG pnCpus, FARPROC pfnContinue);
// This function is called by the kernel on each slave CPU. //
// It is the 1st function the kernel calls on the slave
// CPU and it returns the hardware CPUID.
DWORD OEMMpPerCPUInit(void);
// This function sends an interprocessor interrupt.
BOOL OEMSendIPI(DWORD dwType, DWORD dwTarget);
BSP Support for Multicore 2
• Optionally support the following functions
// This function initializes the interlocked function
// table for the OAL. Only override this function if you
// need platform-specific interlocked func initialization.
void OEMInitInterlockedFunctions(void);
// Called when the debugger starts and stops. Timer ISR
// won't execute while the debugger is in a break state,
// but count register will continue to increment. So do
// some special time accounting, or else CurMSec will
// leap forward unexpectedly.
void OALKdEnableTimer(BOOL fEnable);
BSP Support for Multicore 3
• Optionally support the following functions
// This function is called by the kernel to power on/off a
// specific CPU.
BOOL OEMMpCpuPowerFunc(DWORD dwProcessor, BOOL fOnOff, DWORD dwHint);
// This function handles platform-specific interproc intr.
void OEMIpiHandler(DWORD dwCommand, DWORD dwData);
// Called by the kernel to place the CPU(s) in idle state.
// OEMIdleEx is more performant than OEMIdle, and if
// OEMIdleEx is implemented, leave OEMIdle as a stub.
void OEMIdleEx(LARGE_INTEGER *pliIdleTime);
Kernel support for Multicore BSPs
• Use this to send Interprocessor Interrupts to other cores
• Replace disable interrupt calls with the following
• Take care not to…
– Call a synchronization object while holding SpinLock
– No (KITL based) debugging messages while holding SpinLock
void NKSendInterProcessorInterrupt (DWORD dwType,
DWORD dwTarget, DWORD dwCommand, DWORD dwData);
void NKAcquireOalSpinLock (void);
void NKReleaseOalSpinLock (void);
Driver Impacts for New Kernel Memory Layout
• If not using OEMDeviceTable or OEMRamTable
– None!
• If using OEMRAMTable
– Drivers can no longer directly access physical RAM through 8000 0000 kernel mode window
• If using OEMDeviceTable
– Cached and uncached windows may no longer be consistent
Application Impacts due to Multicore
• To take advantage of multicore CPU
– Applications must be recompiled for Compact 7
OR
– Application header marked as compiled for Compact 7
• Otherwise all threads within an application will run on the same CPU core
– For backward compatibility reasons
Summary
• BSP architecture stays the same
– No new hardware, just build file changes
• More RAM available
– Use OEMRamTable to expose additional RAM
• Kernel Virtual Space Expanded
– Review driver source to ensure no problems with new memory format
• Multicore
– Add BSP functions as needed.
– Look to CPU manufacturer for details
Questions…
Doug Boling
Boling Consulting Inc.
www.bolingconsulting.com
dboling @ bolingconsulting.com
© 2011 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
© 2011 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.