Porting BSP from Win CE 5.0 to 6.0

20 June 2017

A board support package (BSP) is software that implements and supports an operating system (OS) on a standard development board (SDB). It typically consists of a boot loader, OEM Adaptation Layer (OAL), device drivers, and run-time image configuration files.
Windows Embedded CE 6.0 features a completely redesigned kernel introducing a set of new significant features like two device drivers modes (Kernel-Mode and User-Mode), system APIs (Application Programming Interface) placed into kernel-mode DLLs (moved out of their own user-mode processes) or new memory architecture that removes previous limits (up to 32K processes at any one timed with 2 GB of Virtual Memory per process are possible).
Additionally OEM Adaptation Layer code (nk.exe) and the kernel operating system code (kernel.dll) are now separated and can communicate using only strictly defined interfaces.sy.

Features:

Porting BSP for „RMI Alchemy™ DBAu1550™ Development Board” (delivered by BSQUARE Corporation) from Windows CE 5.0 to CE 6.0.

RMI Alchemy™ DBAu1550™ Development Board
Au1550™ security network processor on MIPS32 architecture
New BSP basing on:
- One of existing Win CE 6.0 BSPs for MIPSII processor
- Existing BSP for „RMI Alchemy™ DBAu1550™ Development Board” for Win CE 5.0
Migration process from CE 5.0 to CE 6.0 and to a new IDE (Microsoft Visual Studio 2005 with Platform Builder for CE 6.0 plug-in)
Separating OEM Adaptation Layer (OAL) code from kernel operating system code
Verifying boot loader and device drivers to new CE 6.0 requirements

Changes the Major Modules

OEM Adaptation Layer (OAL) code (nk.exe) is separated from kernel operating system code (kernel.dll)
To improve performance system APIs are moved out of their own user-mode processes and are placed into kernel-mode DLLs instead:
- filesys.dll – Registry, file system and property databases
- gwes.dll – The graphics, windowing and events subsystem
- device.dll – Manages kernel-mode device drivers
Services Manager consists of host process for system services (servicesd.exe) and command-line interface to configure services (services.exe)
New, separate process to manage user-mode device drivers (udevice.exe)

New Memory Architecture

New Memory Architecture removes previous limits

Each process gets its own, truly private process address space (no application process can look into the address space of any other application process)
A theoretical maximum of 32K processes instead of 32 processes at any one timed
Larger address space – 2 GB of Virtual Memory per process instead of 32 MB.

Kernel-Mode Operation

CPU must support two privilege levels: Kernel mode (higher) and User mode (lower)
Only the mixed operating mode is supported – all applications loaded into user-mode memory, and all OS components loaded into kernel-mode memory (that is slower than running the system entirely in kernel mode but environment runs more robustly and more securely)
Some system libraries have both a user-mode and a kernel-mode incarnation to minimize the cost of calling across the privilege boundary (e.g. Core system library – coredll.dll & k.coredll.dll).

Two Device Drivers Modes

Kernel-Mode Drivers – functionality of the old device.exe moved into the kernel to increase system performance. These drivers must be very well tested and robust so they do not crash the kernel and entire system
User-Mode Drivers – a new more protected user device process (udevice.exe) to increase robustness and security – suitable for untrusted third party drivers or unstable drivers that can be tested in user-mode and then moved to kernel-mode. Each single (or a group of) user-mode driver(s) could be hosted on a separate instance of udevice.exe.

New API limitations

Functions not supported any more – SetKMode, SetProcPermissions / GetCurrentPermissions, MapCallerPtr, MapPtrToProcess
VirtualCopy function – in case of calling VirtualCopy in user mode drivers, the reflector will check addresses to make sure your driver is allowed to access requested physical address
OAL layer can not use kernel functions that are not exported.

Impact of the new CE 6.0

Impact of the new CE 6.0 on existing drivers & software

Binary compatibility for applications – well behaved applications will work with/ little/ no changes (memory is allocated with the same APIs, and data is still stored using 32-bit virtual memory pointers). Large data blocks allocations with a call to VirtualAlloc instead of shared memory allocation functions (ex. MapViewOfFile) from the earlier CEs
Compatibility maintained through CoreDLL with minimized impact on Win32 APIs and changes hidden in API libraries
Applications using undocumented techniques (such as passing handles or pointers between processes) will likely have to be modified
Main changes will be in drivers and services:
- In most cases drivers will migrate with little work
- In the case of non-standard programming solutions or in the case of undocumented functions usage it can be necessary to driver internal built or its interface reorganize
- Drivers that still need to access (read/write) data in an application’s address space need to run in kernel mode (because SetKMode function and setting process permissions to access other processes are no longer supported)
- Device driver could be run in user mode through the use of a user-mode device driver process – udevice.exe

The new BSP bases on one of existing BSPs for MIPSII processor delivered by Microsoft together with Platform Builder for CE 6.0 plug-in to Microsoft Visual Studio 2005 and on existing BSP for „RMI Alchemy™ DBAu1550™ Development Board” for Win CE 5.0. Migration process from CE 5.0 to CE 6.0 and to a new IDE (Microsoft Visual Studio 2005 with Platform Builder for CE 6.0 plug-in) included steps presented below.

Porting OAL Layer

Clone an existing BSP for „RMI Alchemy™ DBAu1550™ Development Board” CE 5.0
Modify the OAL directory structure to reflect the separation of the OAL, KITL, and the Kernel
Use the new names for the executables being built (e.g. nk.exe, kitl.dll)
Split nk.exe (OAL with KITL + Kernel) from CE 5.0 into separate modules:
- nk.exe – startup code and the OAL implementation
- kernel.dll – OAL-independent kernel implementation provided by Microsoft
- kitl.dll – platform-specific KITL support
Rename / Add a couple of OAL and KITL functions that are expected by the Kernel (OEMGLOBAL structure defines all the functions and variables that the OAL must implement)
OAL / kernel interface is well defined through shared structures and direct calls to internal Kernel, OAL and KITL functions are no longer possible – use dedicated interface from NKStub.lib (wrapping kernel interface – exported functions and variables defined in NKGLOBAL structure) and call functions KITLIoctl(), OEMIoControl().

Porting Drivers Layer

The following OEM and development board specific drivers were verified and adjusted to CE 6.0 requirements:

Au1550 PSC AC97 Audio, PSC I2S Audio – audio drivers
Alchemy ATI Rage XL, Silicon Motion Voyager – display drivers
Alchemy Ethernet, Alchemy PCMCIA, Alchemy Serial, Alchemy USB (OHCD) host controller, Alchemy USB Function, Au1550 PSC SPI Controller – bunch of drivers providing support for communication buses and interfaces allowing interactions with external devices
Highpoint HPT371/372 IDE Controller, Au1550 NAND FLASH Controller – storage devices

Project

Development environment: Platform Development Tools integrated into Visual Studio® 2005 (replaces earlier standalone Platform Builder)
Programming language: C, C++ (for some drivers)
Size: 5 man-months