五、How To Develop A BootLoader （2）

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.

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.