High Robustness
Platform
Final Report
August 1, 2003
Darryl Gamroth 0123949
dgamroth@engr.uvic.ca
CEng 499A Project
University of Victoria supervisor:
Dr. Daler Rakhmatov
Industry supervisor:
Bruce Jenner
Bootloader
for
x86
Executive Summary
This report is a summary of the progress made on a high reliability/secure bootloader for General
Hydrogen Corporation as done for the CEng499A senior design project.
This project comprised of three parts: basic low level platform functionality, providing a secure
way to verify program binary images, and finally the design and construction of debugging
hardware to assist in the development of the system.
For the first part, RedHat’s RedBoot was ported to the development hardware (an AMD Élan
SC520 x86 compatible microcontroller) and tested for its suitability for this project and to provide
the main framework for the application.
Secondly an additional framework was added onto RedBoot to provide the capability of having
signed program binary images.
The Message Digest 5 (MD5) algorithm is used to create a
unique fingerprint for the application and that fingerprint is signed using the RSA public key
encryption system.
Finally a custom JTAG controller board was designed to provide quick programming of flash to
quicken the development cycle. A Cypress AN2131S USB slave controller was used to control the
peripheral and a Texas Instruments SN74LVT8980A was used as the JTAG test bus controller.
i
Table of Contents
Executive Summary ..................................................................................................................i
Introduction............................................................................................................................1
Bootloader ..........................................................................................................................2
Low-level Initialization ......................................................................................................3
Application Signing ..............................................................................................................5
MD5 Fingerprint ...............................................................................................................6
RSA Algorithm ..................................................................................................................6
JTAG Hardware ................................................................................................................. 10
Why JTAG? .................................................................................................................... 10
JTAG Hardware Design ................................................................................................... 10
Conclusions .......................................................................................................................... 14
Recommendations................................................................................................................. 15
Bibliography ......................................................................................................................... 16
Appendices ........................................................................................................................... 17
Table of Figures
Figure 1 RedBoot ROM Monitor architecture [2] ........................................................................2
Figure 2 Bootloader firmware flowchart ....................................................................................4
Figure 3 RedBoot command monitor prompt .............................................................................5
Figure 4 RedBoot: invalid application ........................................................................................8
Figure 5 RedBoot: successfully identifying an image ..................................................................9
Figure 6 USB JTAG schematic ................................................................................................ 12
Figure 7 Target board (left) attached to USB JTAG (right) ....................................................... 13
Figure 8 JTAG test program ................................................................................................... 14
ii
Introduction
General Hydrogen Corporation sponsored the work for this project for a new hydrogen dispenser
system. To ensure that certain safeguards are met the software, although not part of the safety
system, was determined to be "as safe as possible".
To meet this goal an off-the-shelf
bootloader was to be used as a starting place and the necessary modifications made to it. This
reduced the need to create a system from scratch and be able to leverage existing technologies.
1
Discussion
Bootloader
“RedBoot is a complete bootstrap environment for embedded systems. Based on the eCos
Hardware Abstraction Layer, RedBoot inherits the eCos qualities of reliability, compactness,
configurability, and portability.
RedBoot allows download and execution of embedded applications via serial or Ethernet,
including embedded Linux and eCos applications. It can be used for both product development
(debug support) and in deployed products in the field (flash update and network booting).
Ethernet download and debug support is included, allowing RedBoot to retrieve its IP parameters
via BOOTP or DHCP, and program images to be downloaded using TFTP. Images can also be
downloaded over serial, using X- or Y-modem.
RedBoot can be used to communicate with GDB (the GNU Debugger) to debug applications via
serial or Ethernet, including the ability to interrupt a running application started by GDB.
An interactive command-line interface is provided to allow management of the Flash images,
image download, RedBoot configuration, etc., accessible via serial or Ethernet. For unattended or
automated startup, boot scripts can be stored in Flash allowing for example loading of images
from Flash or a TFTP server.”[1]
Figure 1 RedBoot ROM Monitor architecture [2]
2
The reason for choosing RedBoot was simple, it already provided a proven framework for
downloading software onto a platform as well as support for a generic x86 PC platform. What
needed to be added were the low level support routines to get the AMD Élan to behave as a
generic x86 PC and the security oriented application signing.
Low-level Initialization
As shown in Figure 1, RedBoot utilizes a hardware abstraction layer to keep the Bootloader
application portable between architectures. The hardware abstraction layer is provided by the
RedHat’s eCos real time operating system; as an added bonus, when the abstraction layer is
written both a bootloader and operating system are available for use. Initial development of this
project did exactly that, the hardware abstraction layer was written to conform to the guidelines
of porting eCos to a new variant of an existing architecture.
Unfortunately as product
development continued it was determined by management that the application being loaded by
the bootloader must re-initialize the platform to its desired state to ensure safety. For the sake
of code reuse, the initialization code was broken out into a library for use by both the application
and the bootloader.
Various application notes from AMD were used as a basis of the system initialization library, in
particular the SDRAM sizer application note which determines the configuration of the SDRAM
installed in the system and configures the memory controller. Before control can be turned over
to RedBoot, the following hardware must be properly configured:

