The document discusses how to add more functionality to an embedded system without increasing the package size. It recommends layering the firmware code into platform-dependent, system-dependent, and OS/application layers. Each layer should be able to load the layer above it. It also suggests including robust debug capabilities to help troubleshoot problems early in the boot process using a small, lightweight debug monitor. Layering the code in this way allows for a modular debugging approach rather than a monolithic one.

1. How to put 10lbs of functionality into a 5lb package.
How to put 10lbs of functionality
into a 5lb package.
By
Marc Karasek
Senior Firmware Engineer
marckarasek@ivivity.com
ESC-370 San Jose California Spring 2007 Page 1 of 7

2. How to put 10lbs of functionality into a 5lb package.
How to put 10lbs of functionality into a 5lb package..........................................................1
Overview: ............................................................................................................................3
Layering Your Code :..........................................................................................................4
In looking at the boot process for today’s embedded designs, more functionality is
being added earlier in the process. Some examples are : power status, OS flash image
integrity and system recovery. Each of these requires a different amount of software
support. Some will require notification to the user of the status and some will require
interaction with the user. Most of these features are in addition to bringing the system
up to a point where an OS and/or application can run. ..................................................4
Many embedded designs have one large firmware image that is both the boot code and
the OS/application rolled into one. This monolithic approach to the code has many
limitations associated with it. Some examples are : ......................................................4
Upgrading the firmware is a potentially dangerous problem that could leave the device
nonfunctional. ................................................................................................................4
The ability to maintain multiple images, a requirement in some cases, is impossible
without some form of hardware support. ........................................................................4
Each layer should have a mechanism to load the layer above it. It should also have as
much debug capability in the code as possible. (See next section). .............................5
Having split the monolithic firmware image into these layers allows us to move from a
monolithic way of debugging the code to a more modular approach. ............................5
Debugging without the Bloat :.............................................................................................5
Most embedded firmware has some form of debug monitor capabilities in it. This is
usually accessed by a key sequence during boot time or through a menu system that is
the default interface for the device. This debug monitor usually requires that the
majority of the system be functional in order to work. This does not lend itself to
debugging problems that occur early in the boot process and is usually used to help
debug OS/applications. In order to debug the hardware/boot code better we need a
monitor that needs little to no resources to run. One such monitor is Micromon
developed for the MIPs family of chips by IDT. This monitor as a standalone binary is
only 13K in size, yet it provides all of the features needed to help debug during system
bring-up. It could very easily be adapted to another processor. It only needs 8 GP
registers for the stack and input positions........................................................................5
Using the split firmware above, .....................................................................................5
Assumptions : ......................................................................................................................5
Definitions : ........................................................................................................................6
ESC-370 San Jose California Spring 2007 Page 2 of 7

3. How to put 10lbs of functionality into a 5lb package.
Overview:
In today’s embedded designs more and more functionality is being crammed
into smaller packages. As this functionality increases so does the amount of
upper layer “OS” software needed to run it. With cost always a driving
factor, flash devices used for the system software need to be as small as
possible. A combination of cost + increased system functionality means less
space available for the boot/initialization code. At the same time there is
pressure to also add functionality too the boot/initialization code. As an
embedded systems engineer, you need to be able to understand the
implications associated with adding this functionality. Will you need to
increase the size of the flash part, can you live without this feature or is it a
must have or can you squeeze some more space from your current flash?
You must become an “embedded systems engineer” to know what affect a
specific feature request will have on the system.
Knowing what the choices you have when a feature request hits your inbox
is only the first step. You also need to be able to communicate this
information to your managers/executives. It maybe that the request for this
wiz-bang new feature has come from your manager and he/she is just
convinced that the end product will be a complete disaster without it. You
must be able to explain what are the options associated with adding this new
feature. We have all heard the line one time or another that ‘it is only code
and what is the big deal’.
If we are prepared ahead of time to deal with these requests, then ‘putting 10
lbs of functionality into a 5 lb package’ will be a lot easier. There are a few
things an engineer can do up front that will help:
1) Layering the firmware, with a clear plan for what each layer of the
code is responsible for.
2) Adding debug code while minimizing the impact to the boot process
and avoiding code bloat.
3) Maintaining multiple firmware images in a system with a minimal
footprint in the boot process.
ESC-370 San Jose California Spring 2007 Page 3 of 7

