9
Embedded Bootloader Architecture In general, bootloader architecture depends on: – Processor family, – Chipsets present on the hardware platform, – Boot device, and – OS running on the device. Effects of the processor family on bootloader architecture: – Even when two platforms are based on similar processor cores, the bootloader architecture may differ based on the SoC. – An x86 bootloader might need to switch to protected mode to load a kernel bigger than the 1MB real-mode limit. – Non x86 embedded platforms cannot avail legacy BIOS services. – A bootloader for a device designed around the StrongARM processor has to know whether it's booting the system or waking it up from sleep, because the processor starts execution from the top of its address space. Embedded Bootloaders require fixed functional characteristic.

10
Embedded Bootloaded Features At the minimum, a bootloader is responsible for – Processor- and board-specific initializations, – Loading a kernel, – Initial ramdisk into memory, and – Passing control to the kernel. In addition – Might provide BIOS services (POST, firmware download, passing memory layout and configuration information to the kernel). – Decryption for encrypted firmware images. – Debug monitor to load and debug stand-alone code on to the target. – Failure-recovery mechanism to recoup from kernel corruption. – Require device-specific modifications. – Update capacity through interfaces such as UART, USB or Ethernet. Embedded Bootloaders need to be extensible.

12
Bootstrapping for Embedded Bootloader Bootstrapping is the mechanism to transfer a bootloader image from the host development system to the target's boot device. – Bootstrapping is straightforward on PC-compatible systems. – Embedded devices do not have a generic method for bootstrapping. The boot suite has to be architected into two steps, each loaded at a different address: – The first step (the 128-byte image) is part of processor firmware. Note: Processor-resident microcode (the first step) cannot function as the bootstrapper because a bootstrapper needs to have the capability to program flash memory. Many types of flash chips can be used with a processor, the bootstrapper code needs to be board-specific. – The second step lives in the on-chip SRAM, so it can be up to 2KB. This is the bootstrapper. The bootstrapper downloads the actual bootloader image from an external host to the top of flash memory. The bootloader gets control when the processor powers on in normal operation mode. Many embedded controller chips do not support a bootstrap mode. Instead, the bootloader is written to flash via a JTAG interface. Primarily Embedded Bootloaders do not follow exact steps of System BIOS.

13
Developing Embedded Bootloader Understand the hardware environment – Memory mapping, – I/O mapping, and – Interrupt Vectors. Understanding program loader: – the transition of control from ROM to RAM, – initializing the RAM, and – loading "C" code in RAM then transferring the control to "C" code. Necessary programming and debugging tools. Make sure programming and debugging tools are compatible with the hardware environment. Board design meets the “proper” spec. – Perform some simple tests to verify that the hardware is working. Proper board design is very important for functional embedded bootloader.

24
Reasons and Rational Focus is to connect the flexible BIOS and embedded bootloader, and target the generic IA architecture to meet the end-to-end solution for embedded! BIOS has inherent constraints for embedded systems! Embedded Bootloaders have diversified requirements. Embedded Bootloaders require fixed functional characteristic. Embedded Bootloaders need to be extensible. No common framework for embedded framework to take advantages.. Such as Linux, WinCE, and other embedded OSes. Need a flexible and extensible x86 bootloader. “IA Boot Loader” is a natural progression for Embedded Solutions.