C h a p t e r 10 : Firmware
Feature Firmware Software
Definition Program embedded in hardware General-purpose program
Storage ROM / Flash (non-volatile) Hard disk / RAM
Level Low-level (close to hardware) High-level (user-oriented)
Update Difficult / less frequent Easy / frequent
Purpose Controls hardware functions Performs user tasks
Speed Fast (direct hardware control) Depends on OS/system
Example Microcontroller code, BIOS Apps, OS, browsers
10.1 Firmware and Bootloader
Firmware
• Firmware is deeply embedded, low-level software
• It acts as an interface between hardware and application/OS software
• It is stored in ROM (non-volatile memory).
• It executes immediately when power is applied to the system.
• Firmware may remain active even after system initialization
• It supports basic system operations
• he type of firmware used depends on the specific application.
• It can range from:
• Loading a complex operating system, to
• Handing control to a small microkernel.
• Firmware requirements vary from system to system
• Small systems may need minimal firmware just for booting
• A major role of firmware is to provide a stable mechanism to load and boot
the OS.
Bootloader
• A bootloader is a small application program
• It is used to install/load the operating system or application onto the
hardware
• It runs before the operating system starts
• Its role ends once the OS or application begins execution.
• It is temporary in operation (only active during boot process)
• It is commonly part of the firmware.
• It helps in initializing the system and transferring control to the
OS/application.
HAL (Hardware Abstraction Layer)
• HAL is like a translator between software and hardware. Software gives simple
commands, and HAL converts them into hardware operations.
• Hardware abstraction is a technique that hides complex hardware details and
provides a simple interface for software developers to interact with hardware
Application Software
↓
Hardware Abstraction Layer (HAL)
↓
Actual Hardware
(Processor, Memory, GPIO, UART)
Analogy:
• Hardware Abstraction means hiding the complicated hardware details
and giving programmers a simple way to use the hardware.
• When you drive a car:
• You use the steering, brake, and accelerator
• You do not need to know how the engine, gearbox, or fuel injection internally
works
• Ex: without HAL to turn on LED “GPIOA->ODR |= (1<<5);”
• With HAL to turn on LED “LED_ON();” or digitalWrite (LED, HIGH);
10.1.2 Red Hat RedBoot
• RedBoot is a firmware tool developed by Red Hat.
• It is provided under an open source license with no royalties or up front fees.
RedBoot is designed to execute on different CPUs (for instance, ARM, MIPS, SH
(SuperH processor family), and so on).
• It provides both debug capability through GNU Debugger (GDB), as well as a
bootloader.
• The RedBoot software core is based on a HAL.
RedBoot supports these main features:
• Communication—configuration is over serial or Ethernet. For serial, X-Modem
protocol is used to communicate with the GNU Debugger (GDB). For Ethernet,
TCP is used to communicate with GDB. RedBoot supports a range of network
standards, such as bootp, telnet, and tftp.
• Flash ROM memory management—provides a set of filing system routines that
can download, update, and erase images in flash ROM. In addition, the images
can either be compressed or uncompressed.
• Full operating system support—supports the loading and booting of Embedded
Linux, Red Hat eCos, and many other popular operating systems. For Embedded
Linux, RedBoot supports the ability to define parameters that are passed directly
to the kernel upon booting.
10.2 Example: Sandstone
• Sandstone is a minimal bootloader system used to initialize hardware, load the
operating system into memory, and transfer control to the OS
• Sandstone is a minimal static bootloader designed for the ARM Evaluator-7T
platform with ARM7TDMI processor. It initializes the hardware, loads an
application or operating system into memory, and boots it. (ARM7TDMI is a 32-bit
RISC processor core that supports Thumb instructions, debugging features, and
fast multiplication operations, Embedded ICE for embedded systems)
• Note that Sandstone is written entirely in ARM assembler and is a working piece
of code that can be used to initialize target hardware and boot any piece of
software, within reason, on the ARM Evaluator-7T.
• The sandstone source file sand.s is located under the sand/build/src directory.
• The object file produced by the assembler is placed under the build/obj directory.
• The object file is then linked, and the final Sandstone image is placed under the sand/build/image directory.
This image includes both the Sandstone code and the payload.
• The payload image, the image that is loaded and booted by Sandstone, is found under
the sand/payload directory
• For information about the Sandstone build procedure, take a look at the [Link] file under the sand
directory. This file contains a description of how to build the example binary image for the ARM Evaluator-
7T.
10.2.2 Sandstone Code Structure
• Sandstone consists of a single assembly file. The file structure is broken down into
a number of steps, where each step corresponds to a stage in the execution flow
of Sandstone