4. How to put 10lbs of functionality into a 5lb package.
Layering Your Code :
In looking at the boot process for today’s embedded designs, more
functionality is being added earlier in the process. Some examples are :
power status, OS flash image integrity and system recovery. Each of
these requires a different amount of software support. Some will
require notification to the user of the status and some will require
interaction with the user. Most of these features are in addition to
bringing the system up to a point where an OS and/or application can
run.
Many embedded designs have one large firmware image that is both the boot
code and the OS/application rolled into one. This monolithic approach
to the code has many limitations associated with it. Some examples
are :
• Upgrading the firmware is a potentially dangerous problem that could
leave the device nonfunctional.
• The ability to maintain multiple images, a requirement in some cases,
is impossible without some form of hardware support.
A better way to deal with this is to modularize or layer the code. Look at
what initialization needs to be done and break this up into sections. From
this see what is platform dependent and what is platform agnostic. This is
your first point of layering. If you have any system initialization code, this
would become the next layer. The final layer would be the OS/application
for the device. So we now have three layers for our firmware (see Figure 1).
Platf orm Dependent Code
Sy stem Dependent Code
OS/Application
ESC-370 San Jose California Spring 2007 Page 4 of 7

5. How to put 10lbs of functionality into a 5lb package.
Figure 1 : Firmware Layering
Each layer should have a mechanism to load the layer above it. It should
also have as much debug capability in the code as possible. (See next
section).
Having split the monolithic firmware image into these layers allows us to
move from a monolithic way of debugging the code to a more modular
approach.
Debugging without the Bloat :
Most embedded firmware has some form of debug monitor capabilities in it.
This is usually accessed by a key sequence during boot time or through
a menu system that is the default interface for the device. This debug
monitor usually requires that the majority of the system be functional in
order to work. This does not lend itself to debugging problems that
occur early in the boot process and is usually used to help debug
OS/applications. In order to debug the hardware/boot code better we
need a monitor that needs little to no resources to run. One such
monitor is Micromon developed for the MIPs family of chips by IDT.
This monitor as a standalone binary is only 13K in size, yet it provides
all of the features needed to help debug during system bring-up. It
could very easily be adapted to another processor. It only needs 8 GP
registers for the stack and input positions.
Using the split firmware above,
Assumptions :
The assumptions for this paper are that the reader has a good understanding
of embedded systems and an understanding of the general boot process for
microprocessors. An understanding of C is expected and some assembly
would be helpful.
Layering your code :
ESC-370 San Jose California Spring 2007 Page 5 of 7

6. How to put 10lbs of functionality into a 5lb package.
Definitions :
Boot Device :
Reset Vector :
ESC-370 San Jose California Spring 2007 Page 6 of 7

7. How to put 10lbs of functionality into a 5lb package.
As embedded engineers we are faced with pressures to put the maximum functionality into
our systems within the minimal footprint.
What this means from a boot code perspective is the initialization code is being squeezed into
a smaller footprint so that the upper layer applications have more room. At the same time,
we are being asked to add additional functionality.
[Understanding how to add as much functionality into your boot code, and the tradeoffs
associated this.] Presentation on how to modularize your boot code into different layers. This
will include examples of code using the MIPS processor. How to add debug output into the
boot process without slowing down the process and fitting into the available boot device being
used. How to satisfy requirements of having multiple boot images in a system with a minimal
footprint in the boot process.
ESC-370 San Jose California Spring 2007 Page 7 of 7