Firmware and Bootloader

 The firmware is the deeply embedded, low-level software that provides an interface
between the hardware and the application/operating system level software. It resides in
the ROM and executes when power is applied to the embedded hardware system.
 The choice of which firmware to use for a particular ARM-based system depends
upon the specific application
 The bootloader is a small application that installs the operating system or application onto
a hardware target. The bootloader only exists up to the point that the operating system or
application is executing, and it is commonly incorporated into the firmware.

 The first stage is to set up the target platform—in other words, prepare the environment
to boot an operating system since an operating system expects a particular type of
environment before it can operate.
 Diagnostics software provides a useful way for quickly identifying basic hardware
malfunctions.
 Debug capability is provided in the form of a module or monitor that provides
software assistance for debugging code running on a hardware target. This assistance
includes the following:
 Setting up breakpoints in RAM. A breakpoint allows a program to be interrupted
and the state of the processor core to be examined.
 Listing and modifying memory (using peek and poke operations). Showing
current processor register contents.
 Disassembling memory into ARM and Thumb instruction mnemonics.
  The second stage is to abstract the hardware. The Hardware Abstraction Layer (HAL) is a
software layer that hides the underlying hardware by providing a set of defined
programming interfaces. The HAL software that communicates with specific hardware
peripherals is called a device driver.
 The third stage is to load a bootable image. The ability of firmware to carry out this
activity depends upon the type of media used to store the image. The operating system
image or application image can simply execute directly from ROM.

 Relinquishing control on an ARM system means updating the vector table and modifying
the pc. Updating the vector table involves modifying particular exception and interrupt
vectors so that they point to specialized operating system handlers. The pc has to be
modified so that it points to the operating system entry point address.

ARM Firmware Suite

 ARM has developed a firmware package called the ARM Firmware Suite (AFS). AFS is
designed purely for ARM-based embedded systems. The package includes two major
pieces of technology, a Hardware Abstraction Layer called μHAL (pronounced micro-
HAL) and a debug monitor called Angel.

1. μHAL provides a low-level device driver framework that allows it to operate over
different communication devices (for example, USB, Ethernet, or serial). It also provides
a standard API. API call to access the hardware. μHAL supports these main features:
 System initialization—setting up the target platform and processor core.
Depending upon the complexity of the target platform, this can either be a simple
or complicated task.
 Polled serial driver—used to provide a basic method of communication with a
host.
 LED support—allows control over the LEDs for simple user feedback. This
provides an application the ability to display operational status.
 Timer support—allows a periodic interrupt to be set up. This is essential for
preemptive context switching operating systems that require this mechanism.
 Interrupt controllers—support for different interrupt controllers.

 The second technology, Angel, allows communication between a host debugger and a
target platform. It allows you to inspect and modify memory, download and execute
 images, set breakpoints, and display processor register contents. All this control is
through the host debugger.

 The Angel debug monitor must have access to the SWI and IRQ or FIQ vectors. Angel
uses SWI instructions to provides a set of APIs that allow a program to open, read, and
write to a host filing system. IRQ/FIQ interrupts are used for communication purposes
with the host debugger.

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, 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.

Example: Sandstone
 The implementation is specific to the ARM Evaluator-7T platform, which includes an
ARM7TDMI processor. Table below lists the basic characteristics of Sandstone.
Sandstone Directory Layout
 The directory structure is as shown in Figure below. The structure follows a standard
style that we will continue to use in further chapters. 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.
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 (see Table
below).

Step 1: Take the Reset Exception

Execution begins with a Reset exception. It is the very first instruction executed. sandstone_start
is located at address 0x00000000.

Step 2: Start Initializing the Hardware

• The primary phase in initializing hardware is setting up system registers. These registers
have to be set up before accessing the hardware. For example, the ARM Evaluator-7T has
a seven-segment display, which we have chosen to be used as a feedback tool to indicate
that the firmware is active.

• The default address 0x03ff0000, since this places all the hardware system registers away
from both ROM and RAM, separating the peripherals and memory.
Step 3: Remap Memory
One of the major activities of hardware initialization is to set up the memory environment.
Sandstone is designed to initialize SRAM and remap memory. The platform starts in a known
memory state, as shown in Table

In this step the code consists of two part:

 The first part of the code calculates the absolute address of the routine before remapping
takes place. This address is used by Sandstone to jump to the next routine in the new
remapped environment.
 The second part carries out the memory remapping. The new memory map data is loaded
into registers r1 to r12,

Step 4: Initialize Communication Hardware

Communication initialization involves configuring a serial port and outputting a standard

banner. The banner is used to show that the firmware is fully functional and memory has been
successfully remapped.

The serial port is set to 9600 baud, no parity, one stop bit, and no flow control. If a serial cable is
attached to the board, then the host terminal has to be configured with these settings.

Step 5: Bootloader—Copy Payload and Relinquish Control

The final stage involves copying a payload and relinquishing control of the pc over to the copied
payload. The first part of the code sets up the registers r12, r13, and r14 used in the block copy.

Destination register r13 points to the beginning of SRAM, in this case 0x00000000. The source
register r12 points to the start of the payload, and the source end register r14 points to the end of
the payload. Using these registers, the payload is then copied into SRAM.