Understanding embedded-system-boot techniques

Boot-up, the sequence of steps that a system performs between when you switch on power and load applications, is simple in theory but often complex in reality. The main job of a boot loader is to load the operating system, but software and hardware engineers view this process in different ways.

The system-boot process, although potentially simple in concept, becomes complex when you consider various implementation options. Windows XP provides a popular case study of a classic boot sequence. Numerous hardware and software techniques provide different means of getting post-reset-configuration data to the processor. Primary and secondary boot options comprehend different startup and kernel-code sizes, read- and write-performance expectations, and other variables. U-Boot (Universal Boot Loader) is a powerful open-source tool that deserves consideration in Linux-based designs.

Understanding embedded-system-boot techniques imageTo load a program into memory, you must first load a program into memory. The bootup process, often a complex multistep sequence involving numerous substeps, solves this problem. Any boot-up process, including booting up Windows, Linux, or an embedded RTOS (real-time operating system), begins with the application of power to the system and the subsequent removal of system reset. During POR (power-on-reset) assertion, you may have to reconfigure hardware peripherals if operational values differ from those of default settings. Embedded microcontrollers, for example, often offer various hardware-reset-configuration schemes.

Over the last several decades, booting up has evolved from a simple DOS-based step to more complicated multiple-operating-system choices or even peripheral-based boot-up techniques. A USB (Universal Serial Bus) interface, for example, allows you to boot up a disk image from an external storage device; this approach is increasingly popular in industrial- and embedded-system applications because it provides abundant flexibility. In the case of software corruption, for example, in which a system requires the reloading of new firmware, the USB technique allows a service engineer to simply copy new software onto a flash drive and boot from it. The service department therefore saves the thousands of dollars in expenses that it would otherwise incur in transporting the equipment to the manufacturer for repair.

To enable system-boot flexibility both from USB, PCIe (Peripheral Component Interconnect Express), and SDHC (secure-digital-high-capacity) interfaces and from conventional memory devices requires in-depth hardware and software capabilities. Opensource firmware—specifically, the UBoot (Universal Boot Loader) utility, which finds wide use in embedded-system platforms—may also be of value. The Linux-based boot loader can automatically boot up the operating system; alternatively, it allows a user to manually run explicit commands to start the operating system, and it supports booting from a variety of interfaces (see sidebar “The U-Boot”).

Windows XP system boot

Understanding embedded-system-boot techniques figure 1A simple x86 boot sequence is fairly self-explanatory (Figure 1). Windows XP follows comparable steps, albeit with more sophistication. The boot sequence begins with the application of system power; the processor remains in reset. When all voltages and current levels are acceptable, the power supply sends a power-good signal to the processor. The next step, POR negation, takes place when the availability of the good-power signal negates the processor reset to allow the CPU to begin operation. The CPU points to the ROM boot address and begins executing the BIOS (basic-input/output-system) code. The ROM BIOS then performs POST (power-on self-test), a basic test of core hardware to verify basic performance. The boot-up process then reports any errors that occur at this point using beep codes because the video subsystem has not yet initialized.


The next step is video-card initialization, during which the BIOS searches for a video-card adapter by scanning memory addresses C000:0000 through C780:0000 to find a video ROM. The video test initializes and tests any discovered video adapter, potentially along with its video memory, and displays configuration information. If a “cold” start is taking place, the ROM BIOS executes a full POST. If it is a “warm” start, the boot-up process skips the memory-test portion of the POST.

The CMOS now reads from the BIOS. During this step, the BIOS locates and reads configuration information stored in the CMOS. A small coin battery cell on the motherboard typically maintains the CMOS, a small—typically, 64-byte area of memory—on the motherboard. The CMOS memory stores information such as date, time, and peripheral-boot order. If the first bootable disk is a fixed disk, the BIOS examines its first sector for an MBR (master boot record). The MBR comprises a partition table, which describes the layout of the fixed disk, and a partition-loader code, which includes instructions for continuing the boot process. The boot, or partition, loader then examines the partition table for an active partition. The partition loader searches the first sector of that partition for a boot record. The boot process than checks the active partition’s boot record for a valid boot signature. If it finds one, it executes the boot-sector code as a program.

The NTLDR (New Technology Loader) for Windows, a hidden system file that resides in the root directory of the system partition, controls the loading of Windows XP. During NTLDR’s initial phase, it moves the processor from real mode to protected mode, enabling 32-bit memory accesses and turning on memory paging. It then loads the appropriate minidrivers to allow NTLDR to load files from a partition formatted with any of the file systems that Windows XP supports, including FAT (fileallocation table)-16, FAT-32, and NTFS (New Technology File System).

If the boot-initialization file resides in the root directory, NTLDR reads its contents into memory. If the file contains entries for more than one operating system, NTLDR suspends the boot sequence, displays a menu of choices, and waits for the user to make a selection. NTLDR then continues the boot-up process by locating and loading the DOS-based New Technology executable file to perform hardware detection. After selecting a hardware configuration, NTLDR begins loading the Windows XP New Technology kernel file. During this process, the screen clears, and a series of white rectangles subsequently progresses across it. NTLDR now loads device drivers that are marked as boot devices. Before performing this load, NTLDR relinquishes control of the computer.

At this point, the system displays a graphics screen with a status bar indicating the load status. During later initialization phases, the system cannot accept device interrupts. The I/O manager also begins to load the remainder of the system drivers, picking up where NTLDR left off. The last task for this initialization phase is to launch the session-manager subsystem, which is responsible for creating the user-mode environment. The session-manager subsystem then loads the Windows device driver, which implements the graphics subsystem. Windows XP boot is not complete until a user has successfully logged onto the system. The Windows log-in file begins the log-in process, which the kernel loads as a service, and displays the log-on dialogue box.