Firmware for Embedded

Computing
Define “Firmware”
 Firmware is a computer program that is embedded in a
hardware device, for example a microcontroller. It can
also be provided on flash ROMs or as a binary image
file that can be uploaded onto existing hardware by a
user†.
 Firmware is stored on non-volatile solid-state memory
 Typical functions of a firmware:
 Booting and running a system (a board or a chip)
 Providing basic I/O services
 Providing debugging services
 Providing backdoor for system recovery/maintenance

2/42
Recursive System Layout

 A typical system printed circuit board (PCB):

OS
PCB boot Image
(may be
SDRAM: on Flash)
 Operating Systems
 Applications
ROM: I/O Device ICs
System bootcode (analog)

System BUS

MCU IC (SoC)
Device
I/O

RISC I/O IPs
Processor Device RISC
Local BUS

Local BUS
Core IPs Core
(digital) Onchip

cache Onchip DRAM

Onchip bootcode
bootcode Custom
Onchip Accelerator
Onchip Logic (IP)
SRAM
SRAM

3/42
Board-level vs. Chip-level Firmware
 Typical examples:
 Board-level: BIOS, bootloader, debug agent, etc.
 Chip-level: microcontroller codes for an MPEG codec chip,
USB controller chip, etc.
 Firmware code size:
 Board-level: ranges from several KB to several MB
 Chip-level: as small as possible to reduce cost

4/42
Board-level Firmware and OS
 There is a lot of similarity between board-level
firmware and an operating system (OS)
 Provides I/O interfaces for (application) program
 Loads and executes program images
 Helps program development
 In the good old days, the entire OS of a computer can
be a firmware (e.g. Apple II)
 Today, more and more consumer electronics have a
firmware-based OS (e.g. mobile phones, PDAs)

5/42
Operating Systems Components
 Process Management
 Who gets to use the CPU?
 Memory Management
 Who gets to use the runtime memory?
 File System
 How to retrieve/store data?
 I/O (Sub)-system
 How to talk to the peripherals?
 Can be part of the file system (e.g. Unix)
 Graphics (Multimedia), Windowing, and Events
Subsystem

6/42
Typical Architecture of an OS
user applications

OS libraries
user space
kernel space
system call interface

file system process manager

buffer control Inter-process
scheduler memory manager
communication

device drivers

hardware abstraction layer (HAL)

hardware
peripherals DSP MCU

7/42
Can We Get away with “OS”?
 There are two kinds of tasks a typical embedded
system runs:
 Background operations:
 Runs the main application of the embedded system
 Handling routine (synchronous) tasks
 Usually called task level
 Foreground operations:
 Handling asynchronous events
 Usually called interrupt level

8/42
Foreground/Background Systems
Background Foreground

code
execution

ISR†

Time
ISR ISR

† ISR stands for Interrupt Service Routine

9/42
F/B System vs. Full OS
 Why do we need an OS for embedded systems?
 Handling complex scheduling problems for background tasks
 Reduced development cost for a family of product
 Easy extensibility (for new hardware)
 Support for third party applications
 Have someone to blame if things don’t work … (e.g. Microsoft)
 In general, a firmware-based F/B system should be
good enough for most embedded devices
Industrial Firmware Example: AFS
 Firmware are typically custom-designed for each
embedded systems
 However, many firmware codes can be recycled for different
applications/projects
 The ARM Firmware Suite (AFS) is a collection of
libraries and utilities designed as an aid to application
and OS development on ARM-based platforms†

† AFS is free as long as it is used for ARM-based platforms!

AFS Components
 µHAL libraries:
The ARM Hardware Abstraction Layer; the basis of AFS
 Flash library and utilities:
Library and utilities for programming on board flash memory
 Angel:
A remote debugging monitor for ADS
 µC/OS-II:
AFS
includes
a port of
the
multitaski
ng
kernel,
µC/OS II,
using
µHAL API
 Addition
Logical Organization of AFS

 AFS also shields the hardware detail from user

applications, however, it is much thinner than an OS

User applications AFS utilities General

C and C++ libraries

AFS support
AFS board-specific HAL routines routines

Development Board Specific

HAL
 The µHAL libraries mask hardware differences
between platforms by providing a standard layer of
board-dependent functions
 Example of µHAL functions:
 System (processor, memory, and buses) initialization
 Serial ports initialization
 Generic timers
 Generic LEDs
 Interrupt control
 Code/data access in flash memory
 Memory management (cache and MMU)
Example: Using HAL (1/2)

 Getting Board Information:

infoType platformInfo;

/* who are we? */

uHALr_GetPlatformInfo(&platformInfo);
uHALr_printf("platform Id :0x%08X\n",
platformInfo.platformId);
uHALr_printf("memory Size :0x%08X\n", platformInfo.memSize);
uHALr_printf("cpu ID :0x%08X\n", platformInfo.cpuId);

 LEDs Control:
int idx;
int count = uHALr_InitLEDs(); /* turn off all the LEDs */

for (idx = 0; idx < count; idx++) uHALr_SetLED(idx);

Example: Using HAL (2/2)

 Installing a Timer:
static int OSTick = 0;
void TickTimer(unsigned int irq) { OSTick++; }

int main(int argc, char *argv[])

{
uHALr_InitInterrupts(); /* Install trap handlers */
uHALr_InitTimers(); /* Initialize the
timers */

uHALr_printf("Timer init\n");
if (uHALr_RequestSystemTimer(TickTimer, "test") <=
0)
{
uHALr_printf("Timer/IRQ busy\n");
}

uHALr_InstallSystemTimer(); /* Enable the interrupt

*/

/* Get the interval per tick */

interval = uHALir_GetSystemTimerInterval();
}
Firmware Operation Modes
 An embedded system application operates in one of
two modes:
 Standalone:
A standalone application is one that has complete control of
the system from boot time onwards
 Semihosted:
A semihosted application is one for which an application or
debug agent, such as Angel or Multi-ICE, provides or
simulates facilities that do not exist on the target system
uHALr_SetLED(0);

#ifdef SEMIHOSTED
/* All done, give semihosted a chance to break in … */
uHALr_printf("Press a key to repeat the test.\n");
uHALr_getchar();
#endif
Typical Firmware Images

 A typical prototype board with AFS

User System-dependent
User application hardware
flash Debug Agent
Switches
Default application LEDs
AFS in (e.g. boot I/O
monitor)
boot flash Serial
Boot switcher port
Flash memory
Development board
Weakness of Thin Firmware
 A system build upon a thin firmware, such as AFS,
has the following weaknesses:
 Can only implement F/B systems: no multithreading for the
applications
 No device driver model: adding new hardware requires
extension of system call API
 Selection of different applications can only be done via boot
switcher
Deeply-Embedded OS
 Sometimes, we need a little extra functions in the
firmware to implement a powerful F/B systems
 Multi-threading for the background task (but still allowing
only single process)
 Installable device drivers (the “installation” may happen
before the build time)
 Componentized model for building a custom system
 More flexible foreground task management
 Remains small (otherwise, we can use a full-blown OS)
eCos: A Deeply Embedded OS
 eCos stands for Embedded Configurable Operating
System
 eCos is an “application-oriented” OS: The OS can be
configured for a specific application/platform
combination (e.g. digital security camera)
 eCos is something between a “full” OS and a thin
firmware
eCos Features (1/2)
 Embedded Configurable Operating System
 Developed and maintained by RedHat
 Not Linux-based
 Under eCos license (similar to GPL)
 Current version 2.0
 Minimum footprint : about 50 Kbytes
 Single address space for all threads
 Real-time support
eCos Features (2/2)
 eCos is different from other Embedded OS
 Dynamic memory management is not part of the kernel
 Device drivers are handled as “packages“ as well
 eCos kernel is an “optional” package of the OS. It is only
required when multi-threading support is required for
the application
 eCos is linked with the user application as a single runtime
image!
“Open” Embedded OS Spectrum†

GNU
Server Platforms Communication Client Platforms
Infrastructure
Thin clients Deeply embedded
• Internet
• File Server • Routers
• Filters STB HH OA Mobile Pager

Linux eCos
AFS
Embedded Linux
eCos Supported Hardware
 Architectures:
 ARM, CalmRISC, FR-V, H8, IA32, M68K, Matsushita AM3x, MIPS,
NEC V8xx, PowerPC, SPARC (Leon), SuperH
 Devices:
 Flash: AMD, ATMEL, Intel, Sharp
 Ethernet: AMD, Cirrus Logic, Intel, Motorola, Natioanl
Semiconductor, SMSC, VIA
 Seriel: Motorola, 1655x, 8250
 USB: Intel SA-11x0 on-chip, NEC uPD985xx on-chip
 RTC: DS-1742
 See http://sources.redhat.com/ecos/hardware.html for a
complete list of the supported platforms
Componentized Build Environment

 eCos components required for a custom build can be

selected using a GUI build tool
Typical eCos Usage

 Typical eCos board-level Image (could be for chip-

level bootcode as well)

User User application System-dependent

hardware
(linked with eCos image)
flash Switches
LEDs
RedBoot I/O
boot flash (bootloader + debug agent) Serial port
Ethernet
Accelerator

Flash memory
Development board
RedBoot – the Boot Loader for eCos
 RedBoot -- RedHat embedded debug and bootstrap loader
 Based on eCos HAL
 Support boot scripting
 Simple command line interface
 Support flash & network booting of OS
 Support BOOTP, DHCP
 Support TFTP, X/Y-modem for program download
 Support GDB for remote debugging via serial or Ethernet
connections
 Source code:
 http://sources.redhat.com/redboot/