Memory controller (SDRAM)

General purpose bus configuration

Chip select configuration

Interrupt steering controller

Programmable I/O configuration
3
Reset
Basic Hardware
Initialization
No
Re-program
jumper set?
Yes
Command Monitor
No
Boot Timeout?
Yes
Re-program
jumper set?
Yes
Wait for image
transfer
Xmodem transfer
of image
No
GH
Development
jumper set?
No
Yes
Yes
No
No
Valid
application?
Valid
application?
Ethernet load
Re-program
FLASH
Start Program
Stop, wait for reset
Yes
Stop, wait for reset
Figure 2 Bootloader firmware flowchart
Several modifications were made to RedBoot to remove functionality that would commonly be
available but due to security concerns were removed. Features such as raw binary, S-Record and
4
ELF executable support were removed, along with commands which can modify the contents of
system memory. Below in Figure 3, RedBoot’s command monitor is displayed immediately after
boot.
Figure 3 RedBoot command monitor prompt
Application Signing
Typical bootloaders only provide data integrity checks using a Cyclic Redundancy Check (known
as a CRC) to ensure that the software to be installed was not corrupted while being downloaded.
Although improbable, it is possible for two different applications to generate an identical CRC.
To address the issue of security a different method was devised. To create a unique “fingerprint”
for an application the MD5 algorithm is used.
5
MD5 Fingerprint
MD5 was developed by Professor Ronald L. Rivest of MIT. What it does, to quote the executive
summary of rfc1321, is:
“[The MD5 algorithm] takes as input a message of arbitrary length and produces as output a
128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally
infeasible to produce two messages having the same message digest, or to produce any message
having a given pre-specified target message digest. The MD5 algorithm is intended for digital
signature applications, where a large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem such as RSA. “
An MD5 “fingerprint” of the application is generated as part of the application build process using
public domain source code. This source code is also embedded within the bootloader application
to generate a digest for verification.
RSA Algorithm
To sign the fingerprint the RSA public key cryptosystem is used. The term “public key” refers to
the fact that knowing how to send a message in code does not help you decrypt the message.
When using public key encryption, only the decryption keys are kept secret while the encryption
keys are shared freely. The RSA algorithm was chosen due simplicity of implementation and
effectiveness. In the case of RSA, security is assured through the assertion that large prime
numbers are very difficult to factor.
The RSA encryption algorithm works as follows:
6
1. Two prime numbers ( p and q ) of similar size are chosen randomly. Even though it is
very difficult factor a prime it is relatively easy to test if a number is prime.
2. Calculate n  p  q
3. Choose
a
value
e
which
is
relatively
prime
to
 p  1  q  1
(i.e.
gcd n,  p  1  q  1  1, this can be verified using Euclid’s Algorithm)
4. The message to be encrypted is partitioned such that M (the message) is less than
5. The cyphertext (the encrypted message) C  M mod n . As
e
n.
M e gets very large very
fast, an algorithm for fast modular exponentiation is used (via the Chinese Remainder
Theorem). In the case of the bootloader, a GNU arbitrary precision library was used.
The RSA decryption algorithm:
1. Using Euclid’s algorithm the decryption key
d can be calculated.
2. Now, destroy p and q such that the original primes cannot be found (RSA works on the
assumption that it is impossible/improbable that
n can be factored back to p and q ).
3. The message can be recovered using: M  C mod n .
d
The public key for encryption is denoted by
n, e , for the bootloader, the public key is part of the
bootloader software and is used to verify images; only the encryption algorithm must be
implemented in the bootloader. The private key is given by
n, d  and is used by the application
developer to sign the binary program image.
From the equations above it can be stated that encryption and decryption are inverse functions
of one another; if M  C mod n and C  M mod n then:
d
e
7


