Partager via

Recommended Boot Loader Features

  • Article

The boot loader typically resides in nonvolatile storage on the target device and executes at system power-on/reset (POR). To get the boot loader on the target device for the first time, a JTAG programmer is typically used. However, future boot loader updates are usually handled by using the boot loader itself to download and flash any new OS images.

Consider the following recommended boot loader features when developing a boot loader. Some platforms may not be able to implement all recommended features — for example, if the platform does not support flash — but most recommendations are applicable to all platforms.

  • The boot loader should live in nonvolatile storage — for example, flash — that can be optionally updated while in the system. Locking the flash blocks where the boot loader lives is also a good way to help protect the boot loader from possible corruption.

  • The boot loader should provide load status or progress and error message output. This is typically done over a serial port (physical COM1) and 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 will minimize the development work required and will make it easier to take advantage of fixes or new features in the support libraries.

  • The boot loader should provide the ability to load both OS images and boot loader images, not only to RAM but also to nonvolatile storage, such as flash, to support testing in a simulated final product configuration.

    Note   In order to accommodate a flash update, the boot loader will most likely need to execute from RAM.

  • The boot loader should perform checksum (CRC) checking on the downloaded information and should avoid changing the flash contents until the checksum is confirmed to be correct.

  • The platform initialization code should be shared between the boot loader and the OAL since both physically need to know how to initialize the 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 provide a menu that allows the user to set configuration options, such as DHCP or static IP information. The boot loader should store these settings for future use so the user does not need to enter them each time.
  • No user input should be required to get the boot loader image to download when the device is powered 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 and update itself with a simple download from 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.
  • There should be 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 JTAG.
  • If the storage size allows it, plan to include all Ethernet debug drivers in the boot loader image that the user may use.

See Also

Boot Loaders | Hardware Considerations for the Boot Loader

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.