eCos Kernel
 Support multi-threading embedded applications:
 The ability to create new threads in the system, either during
startup or when the system is already running
 Control over the various threads in the system, for example
manipulating their priorities
 A choice of schedulers, determining which thread should currently
be running
 A range of synchronization primitives, allowing threads to interact
and share data safely
 Integration with the system’s support for interrupts and
exceptions
eCos Kernel Is Optional
 For simple foreground/background (F/B) systems, the
eCos kernel package can be skipped
 F/B applications have a central polling loop, continually
checking all devices and taking appropriate action when I/O
occurs
 RedBoot is one of such eCos applications
 However, RedBoot with network support includes the kernel
since the TCP/IP stack uses multithreading internally
eCos Schedulers
 eCos support two types of task scheduler
 Bitmap scheduler
 Multi-level queue (MLQ) scheduler
 The number of priority levels is configurable --
the default is 32
 Low priority thread only runs if all higher priority
threads are blocked
Bitmap Scheduler
 Only allows one thread per priority level, so if the
system is configured with 32 priority levels then it is
limited to only 32 threads
 Bitmaps can be used to keep track of which threads
are currently runnable, waiting on a mutex, or other
synchronization primitive
 Bitmap scheduler is fast and totally deterministic
 Does not support SMP and priority inversion
prevention
MLQ Scheduler
 The MLQ scheduler allows multiple threads to run at
the same priority
 Each priority level maintains a queue of threads
 Timeslicing is used among threads in same priority queue
 Timeslicing can be enabled/disabled at kernel build time
 Operation of finding the highest priority queue with
runnable thread is expensive
 Default behavior is LIFO, which does not guarantee highest
priority queue will be examined next; in this case MLQ is
only used to increase the number of simultaneous threads
 MLQ scheduler also support strict priority queuing but the
system’s dispatch latency is worse
eCos Synchronization Primitives
 Mutexes
 Condition variables
 Counting semaphores
 Mail boxes
 Event flags (binary semaphores)
Sync. Support in Device Drivers
 The eCos common HAL package provides its own
device driver API which contains some of the above
synchronization primitives
 If the configuration includes the eCos kernel package
then the driver API routines map directly onto the
equivalent kernel routines
 If the kernel package is not included and the
application consists of just a simple F/B system then
the driver API is implemented entirely within the
common HAL
Interrupt Handling
 Kernel uses a two-level approach to interrupt
handling:
 Associated with every interrupt vector is an Interrupt Service
Routine or ISR, which will run as quickly as possible
 However an ISR can make only a small number of kernel
calls, and it cannot make any call that would cause a thread
to wake up
 If an ISR detects that an I/O operation has completed it can
cause the associated Deferred Service Routine (DSR) to run
and make more kernel calls, for example, to signal a
condition variable or post to a semaphore
Interrupt Translation†
 eCos translates different interrupt jump table
mechanisms to a common approach
 Each hardware vector executes a trampoline code
that makes an indirect jump via a table to the actual
handler called the Vector Service Routine (VSR)
 The trampoline code performs the absolute minimum
processing to identify the exception source, and jump
to the VSR
 The VSR is responsible for saving the CPU state and
handle the exception or interrupt
eCos HAL & Kernel

Application Application Application

Thread

Dev Drv Dev Drv

DSR

HAL Kernel (optional)

ISR
VSR
Hardware
eCos HAL Principles
 eCos kernel itself is largely implemented in C++, but
the HAL is implemented in C and assembly to
enforce portability
 All interfaces to the HAL are implemented by CPP
macros
 The HAL provides simple, portable mechanisms for
dealing with the hardware of a wide range of
architectures and platforms
HAL Structure (1/2)
 Common HAL
 Generic debugging functionality, driver API, eCos/ROM
monitor calling interface, and tests.
 Architecture HAL
 Architecture specific debugger functionality
 Exception/interrupt vector definitions and handlers
 Cache definition and control macros
 Context switching code
 Assembler functions for early system initialization
 Configuration options
HAL Structure (2/2)
 Variant HAL
 Extensions to the architecture code (cache, exception/interrupt)
 Configuration options
 Drivers for variant on-core devices
 Platform HAL
 Early platform initialization code
 Platform memory layout specification
 Configuration options (processor speed, compiler options)
 Diagnostic IO functions
 Debugger IO functions
 Platform specific extensions to architecture or variant code (off-core
interrupt controller)
 Auxiliary HAL
Discussions
 Thin firmware such as AFS is less and less popular
for embedded systems
 If the application platform of a device is based on an
open standard (e.g. J2ME or Android), a deeply
embedded OS kernel such as eCos is a better choice
than Linux, WinCE, BSD Unix, …, etc. for complex
embedded systems
 For multimedia, feature-rich functions, just leave it to the
portable system middleware
 Software is the key to high-value consumer
electronics