UNIT 4

SYLLABUS
Firmware & Boot loader
Embedded Operating Systems
RTOS CONCEPTS

1
 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, which
can range from loading and executing a sophisticated
operating system to simply relinquishing control to a small
microkernel.
• The bootloader is a small application that installs the
operating system or application onto a hardware target. 2
 Can the embedded system exist without
firmware and bootloader?

• No, an embedded system typically cannot exist without firmware and a bootloader. These
components are fundamental to the operation of an embedded system, especially if the
system has a microcontroller or microprocessor at its core. Here's why:
• Firmware: Firmware is a type of software that is permanently stored in a device's
memory, typically in non-volatile memory like Flash memory. It provides the embedded
system with the instructions and code needed to perform its specific functions. Firmware
is responsible for controlling hardware components, handling inputs and outputs, and
managing various aspects of the embedded system's operation.
• Without firmware, an embedded system would lack the essential software that defines its
purpose and functionality. It's like the brain of the embedded system, and it tells the
hardware how to operate.

•
 Can the embedded system exist without
firmware and bootloader?(conti)

• Bootloader: A bootloader is a small program that initializes the hardware, loads

the firmware into memory, and then starts the execution of the firmware. It's
often the first software component to run when the embedded system is
powered on or reset. The bootloader is essential for the system to start and run
the firmware.
• Without a bootloader, there would be no way to load the firmware into
memory, and the embedded system wouldn't be able to start executing its
intended functions. Bootloaders are crucial for updating or replacing firmware
as well.
• In summary, firmware and a bootloader are integral components of an
embedded system. Firmware provides the instructions and logic for the
system's operation, while the bootloader ensures that the firmware can be
loaded into memory and executed. Together, they enable the embedded system
to function as designed.
Firmware Execution Flow

5
 Setup Target Platform
• Diagnostics software provide a useful way for quickly identifying basic
hardware malfunctions.
• Debug capability is provided in the form of a module or monitor.
a)Setting up breakpoints in RAM;
b)Listing and modifying memory (peek & poke);
c)Showing current processor register contents;
d)Disassembling memory into ARM or Thumb mnemonics.
• Interactive method:CLI (command line interpreter):Debug capability is
provided in the form of a module or monitor. The CLI is commonly available
on the more advanced firmware implementations. It allows user to change the
operating system to be booted by altering the default configurations through
typing commands at a command prompt
 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 called a device
driver. A device driver provides a standard
application programming interface (API) to read
and write to a specific peripheral.
 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
• ARM processors are normally found in small devices that include flash
ROM. A common feature is a simple flash ROM filing system (FFS),
which allows multiple executable images to be stored.
• A popular image format for ARM-based systems is Executable and
Linking Format (ELF). This format was originally developed for UNIX
systems and replaced the older format called Common Object File Format
(COFF). ELF files come in three forms: relocatable, executable, and shared
object.
 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 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.
• 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. It provides support for a number of boards and processors including the Intel
XScale and StrongARM processors. The pack- age includes two major pieces of technology, a Hardware
Abstraction Layer called μHAL (pronounced micro-HAL) and a debug monitor called Angel.
μ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.

• μ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.

 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 proto- col 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.
 Example: Sandstone
• It carries out only the following tasks: set up target platform
environment, load a bootable image into memory, and relinquish
control to an operating system.
• The implementation is specific to the ARM Evaluator-7T
platform, which includes an ARM7TDMI processor.
• Sandstone summary:

12
 Sandstone directory layout:

• 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 file under the sand directory.
This file contains a description of how to
build the example binary image for the
ARM Evaluator-7T.

13
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
 Step 1: Take the Reset Exception

• Execution begin with a Reset

exception.Only the reset vector entry
is required in the default vector
table. It is the very first instruction
executed.

• All the vectors, apart from the reset

vector, branch to a unique dummy
handler—a branch instruction that
causes an infinite loop.
• sandstone_start is located at address
0x00000000.

15
 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,
chosen to be used as a feedback
tool to indicate that the firmware
is active. Before the segment
display is set up, base address of
the system registers is positioned
at 0x03ff0000. 16
 Step 3: Remap Memory
