Boot Loader Design (Windows CE 5.0)
The boot loader described in the topic How to Develop a Boot Loader uses Microsoft® Platform Builder to download a file over Ethernet to the target device's RAM before executing it.
The following high-level overview lists the tasks that the boot loader performs in a semi-chronological order, immediately following a CPU reset:
Early CPU initialization.
Enter supervisor mode.
Note This is whatever mode specifies unrestricted access to all hardware and memory. For x86, this would be ring 0 protected mode with a flat memory model, but with memory management unit (MMU) disabled. Some CPUs reset into the correct mode; others must enter it through software initialization.
Clear the instruction and data caches.
Clear the translation look-aside buffers (TLBs).
Drain the write and fill buffers.
Configure and enable the RAM controller.
Ensure that interrupts are cleared and masked.
Initialize any required phase-locked loops (PLLs) or timebases such as RTC and tick counter.
Optionally relocate the run-time image to RAM. The boot loader may initially run in flash memory after reset.
Optionally enable the MMU and caches.
Note It is possible to run with the MMU and caches off, but it requires the Config.bib file of the OS to take this into consideration. This is usually a better approach if the goals are efficiency and code clarity.
Copy the copy-section data to its final location. This instantiates initialized global data.
Create and populate a reserved memory area to be shared with the OS. This boot arguments or boot args area is used to pass along various bits of information to the OS.
Early board-level initialization.
- Set up debug UART.
- Optionally provide a user menu for configuring loader options.
- Initialize the Ethernet controller.
Optionally obtain an IP address for the target from a DHCP server. An alternative would be to assign a static IP address to the device.
Initialize the TFTP connection. Platform Builder uses the TFTP protocol to download .bin files from the development workstation.
Download the .bin file as individual records, then verify each with a checksum, and then store the data where each record indicates it needs to be stored. The operation is slightly different if the run-time image is to be stored in flash memory.
Obtain various user settings from Platform Builder, such as boot clean and whether to establish a passive KITL connection, as well as IP and port address information for various Platform Builder service connections.
Execute the downloaded .bin file by ensuring the system state is configured appropriately and then jumping to the run-time image's startup address.
The boot loader support libraries encapsulate many of the tasks summarized above. For more information about the support libraries, see Boot Loader Support Libraries.
Boot Loader Binary Images
At the end of the boot loader development process described in the topic How to Develop a Boot Loader, you will have two different binary images for the boot loader: a .bin file and an .nb0 file.
The Microsoft Windows® CE binary image data format (.bin) file is the most common format for Windows CE binary images. It is a binary file that consists of a number of individual records with associated per-record bookkeeping data.
The format is convenient for minimizing the amount of data to be downloaded to the target device by removing the need to pad between records. For more information about the .bin file format, see Windows CE Binary Image Data Format.
The .nb0 file format is a raw binary image of the boot loader. The boot loader image is as it appears in the memory on the target device and does not contain the header information that the .bin file includes. The .nb0 file is typically larger than the .bin file.
The .nb0 file is useful for placing the initial boot loader image on the target device. This is usually done with a built-in monitor program provided by the board manufacturer. You can also place the initial boot loader image on the target device through a JTAG connection using a JTAG probe.
Once the .nb0 image is stored on the device, it should be able to download and update itself using the .bin file format from then on.
Hardware Platform Description
The boot loader described in the topic How to Develop a Boot Loader is developed for an example platform containing the following hardware specifications:
- ARM V4I CPU
- 64 MB RAM
- 32 MB Intel Strataflash (28F128)
- A supported Ethernet controller, such as NE2000 or SMC9000. As a simplification for the process described in the how-to topic, the controller is built-in and not a PCI or PCMCIA device.
The following table shows the memory map for this hardware platform.
| Physical address | Length | Description |
|---|---|---|
| 0000.0000 - 01FF.FFFF | 32 MB | Flash |
| A000.0000 - A3FF.FFFF | 64 MB | RAM |
The boot loader design assumes that the CPU will begin fetching code at physical address 0 following a reset.
See Also
Send Feedback on this topic to the authors