Windows Mobile 6.5 Bootloader Mechanics

Windows Mobile 6.5 relies on a structured, multi-stage boot sequence rooted in the Windows Embedded CE 5.2 core architecture. Upon device startup, execution moves through hardware-level reset vectors, proprietary initial loaders, a secondary program loader, and an OEM Adaptation Layer (OAL) before handing execution over to the operating system kernel. This article examines the specific bootloader mechanics, execution stages, and handoff protocols that allowed Windows Mobile 6.5 devices to transition from cold power to a functioning user interface.

Stage 1: Power-On Reset and Hardware Vectoring

When a device is powered on, the processor's program counter points directly to a hardcoded hardware reset vector located in Read-Only Memory (ROM) or internal SRAM, typically at address 0x00000000 or 0xFFFF0000 depending on the ARM architecture used. At this stage, system memory (DRAM) is uninitialized and inactive. The processor executes a minimal set of instructions to disable interrupts, configure basic processor clocks, and jump to the primary boot routine.

Stage 2: Initial Program Loader (IPL)

The Initial Program Loader (IPL) is a tiny, vendor-specific firmware layer stored in NOR flash, secure internal ROM, or the first blocks of NAND flash. Because NAND flash cannot be executed directly, on NAND-based devices the internal boot ROM copies the IPL directly into the processor's limited internal SRAM (often called Steppingstone).

The primary responsibilities of the IPL include:

  • Initializing essential platform hardware, specifically the external memory controller and system DRAM.
  • Establishing basic power management states.
  • Locating the Secondary Program Loader (SPL) in flash storage.
  • Copying the SPL into the newly initialized DRAM and jumping to its execution address.

Stage 3: Secondary Program Loader (SPL) or EBOOT

The Secondary Program Loader (often referred to as SPL in commercial devices or Microsoft's reference EBOOT/Ethernet Bootloader in development kits) is the core bootloader responsible for preparing the Windows Mobile operating system image.

Key mechanics performed by the SPL include:

  • Integrity and Security Checks: On production hardware, the SPL validates the cryptographic signature of the operating system image (ROM) to prevent unauthorized code execution.
  • Boot Mode Detection: The SPL checks hardware flags, such as button combinations held during power-on. If triggered, it switches to USB recovery, bootloader maintenance mode, or a flashing utility instead of the OS.
  • Image Relocation or Mapping: Windows Mobile images are distributed as a collection of partitioned modules packaged into NK.bin or NK.nbf files. If the device uses NOR flash, the bootloader can configure Execute-In-Place (XIP), allowing code to run directly from storage. If using NAND flash, the bootloader reads the OS image into physical RAM at a predefined base address.
  • Transfer of Execution: Once the OS image is verified and mapped in memory, the SPL sets up a jump table or direct pointer to the Windows CE kernel entry point, passing basic boot arguments through shared memory.

Stage 4: OEM Adaptation Layer (OAL) and Kernel Entry

The operating system binary entry point executes the OEM Adaptation Layer (OAL), which acts as the abstraction layer between the device hardware and the generic Windows CE kernel (NK.exe).

The sequence unfolds as follows:

  1. Startup Function: The OAL's assembly-level Startup function runs with the Memory Management Unit (MMU) turned off. It performs final low-level hardware initialization, flushes CPU caches, and builds the physical-to-virtual memory translation tables.
  2. Enabling the MMU: The CPU switches to virtual memory mode, establishing the standard Windows CE 32-bit virtual address space.
  3. KernelStart Call: The OAL calls KernelStart(), permanently handing control over to the Windows CE operating system kernel (NK.exe).

Stage 5: OS Kernel and Subsystem Initialization

Once NK.exe assumes control, it uses OAL-provided hooks (OEMInit) to initialize system timers and interrupt handlers (ISRs). The kernel then mounts the internal file system via filesys.exe, reads configuration parameters from the registry, initializes the device driver manager (device.exe), launches graphics and windowing services (gwes.exe), and finally starts the Windows Mobile shell interface.