Chapter 10

Firmware

Optimization Technique in Embedded System

(ARM)
LiangAlei@SJTU.edu.cn, 2008 April
 Overview

• Firmware is an important part of any

embedded system
– Since it is frequently the first code to be ported and
executed on a new platform.
– Firmware can vary from being a complete software
embedded system to just a simple initialization and
Bootloader routine.

• Agenda
– Firmware & Bootloader
– General Process of a firmware
– ARM Firmware Suite
– Redboot (Redhat)
– Sandstone (Sloss)
10.1 Firmware and Bootloader
 Definitions

• We realize that the use of terms may differ among

engineers, but we will use the following
definitions

– The firmware : 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.
» It can remain active after initialization to support basic
system operation.

– The bootloader is a small application that installs the

operating system or applications 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.
 Block Diagram of Firmware
Over The Air (FOTA)
(FOTA is a technology used to remotely update the firmware of embedded
devices via a wireless connection — usually over mobile networks, Wi-Fi, or the
internet.)
 Firmware
• What it is: Software that acts as a
bridge between the hardware and
higher-level software (like operating
systems or applications).
• Where it lives: In ROM (Read-Only
Memory) or Flash Memory.
• When it runs: Automatically executes
when power is applied.
• Purpose: Handles low-level operations
(e.g., reading sensors, controlling
motors, managing memory).
BASIC HVAC System

This image is property

of 1.bp.blogspot.com.
 Example:
In a smart thermostat, the
firmware would:

• Read temperature sensors,

• Control the HVAC(heating, Ventilation,
air-conditioning) system,
• Communicate with the user interface
(e.g., buttons or touchscreen).
• Even if the thermostat isn’t connected
to the internet or running complex
apps, the firmware still ensures the
core functionality works.
 Bootloader

• What it is: A small program that loads

and starts the main firmware or
operating system.
• Where it lives: Usually in a reserved
section of ROM/Flash, often part of
the firmware.
• When it runs: Right after power is
turned on or after a reset.
• Purpose: Initialize hardware and load
the main program.
 Example:
In the same smart thermostat,

when the device powers up:

•The bootloader checks if there's a valid
firmware to run.
•It might allow firmware updates (e.g.,
over Wi-Fi or USB).
•Once the firmware is validated or
updated, the bootloader transfers
control to it and then exits.
 Abstraction of Firmware Execution
Flow

• To help understand the features of different

firmware implementations, we have a
common execution flow.
Firmware execution flow.
 I-a. Identify the platform

• It’s common for the same executable

to operate on different cores and
platforms.
– In this case, the firmware has to identify and
discover the exact core and platform it is
operating on.
» CP15:r0 = processor type, manufacture
name
» Platform identification: a set of particular
peripheral.
 I-b. Diagnosing

• Diagnostics software provide a useful way for

quickly identifying basic hardware
malfunctions.
• Debug capability is provided in the form of a
module or monitor.
– Setting up breakpoints in RAM;
– Listing and modifying memory (peek & poke);
– Showing current processor register contents;
– Disassembling memory into ARM or Thumb mnemonics.
• Interactive method
– CLI (command line interpreter) (via RS-232)
– A dedicated host debugger (via LAN + C/S)
• Unless the firmware has access to the internal
hardware debug circuitry, only RAM image can
be debugged through a software debug
mechanism.
 II. HAL

• 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 peripheral is call a device
driver.
» A device driver provides a standard
application programming interface (API) to
read and write to a specific peripheral.
 III. Load a bootable image

• The ability of firmware to carry out this

activity depends upon the type of media used
to store the image.
– Note that NOT all operating system images or
application images need to be copied into RAM, they
could be executed directly from ROM (XIP).
– FFS: flash ROM filing system.
– Network File System
• Image Format
– Plain binary: doesn’t contain any header or debug
information.
– Executable and Linking Format (ELF)
» developed for UNIX, and replaced the Common
Object File Format(COFF).
» ELF files come in three forms: relocatable,
executable, and shared object.
– Compressed image
 IV. Relinquish Control