e
C  C d mod n mod n
C  C de mod n
de  1
To sign a binary, during the build after the MD5 sum is calculated the decrypt or sign function is
called on the digest using the private key.
Figure 4 shows an invalid application (either corrupted data or an invalid key was used to create
the binary program image). Figure 5 shows program binary successfully loaded, displaying
information about the image.
Figure 4 RedBoot: invalid application
8
Figure 5 RedBoot: successfully identifying an image
To add an extra amount of security for the program binary, both the header which describes the
program and the data contained within can be signed. At a later date it could be possible to
update the system such that the header and data could have different signatures.
typedef struct image_header {
uint32_t
ih_magic;
uint8_t
ih_hdigest[IH_DIGESTLEN];
*/
uint32_t
ih_time;
uint32_t
ih_size;
uint32_t
ih_load;
uint32_t
ih_ep;
uint8_t
ih_ddigest[IH_DIGESTLEN];
*/
uint8_t
ih_os;
uint8_t
ih_arch;
uint8_t
ih_type;
uint8_t
ih_comp;
uint8_t
ih_name[IH_NMLEN];
} image_header_t;
/* Image Header Magic Number
/* Image Header MD5 Digest
*/
/*
/*
/*
/*
/*
Image
Image
Data
Entry
Image
*/
*/
*/
*/
/*
/*
/*
/*
/*
Operating System
CPU architecture
Image Type
Compression Type
Image Name
Creation Timestamp
Data Size
Load Address
Point Address
Data MD5 Digest
*/
*/
*/
*/
*/
9
JTAG Hardware
Why JTAG?
To perform the first write to the embedded system's flash, the JTAG bus is used by bypassing the
system processor and using the JTAG serial bus to manually control the processor's input/out
bus.
Various inexpensive JTAG options are available although almost all utilize the parallel port of a
standard PC, and emulate the JTAG serial bus by manually clocking the serial data. This results
in extremely poor performance (a transfer rate of approximately 3kbps) which creates very long
programming and read times.
The approach taken in this project was to create an alternative using a off the shelf JTAG bus
controller chip.
This controller chip provides the parallel to serial conversion and correct
sequence control to operate the JTAG state machine. To further increase the flexibility of this
device it was decided to use the USB (Universal Serial Bus) instead of the parallel port. The
result of designing this board was an increase in speed of 100 times.
JTAG Hardware Design
Previously in Status Report 2 a hardware JTAG adaptor to attach the parallel port of a PC was
designed. Later upon doing research of various microcontrollers for another project, the Cypress
AN2131S came up as an easy to use USB microcontroller based upon the Intel 8051 core. What
makes this microcontroller interesting is that it requires no programmer; the microcontroller is
bootstrapped via USB.
Upon device connection, the USB bus enumerates the device and
determines its identity. Upon successful identification, the operating system on the PC uploads
10
the required firmware to the device and causes it to simulate the device being removed and
plugged back in.
To save time in firmware development, it was decided to program the JTAG device to behave as
a parallel port. Although this solution is sub-optimal it is still superior to the parallel port solution
in two ways:

The JTAG device is powered off the USB port therefore an external power supply is not
needed.

