Recommended Boot Loader Functionality (Windows CE 5.0)
The boot loader typically resides in nonvolatile storage on a target device and executes when the system powers up or resets. To get the boot loader on a target device for the first time, developers typically use a JTAG programmer. However, for future boot loader updates they usually have the boot loader itself download and flash new run-time images.
Microsoft recommends that you consider the following functionality when you develop a boot loader. Some hardware platforms might not be able to implement all recommended functionality — for example, if the hardware platform does not support flash memory — but most recommendations are applicable to all hardware platforms.
The boot loader should live in nonvolatile storage, such as flash memory, which can be optionally updated while in the system. In addition, locking the flash memory blocks where the boot loader lives is a good way to help protect the boot loader from corruption.
The boot loader should provide error message output and load status or progress. This is typically done over a serial port connection, such as a COM1 hardware port.The connection settings are 38400 baud, no parity, 8 data bits, and 1 stop bit.
Whenever practical, the boot loader should make use of the support libraries provided by Microsoft. Doing so minimizes the development work and makes it easier to take advantage of updates or new functionality in the support libraries.
The boot loader should provide the ability to load both run-time images and boot loader images, not only to RAM but also to nonvolatile storage, such as flash memory, to support testing in a simulated final product.
Note In order to accommodate a flash memory update, the boot loader will probably need to execute from RAM.
The boot loader should perform checksum checking on the downloaded data and should avoid changing the flash memory contents until the checksum is confirmed to be correct.
The hardware platform initialization code should be shared between the boot loader and the OAL because both must be able to initialize the hardware platform.
If you are developing boot loaders for redistribution with the board support package (BSP), consider the following additional recommendations:
- The boot loader version should be clearly visible somewhere in the output along with the date and time that the boot loader was built.
- The boot loader should have a menu that allows the user to set options, such as Dynamic Host Configuration Protocol (DHCP) or static IP information. The boot loader should store these settings for future use so the user does not have to enter them each time.
- No user input should be required to download the boot loader image when the device powers up. If there is a menu, it should time out and the boot process should proceed without user intervention.
- If the hardware allows it, the boot loader should provide the ability to write to flash memory and update itself with a simple download from Microsoft Platform Builder. No additional tools, special cables, or protocols, such as XMODEM, should be required.
- The boot loader should work with all Platform Builder switches, such as download on reset, jump on reset, download if the boot loader image changed, and clean boot.
- Have a fallback mechanism, such as a built-in ROM monitor, to flash the boot loader again if the download is interrupted or if the boot loader image becomes corrupted. Another alternative would be to support flash programming technology using JTAG.
- If the storage size allows it, include all Ethernet debug drivers in the boot loader image that the user might want.
See Also
Boot Loaders | Hardware Considerations for the Boot Loader
Send Feedback on this topic to the authors