• This is where the firmware hands over

control of the platform to an operating
system or application.
– Note that NOT all firmware hands over control.
Alternatively, the MIL (machine independent
layer) or HAL part of firmware can remain active.
This layer expose, through SWI mechanism, a
standard application interface for specific
hardware devices.
• Relinquishing control means
– Updating the vector table and modifying the PC.
– Passing Environment Data Structure (EDS) to
some sophisticated OS, e.g., Linux.
» EDS fields: memory size, MMU type, etc.
 10.1.1 ARM Firmware Suite

• ARM Firmware Suite (AFS)

– Support ARM processors including Intel’s Xscale and
StrongARM
– Two technologies: uHAL and Angel (monitor)
• micro-HAL and API
– System Initialization
» Target platform and processor core
– Polled serial Driver
» Communication with host
– LED Control (for Indicating)
» Display operational result
– Timer (for preemptive context switching)
» Setting up Periodic Interrupt
» Context switching
 10.1.1 ARM Firmware Suite
(cntd.)
– Interrupt Controller (IC) (many types supported)
» Supports different interrupt controller
• Angel
– Communication between host debugger and target
platform(debug/develop )
– SWI instructions provide APIs-open, read, and write to
a host filing sytem (via SWI)
– IRQ/FIQ interrupts used for communication purposes
with the host debugger.
 10.1.2 Redboot
• RedBoot
– Redhat, Open Source License
– CPU: ARM(Advanced RISC Machines),
MIPS(Microprocessor without Interlocked Pipeline
Stages), SH(Super Hitachi)
– HAL is heart of Redboot

• It provide both GDB (GNU debug) and

Bootloader
• RedBoot supports three main features
– Communication: serial-X-Modem with GNU,
» Ethernet- TCP, bootp, telnet, tftp
– Flash ROM memory Management: set of filing system
routines- Download, Update, erase images in flash ROM
– Full OS Support: loading and booting of embedded
Linux, eCos (Redhat)
» Passing parameters directly to the kernel
10.2 Example: Sandstone

A minimal system
 A Real Case: Sandstone

• It carries out only the following task

(simple)
– Setting up target platform;
– Loading a bootable image;
– Relinquish control to OS.

• Implementation
– It is specific to the ARM Evaluator-7T platform.
– This example shows you How a simple platform
be set.
 10.2.1 Directory layout of
Sandstone

• Directory Structure in Sandstone

 Directory layout of Sandstone
• 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
pay load.
• 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
readme.txt
 10.2.2 Sandstone Code
Structure

• Sandstone consist 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.
 10.2.2.1 Take the Reset
Exception
 Execution begins with a Reset exception.
Only the reset vector entry is required in the
default vector table. It is the very first
instruction executed.
 Apart from the reset vector all the vectors,
branch to a unique dummy handler—a branch
instruction that causes an infinite loop.
It is assumed that no exception or interrupt
will occur during the operation of Sandstone.
 The reset vector is used to move the
execution flow to the second stage.
 10.2.2.1 Take the Reset
Exception
– AREA start,CODE,READONLY
– ENTRY
– Sandstone_start
– B sandstone_init1
– B ex_undef
– B ex_swi
– B ex_pabt
– B ex_dabt
– NOP ; bad code (will fall through)
– B int_irq
– B int_fiq

– ex_undefB ex_undef ; loop forever

– ex_swi B ex_swi
– ex_dabt B ex_dabt
– ex_pabt B ex_pabt
– int_irq B int_irq
– int_fiq B int_fiq
 10.2.2.1 Take the Reset
Exception

• The results of executing step 1 are

the following:
■ Dummy handlers are set up.
■ Control is passed to code to initialize
the hardware.
 10.2.2.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.
