Share via

Boot Loader (Compact 7)

  • Article

3/12/2014

The boot loader is responsible for initializing fundamental hardware components, placing the OS image into memory, and jumping to the OS start routine. It resides in nonvolatile memory on the device and can obtain the run-time OS image in a number of different ways, including loading it over a cabled connection such as an Ethernet, USB, or serial connection. Without a boot loader, transferring a run-time image to your device is a slow manual process. The boot loader is used primarily during BSP development.

After the boot loader stores the OS image on the device, you can remove the boot loader from the final product. At this point, the system reset process handles any initialization and jumps to the OS start routine. Hardware platforms that need to perform tasks such as run-time image updates before startup might include the boot loader in the final product.

A boot loader performs the following mandatory tasks:

  • Loads the run-time OS image from a storage device to RAM
  • Jumps to the OS start routine

A boot loader may also perform the following optional tasks:

  • Handles the reset vector
  • Initializes the CPU, including I/O pins
  • Initializes the memory management unit (MMU) for use within the boot loader; the MMU must then be disabled before jumping to the OS
  • Initializes other hardware as needed
  • Performs power-on self test (POST) to identify the devices that are present
  • Displays a splash screen
  • Supports a debug menu
  • Reads from a removable drive
  • Calls another boot loader that loads the OS image via Ethernet or another transport
  • Downloads a new boot loader version and safely replaces itself in nonvolatile memory with the new version

Note

We recommend that you design your boot loader to load both run-time images and boot-loader images, to both RAM and nonvolatile storage, to enable product testing.

The sample BSPs that are provided with Windows Embedded Compact 7 include two sample boot loaders. The original boot loader, based on the BLCOMMON library, is described in this developer guide. It was included with earlier versions of Windows CE and is included in Windows Embedded Compact 7 also. The second boot loader, based on the CE Boot framework, is described in the guide CE Boot Framework. The BLCOMMON boot loader is used by the ARM and MIPS sample BSPs. CE Boot is used by the BSPs that are based on the x86 CPU architecture, which are the CEPC, Virtual CEPC, and eBox BSPs. CE Boot is also implemented for the ARM architecture, although the ARM sample BSPs use the BLCOMMON library, which is described in this guide.

After you develop your boot loader, you will have two binary images: a .bin file and an .nb0 file. The .nb0 file is the boot loader image as it appears in memory on your device, and its size is the maximum amount of memory reserved for the boot loader. You use this file to place the initial boot loader image on the device, using either a built-in monitor program provided by the board manufacturer or with a Joint Test Action Group (JTAG) programmer. After the .nb0 image is stored on the device, it can download and update itself using the smaller .bin file if your boot loader supports that functionality. The .bin file is the most common format for Windows Embedded Compact binary images. This format contains header information that the .nb0 file does not, and it removes the need to pad between records. The .bin file is smaller than the .nb0 file and it does not need to fill the entire memory reserved for the boot loader.

Boot Arguments

The boot loader can pass information to the OS by using the Boot Arguments (sometimes called bootargs) area of memory, which is shared between the boot loader and OAL. Drivers and applications can query the OAL for this information through I/O controls (IOCTLs). You determine the format and contents of the Boot Arguments area. Information that is typically stored in the Boot Arguments includes:

  • Hardware revision number
  • Universally unique identifier (UUID) for the device
  • Settings for debugging and remote tools
  • Network device used for downloading the OS image: base address, interrupt, IP address, subnet mask, and media access control (MAC) address
  • Boot arguments version number, which the OAL checks

The information in Boot Arguments is stored by the boot loader and read by the OAL in the BSP_ARGS structure. 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.
  • A definition of the memory location in boot.bib (see Configuration Files).
  • A definition of the memory location in config.bib (see Configuration Files).
  • A definition of the memory location in an include file shared by the boot loader and the OAL (typically the args.h file in the %_WINCEROOT%\Platform\<Hardware Platform Name>\Src\Inc directory).
  • 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.

See Also

Concepts

BSP Components