Boot Loader Overview (Compact 2013)
3/26/2014
Windows Embedded Compact 2013 includes two different boot loader frameworks. The original boot loader framework, based on the BLCOMMON library, is described in the topic BL Common Boot Framework. The newer framework, based on a collection of CE Boot libraries, is described in CE Boot Framework. This section introduces concepts shared by both frameworks and discusses aspects of the boot loader that BSP developers should consider.
Boot Loader Functions
The boot loader takes a device from the point of power-on reset (POR) to the point where the OS starts. Boot loaders typically initialize fundamental hardware components, place the OS image into memory, and jump to the OS startup routine. Boot loaders usually reside in nonvolatile memory on the device and can obtain the OS image in a number of different ways, including loading it over a wired connection such as an Ethernet, USB, or serial.
Boot loaders used during BSP development need to have different functions than production boot loaders. The following table provides an overview of some common functions performed by each of the two different boot loader types.
Boot loader functions |
Development boot loaders |
Production boot loaders |
|---|---|---|
Jumps to the OS startup routine |
Mandatory |
Mandatory |
Initializes the CPU, including I/O pins |
Mandatory |
Mandatory |
Initializes the memory management unit (MMU) to enable virtual memory support within the boot loader (the MMU must then be disabled before jumping to the OS) |
Optional |
Optional |
Initializes other hardware needed for the tasks to be performed |
Mandatory |
Mandatory |
Displays a splash screen |
Optional |
Optional |
Supports a debug menu |
Recommended |
Not recommended |
Reads the OS image from local, nonvolatile storage |
Optional |
Optional |
Calls another boot loader that loads the OS image via Ethernet or another transport for development or manufacturing purposes |
Optional |
Optional |
Downloads a new boot loader version and safely replaces itself in nonvolatile memory with the new version |
Optional |
Not recommended |
Boot Arguments
The boot loader passes information to the OS in two ways: static information is passed through a dedicated flash memory region, and dynamic information is passed through a shared memory region referred to as the boot arguments area (or sometimes simply bootargs). The boot loader can update the boot arguments each time the device boots, and drivers and applications can query the OAL for this updated information through input/output controls or IOCTLs.
Information that is typically stored in the boot arguments includes:
- Boot arguments version number. (The OAL checks the version number to make sure the boot loader and the OS are compatible.)
- Hardware revision number.
- Universally unique identifier (UUID) for the device.
- Settings for debugging.
- Network device used for downloading the OS image: base address, interrupt, IP address, subnet mask, and media access control (MAC) address.
In some cases, such as when the OS image updates, the OS can use the boot arguments area to pass update request details back to the boot loader.
The boot loader typically stores the boot arguments information in the BSP_ARGS structure. If you choose to store the boot arguments in a different structure, be sure the both the boot loader and the OAL can locate and access this information.
You must determine the format and contents of the boot arguments area. To create and use a boot arguments area, you need:
- A definition of the structure’s contents in an include file shared by the boot loader and the OAL.
- Reserved space in the boot loader address space for this structure. This reserved space is typically defined in boot.bib.
- Reserved space in the OS/kernel address space for this structure. This reserved space is typically defined in config.bib.
- A definition of the memory location in an include file shared by the boot loader and the OAL. This include file is typically the args.h file in the %_WINCEROOT%\Platform\<Hardware Platform Name>\Src\Inc folder.
- Source code in the boot loader that fills in the structure’s contents and stores it in the shared memory location.
- Source code in the OAL that reads the structure’s contents from the shared memory location.
Boot Loader Files
After you develop your boot loader, you will have at least one binary image file in the form of .bin file. The .bin file is a condensed format that uses very little memory and loads quickly, but it requires a program, such as another boot loader, that can understand its binary record format. You will usually use the .bin file format throughout development.
Another common boot loader file format is the .nb0 file. The .nb0 file contains the boot loader image as it should appear in your device’s memory. This file takes up the exact amount of memory that the device has reserved for the boot loader, so the file can be stored on the device with minimal processing. During development and production, this image is often written directly to nonvolatile storage by using a JTAG programmer or fail-safe loading mechanism. You can create an .nb0 file by adding ROMSTART, ROMSIZE, and ROMWIDTH settings to the binary image builder (.bib) file that defines your boot loader (typically boot.bib). For more information about .bib files, see Binary Image Builder (.bib) File