A bootloader is a small program that handles the reset vector and starts up a system. Bootloaders are not all equal, so writing about them is difficult to do without discussing the optional things that a bootloader might do. The only reasons to have a bootloader is to provide a mechanism for updating the software on a device or to retrieve the OS from some storage medium and move it to RAM to run which are the “loader” parts of the bootloader. Anything else that a bootloader might do are optional.
The following are some of the common things that a Windows CE bootloader might do:
  • Handle the reset vector
  • Determine the reset reason and handle
  • Initialize the CPU, including I/O pins
  • Initialize the MMU for use within the bootloader, but the MMU must be disabled prior to jumping to the OS
  • Initialize other hardware as needed
  • Power On Self Test (POST)
  • Display a splash screen on the display
  • Support a debug menu to support system boot options and/or hardware debugging
  • Provide support for updating the OS and bootloader, including:
    • Read from a removable drive
    • Download from Ethernet, or other transports
    • Write to some storage device like flash ROM or disk
  • Load the OS from storage device to RAM
  • Jump to the OS
Bootloaders can be written from scratch, written to use BLCOMMON from the Platform Builder shared code, modified from existing code from Platform Builder or third parties. There are also open source bootloaders available like UBoot.
Bootloaders are typically single threaded. They do not typically support interrupt handling. The goal of most bootloaders is to get their work finished quickly and start the OS.
Other notes thanks to my friend Valter Minute (original text in the feedback below):
The bootloader may also be involved in the suspend/resume procedure.  Resume is actually a CPU reset, and the bootloader usually handles the reset vector. When the reset reason is a wake source, the bootloader will jump back to the OS at an address that the Kernel saves to a location that is mutually agreed on by both the kernel and the bootloader (hardcoded address or register.)
 
The bootloader can't be debugged using the same tools that can be used to debug the OS (Platform Builder). To debug the bootloader you need a JTAG emulator on some CPUs. This will make adding complex features inside the bootloader a more difficult.
 
One solution for upgrading the OS image at boot, loading it from an external device (SD card, USB stick etc.) is to use two Windows CE images. The regular OS image and a very small image used only to perform updates.
 
The bootloader will jump to the appropriate OS based on some trigger. Possible triggers include:
  • Jumper
  • Button(s) press during boot
  • System variable set by the “main” OS before soft reset
  • Failure to load the “main” OS
 
The image loading and updating operation can be performed using the features of Windows CE (USB support, USB host drivers, filesystem drivers etc.) and debugged using Platform Builder. Obviously this feature will require some space on your flash memory. The loader OS image can be reduced in size to less than 5 megabytes because it does not require many of the features of the main OS.  Instead it might include some limited UI and full support for all the external mass storage devices that your system can support.
 
Copyright © 2009 – Bruce Eitman
All Rights Reserved