In the future the firmware can be updated to include more functionality, whereas this
would be impossible for a parallel port connected device.
The JTAG bus control is provided by a Texas Instruments SN74LVT8980A JTAG TAP (Test Access
Port) Master. High level commands are issued to the controller by the host which causes the
controller to generate the signals necessary to operate the JTAG state machine.
To further
enhance reads and writes to the target device a 32 bit FIFO is present to buffer the data in both
directions to help minimize polling. To ensure that the target board’s JTAG signals are at the
correct voltage level, the JTAG controller is powered by the target voltage supply. As the JTAG
controller is a LVT (Low voltage TTL) part it utilizes 3.3V signaling but is 5V tolerant.
11
1
2
3
4
5
6
3.3V
U1
LM 1117
FUSE2
C1
0.1u F
INP UT
3.3V
OU TPUT
OU TPUT
R2
330
4
2
D
C8
10u F
1
D
3
3.3V
3.3V
11
22
33
44
D1
LED 1
10
F1
GND
VBUS
AVCC
VC C
VC C
VC C
VC C
U2
DISCON# 43
DISCON#
BK PT
32
BK PT
R1
330
VT ARGE T
VBUS
D2
LED 1
R6
1.5k
USB1
JP1
24
R8
1
NC
6
4
A
B
USB-
41
USBD+
USBD-
3.3V
PA 4/FWR#
3
NC
1
3
5
7
9
11
TCK
TM S
TD O
TD I
PC4
PA 5/FRD #
R9
10k
SN6 5220
CLK 24
WA KEU P# 37
WA KEU P#
PC7 /WR#
PC6 /RD#
PC5 /T1
PC4 /T0
PC3 /INT1 #
PC2 /INT0 #
PC1 /TxD 0
PC0 /RxD 0
3.3V
R11 R12
2.2k 2.2k
39 PA 4
CLK 24
21
20
19
18
17
16
15
14
PC7
PC6
PC5
PC4
PC3
PC2
PC1
PC0
31
30
29
28
27
26
25
24
D7
D6
D5
D4
D3
D2
D1
D0
VT ARGE T
U5
PC5
PC7
PC6
3.3V
U4
8
4
B
1
2
3
3.3V
VCC
VSS
SDA
SCL
5
6
SDA
SCL
35
36
D7
D6
D5
D4
D3
D2
D1
D0
SDA
SCL
NC
NC
NC
24L C00
RESET
13
C
HE ADER 6X2
40 PA 5
2
2
4
6
8
10
12
19
USB_B
GN D
GN D
42
24
U3
2
5
USB+
14
1
2
PC0
PC1
PC2
24
23
22
D0
D1
D2
D3
D4
D5
D6
D7
3
4
5
6
8
9
10
11
CLK 24
12
13
#RST
#ST RB
R/# W
VC C
R7
D+
D-
RD Y
A0
A1
A2
D0
D1
D2
D3
D4
D5
D6
D7
TD I
TD O
TM S
TCK
#TRST
CLK IN
#TO E
21
PC3
15
20
17
18
16
TD I
TD O
TM S
TCK
B
GND
C
1
3
2
4
5
6
SN7 4LVT 8980A
R3
10k
RESET
7
VBUS
D+
DGN D
SHI ELD
SHI ELD
C2
0.1u F
Y1
AN 2135S
XT AL1
XT AL2
1
4
1
3
4
5
126
23
34
38
NC
NC
7
R10
10k
2
3
XIN
XO UT
GND
GND
GND
GND
GND
GND
GND
GND
GND
AGND
XIN 8
XO UT9
MA -506
3.3V
3.3V
C10
33p F
VT ARGE T
A
L1
C3
0.1u F
C4
0.1u F
C5
0.1u F
C6
0.1u F
C12
0.1u F
C7
0.1u F
C9
2.2u F
470 uH
C11
33p F
A
C13
0.1u F
Title
Size
Num ber
Rev ision
B
Date:
File :
1
2
3
4
5
31- Jul-20 03
She et of
C:\D ocum ents a nd Se ttings\d gamr oth\M y DocDra
uments\Protel\usb.
wn By :
ddb
6
Figure 6 USB JTAG schematic
12
Figure 7 Target board (left) attached to USB JTAG (right)
13
Figure 8 JTAG test program
Conclusions
I have found this to be an extremely interesting and challenging project. From doing software
design on a full featured processor to developing a USB JTAG board to doing discrete math and
encryption; this project touched on a bit of everything. Personally I found the Élan to be lacking
the elegance of a modern RISC architecture simplicity of design. I will not get a chance to see
how this system will operate in the future, but I hope it is of some use to General Hydrogen.
14
Recommendations
Overall this project was a very rewarding learning experience. There were a few lessons learned,
all to do with the hardware platform.
Initially the AMD Élan SC520 was chosen due to it’s
compatibility with the ubiquitous Intel x86 family of processors and its floating point co-processor
for control applications. By leveraging compatibility, existing compilers in the Linux environment
could be used to build target software.
What was not considered was the total lack of
development tools for low level operations such as debugging, therefore the following
recommendations are made:

For evaluation purposes, buy an evaluation platform from AMD. Even though the cost of
the development platform is approximately $2000 USD compared to the $200 USD spent
on the current off-the-shelf board, the support and tools are well worth it.

Buy an off-the-shelf firmware BIOS from General Software Incorporated. By doing this
the low-level step can be ignored and the system will behave as a generic x86 PC.

If possible for a later revision or project replace the AMD Élan with a Motorola MPC8241
PowerPC. General Hydrogen currently owns several high quality debugging tools for the
PowerPC platform for a previous project. The MPC8241 is comparable in performance,
capabilities and cost with the AMD Élan SC520.
15
Bibliography
[1] “RedBoot" [online] 2003, http://sources.redhat.com/redboot (Accessed: 26 July 2003).
[2] Anthony J. Massa, “Embedded Software Development with eCos”, 1st ed. Prentice Hall
PTR, 2002, Figure 9.1 pp. 187
[3] Kenneth H. Rosen, “Discrete Mathematics and Its Applications”, 4th ed. WCB/McGraw-Hill,
1999
[4] “Boundary Scan (JTAG, IEEE 1149.1)”
http://www.acculogic.com/Products/BoundaryScanHome.htm (Accessed: July 31 2003)
16
Appendices
17