• Sandstone is designed to initialize SRAM and
remap memory.
• The platform starts in a known memory
stat(initial) as shown in table.

• As we see, when the platform is powered up, only flash

ROM is assigned a location in the memory map.
• The two SRAM banks (0 and 1) have not been initialized and
are not available.
17
 Step 3…
• The next stage is to bring in the two SRAM banks and
remap flash ROM to a new location.
• This is achieved using the following code:

18
 Step 3…

• Once remapping complete, the new memory

map as shown in table.

19
Step 4: Initialize Communication Hardware
• Communication initialization involves configuring a serial
port and outputting a standard banner (code is not shown).
• 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.
• Banner:

20
 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. This is achieved using
the code shown here.
• 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 uncompressing

4
 Embedded Operating
system

Fundamental Components of Embedded operating system

• There is a common set of low-level components, each carrying out a
prescribed action, that form an operating system.
• Initialization is the first code of the operating system to execute
and involves setting up internal data structures, global variables, and
the hardware.
• For hardware initialization an operating system sets up various
control registers, initializes the device drivers and, if the operating
system is pre emptive, sets up a periodic interrupt.

22
 Fundamental Components …
• Memory handling involves setting up the system and task stacks.
• The positioning of the stacks determines how much memory is available for either the
tasks or the system.
• The decision as to where the system stack is placed is normally carried out during
operating system initialization.
• Setting up the task stack depends upon whether the task is static or dynamic.
• The method for handling interrupts and exceptions is part of the architecture design
of the operating system.
• Designers have to decide how to handle the various exceptions: Data Abort, Fast Interrupt
Request, Interrupt Request, Prefetch Abort, Reset, and Software Interrupt (SWI).

23
 Fundamental Components …
•A preemptive operating system requires a periodic
interrupt, which is normally produced by a counter/timer
device on the target hardware. As part of the initialization
stage, an operating system sets the periodic interrupt
frequency.
• This is normally achieved by setting a specified value into one
of the counter/timer memory-mapped registers. When
activated, the counter/timer will start to decrement this
value.
• Once the value reaches zero, an interrupt is raised. This
interrupt is then handled by the appropriate ISR for periodic
interrupts. The ISR first reinitializes the counter/timer with
24
 Fundamental
Components
…
• The scheduler is an algorithm that determines which task is to be
executed next.
• Once the scheduler is complete, the new and old tasks have to be
swapped with a context switch.
• The last component is the device driver framework—the mechanism an
operating system uses to provide a consistent interface between
different hardware peripherals.
• For an application to access a particular peripheral there has to be a
specific device driver available.

25
Example: Simple Little Operating System(SLOS)
• SLOS is designed to execute on an ARM7TDMI: Evaluator-7T
• SLOS is loaded and executed using the Sandstone firmware.
SLOS is a preemptive operating system
• Assumptions:
-SRAM is required to be located between 0x00000000 to
0x00080000, and the base configuration registers must be set to
address 0x03ff0000.
- ARM processor is in SVC mode when the firmware hands over
control because SVC mode is a privileged mode to set up the
stacks in IRQ and system mode.
Each task in SLOS requires its own stack. All the tasks operate in
user mode; thus, a task can read but not write to the cpsr. The
only way a task can change to a privileged mode is to use an
SWI instruction call. 26
 SLOS Directory Layout

• The directory layout for SLOS is similar to the Sandstone firmware layout
• There are six subdirectories under slos/build/src that hold all the operating system source files.
• The slos/build/src/core directory includes the miscellaneous utility files, as well as the command line
interpreter (CLI) sources.
• Specific code for a platform is stored under a directory with the name of that platform. For instance, the
code for the Evaluator-7T is stored under directory e7t.
• The slos/build/src/e7t/devices directory holds all the device driver files, and the
slos/build/src/e7t/events directory holds the files that handle services, exceptions, and interrupts.
• Finally, the slos/build/src/apps directory holds all the applications/tasks for a particular
configuration. For instance, for the Evaluator-7T implementation, there are three applications/tasks.