• Before we can set up the segment display, we
have to position the base address of the
system registers to a known location.
• Note
– SYSTEM is a self-reference register. Its default
address is 0x3ff00000 (arch-dependent).
10.2.2.2 Start Initializing the
Hardware
– Consequently, all the microcontroller
memory-mappedregisters are located as an
offset from 0x03ff0000. This is achieved
using the following code:
– SYSCFG EQU 0x03FF0000

– sandstone_init1
– LDR r3, =SYSCFG
– LDR r4, =0x03FFFFA0 ; b[31:16]=base,
[15:0]=cfg
» ; Disable both the “cache” and “write-
buffer”
– STR r4, [r3]
– ……...
– B sandstone_memorycode
10.2.2.2 Start Initializing the
Hardware
– LDR r3, =SYSCFG
In this case, we have picked the default address
0x03ff0000, since this places all the hardware system
registers away from
both ROM and RAM,separating the peripherals and
memory.
10.2.2.2 Start Initializing the
Hardware
– LDR r4, =0x03FFFFA0 ; b[31:16]=base,
[15:0]=cfg
– ; Disable both the “cache” and
“write-buffer”
– Upper 16 Bits (Bits 31–16) → 0x03FF
– Meaning Start looking at system config
registers from 0x03FF0000
– Lower 16 Bits (Bits 15–0) → 0xFFA0
– Meaning Bit 7 = 1 → Write buffer is enabled
– Bit 6 = 0 → Cache is disabled
10.2.2.2 Start Initializing the
Hardware
– The results of executing step 2 are the
following:
– ■ Thesystemregisters are set from a
known base address—0x03ff0000.
– ■ Thesegmentdisplay is configured, so
that it can be used to display progress.
 10.2.2.3 Remap Memory

• As you see,
– when the platform is powered up, only ROM is
assigned a location in the memory map.
– The two SRAM bank (0 and 1) are not available.

• We should
– bring in the two SRAM banks, and
– remap the ROM to a new location
 Remap the ROM, and Setup
SRAM
– LDR r14, =sandstone_init2
– LDR r4, =0x1800000
– ADD r14, r14,r4 ; calculate the absolute
address
– ADRL r0, memorymaptable_str ; get address of table
– LDMIA r0, {r1-r12}
– LDR r0, =EXTDBWTH ; =(SYSCFG + 0x3010)
– STMIA r0, {r1-r12} ; setup DBus Width
– MOV pc, r14 ; JUMP to remapped memory (*)
– memorymaptable_str
– DCD rEXTDBWTH ; ROM0(Half), ROM1(Word), ROM1(Word), rest Disabled
– DCD rROMCON0 ; 0x1800000 ~ 0x1880000, RCS0, 4Mbit, 4cycle, ROM
– DCD rROMCON1 ; 0x0000000 ~ 0x0040000, RCS1, 256KB, 2cycle,
SRAM1
– DCD rROMCON2 ; 0x0040000 ~ 0x0080000, RCS2, 256KB, 2cycle,
SRAM2

• * Question: Here, ROM has already remapped to higher memory

space, how can this instruction “MOV pc, lr” be fetched?
 10.2.2.3 Remap Memory

LDR r14, =sandstone_init2

LDR r4, =0x1800000
ADD r14, r14,r4

–The first part of the code calculates the absolute

address of the routines and sandstone_init2
before remapping takes place.
–This address is used by Sandstone to jump to the
next routine in the new remapped environment.
 10.2.2.3 Remap Memory
– ADRL r0, memorymaptable_str ; get address of
table
– LDMIA r0, {r1-r12}
– LDR r0, =EXTDBWTH ; =(SYSCFG + 0x3010)
– STMIA r0, {r1-r12} ; setup DBus Width

– The second part carries out the memory

remapping. The new memory map data is
loaded into registers r1 to r12, from a structure
pointed by memorymaptable_str.
– This structure, using the registers, is then
written to the memory controller offset 0x3010
from system configuration register.
 10.2.2.3 Remap Memory
–memorymaptable_str
– DCD rEXTDBWTH ; ROM0(Half), ROM1(Word), ROM1(Word), rest
Disabled
– DCD rROMCON0 ; 0x1800000 ~ 0x1880000, RCS0, 4Mbit, 4cycle,
ROM
– DCD rROMCON1 ; 0x0000000 ~ 0x0040000, RCS1, 256KB,
2cycle, SRAM1
– DCD rROMCON2 ; 0x0040000 ~ 0x0080000, RCS2, 256KB,
2cycle, SRAM2

– MOV pc, r14 ; JUMP to remapped

memory
This jump is achieved by taking advantage of the ARM
pipeline. Even though the new memory environment is
active, the next instruction has already been loaded into the
pipeline. The next routine can be called by moving the
contents of register r14 (the address sandstone_init2) into
the pc.
10.2.2.3 Remap Memory
 10.2.2.3 Remap Memory
The results of executing step 3 are the following:
■
– Memory has been remapped as shown in Table
10.5.

– pc now points to the next step. This address is

located in the newly remapped flash ROM.
10.2.2.4 Initialize Communication Hardware

• Communication initialization involves

– Configuring a serial port, and
– Outputting a banner message on console

• The serial port is set to

– 9600 baud(bits per second),
– no parity(No extra parity bit for error checking),
– one stop bit(After each character (byte) is sent,
there’s one short stop signal.
(Marks the end of one character.)),
– no flow control(Data is sent freely without
special control signals like "Request to Send" and
"Clear to Send" (hardware flow) or (XON =
Resume, XOFF = Pause) (software flow).)
10.2.2.4 Initialize Communication Hardware
 10.2.2.5 Bootloader
Copy Payload and Relinquish Control

–sandstone_load_and_boot

–// Section 1 : Copy payload to address 0x00000000

– MOV r13,#0 ; destination addree

– LDR r12,payload_start_address ; start
address
– LDR r14,payload_end_address ; end address

– The first part of the code sets up the registers r12, r13, and
r14 used in the block copy. The bootloader code assumes
that the payload is a plain binary image that requires no
deciphering or uncompressing
 10.2.2.5 Bootloader
Copy Payload and Relinquish Control

– block copy
– LDMIA r12!,{r0-r11}
– STMIA r13!,{r0-r11}
– CMP r12,r14
– BLE 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.
 The source end register r14 points to the end of the
payload.
 Using these registers, the payload is then copied into
SRAM.
 Relinquish Control

– // Section 2 : Relinquish control over to the payload

– MOV pc,#0 ;

Control of the PC is then relinquished to the

payload by forcing the PC to the entry address
of the copied payload. For this particular
payload the entry point is address 0x00000000.
The payload now has control of the system.
 Relinquish Control

– // Section 1 : Copy payload to address 0x00000000

– MOV r13,#0 ; destination addree

– LDR r12,payload_start_address ; start address
– LDR r14,payload_end_address ; end address

– block copy
– LDMIA r12!,{r0-r11}
– STMIA r13!,{r0-r11}
– CMP r12,r14
– BLE block_copy

– // Section 2 : Relinquish control over to the payload

MOV pc,#0 ;

– payload_start_address
– DCD startAddress
– payload_end_address
– DCD endAddress
Relinquish Control
 10.3 Summary
• This chapter covered the firmware
– We define firmware as the low-level code that interfaces the
hardware with an application or operating system.
– We also define bootloader as the software that loads an
operating system or application into memory and relinquishes
control of the PC to that software.
– We introduced the ARM Firmware Suite (AFS) and RedBoot.
– Next, we looked at a firmware example called Sandstone.
» Sandstone initialized the hardware and then loads and
boots an image following this procedure:
• Take the reset exception
• Starts initializing the hardware; sets the system register’s base address
and initializes segment display hardware.
• Remaps memory; ROM address = high, and SRAM addr = 0x00000000.
• Initializes the communication hardware output on the serial port.
• Bootloader – loads an image into SRAM and relinquishes control of the PC
to the image (PC=0x00000000).

• We now have a fully initialized ARM7TDMI embedded

system.