Analog Devices, Inc. reserves the right to change this product without
prior notice. Information furnished by Analog Devices is believed to be
accurate and reliable. However, no responsibility is assumed by Analog
Devices for its use; nor for any infringement of patents or other rights of
third parties which may result from its use. No license is granted by implication or otherwise under the patent rights of Analog Devices, Inc.
Trademark and Service Mark Notice
The Analog Devices logo, VisualDSP++, the VisualDSP logo, Blackfin,
the Blackfin logo, SHARC, the SHARC logo, TigerSHARC, the TigerSHARC logo, Crosscore, the Crosscore logo, and EZ-KIT Lite are
registered trademarks of Analog Devices, Inc.
All other brand and product names are trademarks or service marks of
their respective owners.
CONTENTS
PREFACE
Purpose of This Manual ................................................................ xiii
Intended Audience ........................................................................ xiii
Manual Contents ........................................................................... xiv
What’s New in This Manual ........................................................... xiv
Technical or Customer Support ....................................................... xv
Supported Processors ...................................................................... xvi
Product Information ..................................................................... xvii
MyAnalog.com ........................................................................ xvii
Processor Product Information ................................................ xviii
Related Documents ................................................................ xviii
Online Technical Documentation ............................................. xix
Accessing Documentation From VisualDSP++ ....................... xx
Accessing Documentation From Windows ............................. xx
Accessing Documentation From the Web .............................. xxi
Printed Manuals ....................................................................... xxi
VisualDSP++ Documentation Set ......................................... xxi
Format References ...................................................................... A-17
INDEX
VisualDSP++ 4.0 Loader Manualxi
CONTENTS
xiiVisualDSP++ 4.0 Loader Manual
PREFACE
Thank you for purchasing VisualDSP++® 4.0, Analog Devices, Inc. development software for digital signal processing (DSP) applications.
Purpose of This Manual
The VisualDSP++ 4.0 Loader Manual contains information about the
loader/splitter program for the following Analog Devices, Inc. processors—SHARC
Blackfin
The manual describes the loader/splitter operations for these processors
and references information about related development software. It also
provides information about the loader and splitter command-line
interfaces.
®
®
(ADSP-21xxx), TigerSHARC® (ADSP-TSxxx), and
(ADSP-BFxxx).
Intended Audience
The primary audience for this manual is a programmer who is familiar
with Analog Devices processors. This manual assumes that the audience
has a working knowledge of the appropriate processor architecture and
instruction set. Programmers who are unfamiliar with Analog Devices
processors can use this manual, but should supplement it with other texts
(such as the appropriate hardware reference and programming reference
manuals) that describe your target architecture.
VisualDSP++ 4.0 Loader Manual xiii
Manual Contents
Manual Contents
The manual contains:
•Chapter 1, “Introduction”
•Chapter 2, “Loader/Splitter for Blackfin Processors”
•Chapter 3, “Loader for ADSP-TSxxx TigerSHARC Processors”
•Chapter 4, “Loader for ADSP-2106x/21160 SHARC Processors”
•Chapter 5, “Loader for ADSP-21161 SHARC Processors”
•Chapter 6, “Loader for ADSP-2126x/2136x SHARC Processors”
•Chapter 7, “Splitter for SHARC and TigerSHARC Processors”
•Appendix A, “File Formats”
What’s New in This Manual
Information in this VisualDSP++ 4.0 Loader Manual applies to all Analog
Devices, Inc. processors listed in “Supported Processors”.
Refer to VisualDSP++ 4.0 Product Release Bulletin for information on new
and updated VisualDSP++ 4.0 features and other product release
information.
xivVisualDSP++ 4.0 Loader Manual
Technical or Customer Support
You can reach Analog Devices, Inc. Customer Support in the following
ways:
•Visit the Embedded Processing and DSP products Web site at
http://www.analog.com/processors/technicalSupport
•E-mail tools questions to
dsptools.support@analog.com
•E-mail processor questions to
dsp.support@analog.com
•Phone questions to 1-800-ANALOGD
•Contact your Analog Devices, Inc. local sales office or authorized
distributor
Preface
•Send questions by mail to:
Analog Devices, Inc.
One Technology Way
P.O. Box 9106
Norwood, MA 02062-9106
USA
VisualDSP++ 4.0 Loader Manual xv
Supported Processors
Supported Processors
The following is the list of Analog Devices, Inc. processors supported in
VisualDSP++ 4.0.
Blackfin (ADSP-BFxxx) Processors
The name “Blackfin” refers to a family of 16-bit, embedded processors.
VisualDSP++ currently supports the following Blackfin processors.
ADSP-BF531ADSP-BF532 (formerly ADSP-21532)
ADSP-BF533ADSP-BF534
ADSP-BF535 (formerly ADSP-21535)ADSP-BF536
ADSP-BF537ADSP-BF538
ADSP-BF539ADSP-BF561
ADSP-BF566AD6532
SHARC (ADSP-21xxx) Processors
The name “SHARC” refers to a family of high-performance, 32-bit,
floating-point processors that can be used in speech, sound, graphics, and
imaging applications. VisualDSP++ currently supports the following
SHARC processors.
ADSP-21020ADSP-21060ADSP-21061ADSP-21062
ADSP-21065LADSP-21160ADSP-21161ADSP-21261
ADSP-21262ADSP-21266ADSP-21267ADSP-21363
ADSP-21364ADSP-21365ADSP-21366ADSP-21367
ADSP-21368ADSP-21369
xviVisualDSP++ 4.0 Loader Manual
Preface
TigerSHARC (ADSP-TSxxx) Processors
The name “TigerSHARC” refers to a family of floating-point and
fixed-point [8-bit, 16-bit, and 32-bit] processors. VisualDSP++ currently
supports the following TigerSHARC processors.
ADSP-TS101 ADSP-TS201 ADSP-TS202 ADSP-TS203
Product Information
You can obtain product information from the Analog Devices Web site,
from the product CD-ROM, or from the printed publications (manuals).
Analog Devices is online at
www.analog.com. Our Web site provides infor-
mation about a broad range of products—analog integrated circuits,
amplifiers, converters, and digital signal processors.
MyAnalog.com
MyAnalog.com is a free feature of the Analog Devices Web site that allows
customization of a Web page to display only the latest information on
products you are interested in. You can also choose to receive weekly
e-mail notifications containing updates to the Web pages that meet your
interests.
sheets, code examples, and more.
Registration
Visit
Registration takes about five minutes and serves as a means to select the
information you want to receive.
If you are already a registered user, just log on. Your user name is your
e-mail address.
MyAnalog.com provides access to books, application notes, data
www.myanalog.com to sign up. Click Register to use MyAnalog.com.
VisualDSP++ 4.0 Loader Manual xvii
Product Information
Processor Product Information
For information on embedded processors and DSPs, visit our Web site at
www.analog.com/processors, which provides access to technical publica-
tions, data sheets, application notes, product overviews, and product
announcements.
You may also obtain additional information about Analog Devices and its
products in any of the following ways.
•E-mail questions or requests for information to
dsp.support@analog.com
•Fax questions or requests for information to
1-781-461-3010 (North America)
+49-89-76903-157 (Europe)
For hardware information, refer to your processors’s hardware reference,
programming reference, or data sheet. All documentation is available
online. Most documentation is available in printed form.
Visit the Technical Library Web site to access all processor and tools manuals and data sheets:
Online documentation comprises the VisualDSP++ Help system, software
tools manuals, hardware tools manuals, processor manuals, the Dinkum
Abridged C++ library, and Flexible License Manager (FlexLM) network
license manager software documentation. You can easily search across the
entire VisualDSP++ documentation set for any topic of interest. For easy
printing, supplementary
VisualDSP++ 4.0 Loader Manual xix
.PDF files of most manuals are also provided.
Product Information
Each documentation file type is described as follows.
File Description
.CHMHelp system files and manuals in Help format
.HTM or
.HTML
.PDFVisualDSP++ and processor manuals in Portable Documentation Format (PDF).
Dinkum Abridged C++ library and FlexLM network license manager software documentation. Viewing and printing the
Internet Explorer 4.0 (or higher).
Viewing and printing the
Reader (4.0 or higher).
.PDF files requires a PDF reader, such as Adobe Acrobat
.HTML files requires a browser, such as
If documentation is not installed on your system as part of the software
installation, you can add it from the VisualDSP++ CD-ROM at any time
by running the Tools installation. Access the online documentation from
the VisualDSP++ environment, Windows
®
Explorer, or the Analog
Devices Web site.
Accessing Documentation From VisualDSP++
From the VisualDSP++ environment:
•Access VisualDSP++ online Help from the Help menu’s Contents, Search, and Index commands.
•Open online Help from context-sensitive user interface items (toolbar buttons, menu commands, and windows).
Accessing Documentation From Windows
In addition to any shortcuts you may have constructed, there are many
ways to open VisualDSP++ online Help or the supplementary documentation from Windows.
xxVisualDSP++ 4.0 Loader Manual
Preface
Help system files (.
located in the
The
Docs folder also contains the Dinkum Abridged C++ library and the
CHM) are located in the Help folder, and .PDF files are
Docs folder of your VisualDSP++ installation CD-ROM.
Select a processor family and book title. Download archive (.ZIP) files, one
for each manual. Use any archive management software, such as WinZip,
to decompress downloaded files.
Printed Manuals
For general questions regarding literature ordering, call the Literature
Center at 1-800-ANALOGD (1-800-262-5643) and follow the prompts.
VisualDSP++ Documentation Set
To purchase VisualDSP++ manuals, call 1-603-883-2430. The manuals
may be purchased only as a kit.
VisualDSP++ 4.0 Loader Manual xxi
Product Information
If you do not have an account with Analog Devices, you are referred to
Analog Devices distributors. For information on our distributors, log onto
http://www.analog.com/salesdir/continent.asp.
Hardware Tools Manuals
To purchase EZ-KIT Lite™ and In-Circuit Emulator (ICE) manuals, call
1-603-883-2430. The manuals may be ordered by title or by product
number located on the back cover of each manual.
Processor Manuals
Hardware reference and instruction set reference manuals may be ordered
through the Literature Center at 1-800-ANALOGD (1-800-262-5643),
or downloaded from the Analog Devices Web site. Manuals may be
ordered by title or by product number located on the back cover of each
manual.
Data Sheets
All data sheets (preliminary and production) may be downloaded from the
Analog Devices Web site. Only production (final) data sheets (Rev. 0, A,
B, C, and so on) can be obtained from the Literature Center at
1-800-ANALOGD (1-800-262-5643); they also can be downloaded from
the Web site.
To have a data sheet faxed to you, call the Analog Devices Faxback System
at 1-800-446-6212. Follow the prompts and a list of data sheet code
numbers will be faxed to you. If the data sheet you want is not listed,
check for it on the Web site.
xxiiVisualDSP++ 4.0 Loader Manual
Notation Conventions
Text conventions used in this manual are identified and described as
follows.
ExampleDescription
Preface
Close command
(File menu)
{this | that}Alternative required items in syntax descriptions appear within curly
[this | that]Optional items in syntax descriptions appear within brackets and sepa-
[this,…]Optional item lists in syntax descriptions appear within brackets
.SECTIONCommands, directives, keywords, and feature names are in text with
filenameNon-keyword placeholders appear in text with italic style format.
L
a
Titles in reference sections indicate the location of an item within the
VisualDSP++ environment’s menu system (for example, the Close
command appears on the File menu).
brackets and separated by vertical bars; read the example as
that. One or the other is required.
rated by vertical bars; read the example as an optional
delimited by commas and terminated with an ellipse; read the example
as an optional comma-separated list of
letter gothic font.
Note: For correct operation, ...
A Note provides supplementary information on a related topic. In the
online version of this book, the word Note appears instead of this
symbol.
Caution: Incorrect device operation may result if ...
Caution: Device damage may result if ...
A Caution identifies conditions or inappropriate usage of the product
that could lead to undesirable results or product damage. In the online
version of this book, the word Caution appears instead of this symbol.
this.
this or
this or that.
Warn in g: Injury to device users may result if ...
A Warning identifies conditions or inappropriate usage of the product
[
that could lead to conditions that are potentially hazardous for devices
users. In the online version of this book, the word Wa rnin g appears
instead of this symbol.
VisualDSP++ 4.0 Loader Manual xxiii
Notation Conventions
L
Additional conventions, which apply only to specific chapters, may
appear throughout this document.
xxivVisualDSP++ 4.0 Loader Manual
1INTRODUCTION
The majority of this manual describes the loader program (or loader utility) as well as the process of loading and splitting, the final phase of an
application program’s development flow.
Most of this chapter applies to all 8-, 16-, and 32-bit data processors.
Information applicable to a particular target processor, or to a particular
processor family, is provided in the following chapters.
•Chapter 2, “Loader/Splitter for Blackfin Processors”
•Chapter 3, “Loader for ADSP-TSxxx TigerSHARC Processors”
•Chapter 4, “Loader for ADSP-2106x/21160 SHARC Processors”
•Chapter 5, “Loader for ADSP-21161 SHARC Processors”
•Chapter 6, “Loader for ADSP-2126x/2136x SHARC Processors”
•Chapter 7, “Splitter for SHARC and TigerSHARC Processors”
L
VisualDSP++ 4.0 Loader Manual1-1
The code examples in this manual have been compiled using
VisualDSP++ 4.0. The examples compiled with another version of
VisualDSP++ may result in build errors or different output;
although, the highlighted algorithms stand and should continue to
stand in future releases of VisualDSP++.
Program Development Flow
Program Development Flow
Figure 1-1 is a simplified view of the application development flow.
Figure 1-1. Program Development Flow and Booting Sequence
The development flow can be split into three phases:
1. “Compiling and Assembling”
2. “Linking”
3. “Loading, Splitting, or Both”
A brief description of each phase follows.
Compiling and Assembling
Input source files are compiled and assembled to yield object files. Source
files are text files containing C/C++ code, compiler directives, possibly a
mixture of assembly code and directives, and, typically, preprocessor commands. Refer to the VisualDSP++ 4.0 Assembler and Preprocessor Manual
1-2VisualDSP++ 4.0 Loader Manual
Introduction
or the VisualDSP++ 4.0 C/C++ Compiler and Library Manual for your
processor, and online help for information about the assembler and
compiler.
Linking
Under the direction of the Linker Description File (LDF) and linker settings, the linker consumes separately-assembled object and library files to
yield an executable file. If specified, the linker also produces the shared
memory files and overlay files. The linker output (.
the Executable and Linkable Format (ELF), an industry-standard format
for executable files. The linker also produces map files and other embedded information (DWARF-2) used by the debugger.
These executable files are not readable by the processor hardware directly.
They are neither supposed to be burned onto an EPROM or flash memory
device. Executable files are intended for VisualDSP++ debugging targets,
such as the simulator or emulator. Refer to the VisualDSP++ 4.0 Linker and Utilities Manual and online Help for information about linking and
debugging.
DXE files) conforms to
Loading, Splitting, or Both
Upon completing the debug cycle, the processor hardware needs to run on
its own, without any debugging tools connected. After power-up, the
processor’s on-chip and off-chip memories need to be initialized. The process of initializing memories is often referred to as booting. Therefore, the
linker output must be transformed to a format readable by the processor.
This process is handled by the loader/splitter program. The loader/splitter
uses the debugged and tested executable files as well as shared memory and
overlay files as inputs to yield a processor-loadable file.
VisualDSP++ 4.0 Loader Manual1-3
Program Development Flow
VisualDSP++ 4.0 includes these loader/splitter programs:
•
elfloader.exe (loader) for Blackfin, TigerSHARC, and SHARC
processors. The loader for Blackfin processors acts also as a ROM
splitter when invoked with the corresponding option settings or
switches.
•
elfspl21k.exe (splitter) for TigerSHARC and SHARC processors.
The loader/splitter output is either a boot-loadable or non-bootable file.
The output is meant to be loaded onto the target. There are several ways
to use the output:
•Download the loadable file into the processor PROM space on an
EZ-KIT Lite
®
board via the Flash Programmer plug-in. Refer to
VisualDSP++ Help for information on the Flash Programmer.
•Use VisualDSP++ to simulate booting in a simulator session (where
supported). Load the loader file and then reset the processor to
debug the booting routines. No hardware is required: just point to
the location of the loader file, letting the simulator to do the rest.
You can step through the boot kernel code as it brings the rest of
the code into memory.
•Store the loader file in an array on a multiprocessor system. A master (host) processor has the array in its memory, allowing a full
control to reset and load the file into the memory of a slave
processor.
Non-bootable Files Versus Boot-loadable Files
A non-bootable file executes from an external memory of the processor,
while a boot-loadable file is transported into and executes from an internal
memory of the processor. The boot-loadable file is then programmed
(burned into EPROM) into an external memory device within your target
system. The loader outputs loadable files in formats readable by most
1-4VisualDSP++ 4.0 Loader Manual
Introduction
EPROM burners, such as Intel hex-32 and Motorola S formats. For
advanced usage, other file formats and boot modes are supported. (See
“File Formats” on page A-1.)
A non-bootable EPROM image file executes from an external memory of
the processor, bypassing the built-in boot mechanisms. Preparing a
non-bootable EPROM image is called splitting. In most cases (except for
Blackfin processors), developers working with floating- and fixed-point
processors use the splitter instead of the loader to produce a non-bootable
memory image file.
A booting sequence of the processor and application program design dictate the way loader/splitter program is called to consume and transform
executable files:
•For Blackfin processors, splitter and loader operations are handled
by the loader program,
elfloader.exe. The splitter is invoked by a
different set of command-line switches than the loader.
•For TigerSHARC and SHARC processors, splitter operations are
handled by the splitter program,
elfspl21k.exe.
Loader Operations
You can run the loader from the IDDE. In order to do so, change the
project type from DSP Executable to DSP Loader File.
Loader operations depend on loader options, which control how the
loader processes executable files into boot-loadable files, letting you select
features such as kernels, boot modes, and output file formats. These
options are set on the Load page of the Project Options dialog box in the
VisualDSP++ Integrated Development and Development Environment
(IDDE) or on the loader command line. Option settings on the Load page
correspond to switches typed on the
elfloader.exe command line.
VisualDSP++ 4.0 Loader Manual1-5
Booting Modes
Splitter Operations
Splitter operations depend on splitter options, which control how the
splitter processes executable files into non-bootable files:
•For Blackfin processor, the loader program includes the ROM
splitter capabilities invoked through the Load page, the ROM splitter options category of the Project Options dialog box. Refer
to “Using the ROM Splitter” on page 2-62. Option settings on the
Load page correspond to switches typed on the
command line.
•For ADSP-21xxx SHARC and ADSP-TSxxx TigerSHARC processors, change the project type to DSP splitter file. The splitter
options are set via the Split page of the Project Options dialog box.
Refer to “Splitter for SHARC and TigerSHARC Processors” on
page 7-1. Option settings on the Splitter page correspond to
switches typed on the
elfspl21k.exe command line.
elfloader.exe
Booting Modes
Once an executable file is fully debugged, the loader is ready to convert
the executable file into a processor-loadable (or boot-loadable) file. The
loadable file can be automatically downloaded (booted) to the processor
after power-up or after a software reset. The way the loader creates a
boot-loadable file depends upon how the loadable file is booted into the
processor.
The boot mode of the processor is determined by sampling one or more of
the input flag pins. Booting sequences, highly processor-specific, are
detailed in the following chapters.
1-6VisualDSP++ 4.0 Loader Manual
Introduction
Analog Devices processors support different boot mechanisms. In general,
the following schemes can be used to provide program instructions to the
processors after reset.
•“No-Boot Mode”
•“PROM Boot Mode”
•“Host Boot Mode”
No-Boot Mode
After reset, the processor starts fetching and executing instructions from
EPROM/flash memory devices directly. This scheme does not require any
loader mechanism. It is up to the user program to initialize volatile
memories.
The splitter utility generates a file that can be burned into the PROM
memory.
PROM Boot Mode
After reset, the processor starts reading data from a parallel or serial
PROM device. The PROM stores a formatted boot stream rather than raw
instruction code. Beside application data, the boot stream contains additional data, such as destination addresses and word counts. A small
program called kernel, loader kernel, or boot kernel (described on page 1-8)
parses the boot stream and initializes memories accordingly. The loader
kernel runs on the target processor. Depending on the architecture, the
loader kernel may execute from on-chip boot RAM or may be preloaded
from the PROM device into on-chip SRAM and execute from there.
The loader utility generates the boot stream from the linker output (an
executable file) and stores it to file format that can be burned into the
PROM.
VisualDSP++ 4.0 Loader Manual1-7
Boot Kernels
Host Boot Mode
In this scheme, the target processor is a slave to a host system. After reset,
the processor delays program execution until the slave gets signalled by the
host system that the boot process has completed. Depending on hardware
capabilities, there are two different methods of host booting. In the first
case, the host system has full control over all target memories. The host
halts the target while initializing all memories as required. In the second
case, the host communicates by a certain handshake with the loader kernel
running on the target processor. This kernel may execute from on-chip
ROM or may be preloaded by the host devices into the processor’s SRAM
by any bootstrapping scheme.
The loader/splitter utility generates a file that can be consumed by the
host device. It depends on the intelligence of the host device and on the
target architecture whether the host expects raw application data or a formatted boot stream.
In this context, a boot-loadable file differs from a non-bootable file in that
it stores instruction code in a formatted manner in order to be processed
by a boot kernel. A non-bootable file stores raw instruction code.
Boot Kernels
A boot kernel (or loader kernel) refers to the resident program in the boot
ROM space responsible for booting the processor. Alternatively (or in
absence of the boot ROM), the boot kernel can be preloaded from the
boot source by a bootstrapping scheme.
When a reset signal is sent to the processor, the processor starts booting
from a PROM, host device, or through a communication port. For example, an ADSP-2106x/2116x processor brings a 256-word program into
internal memory for execution. This small program is a boot kernel.
1-8VisualDSP++ 4.0 Loader Manual
Introduction
The boot kernel then brings the rest of the application code into the processor’s memory. Finally, the boot kernel overwrites itself with the final
block of application code and jumps to the beginning of the application
program.
Some of the newer Blackfin processors (ADSP-BF531, ADSP-BF532,
ADSP-BF533, ADSP-BF534, ADSP-BF535, ADSP-BF536,
ADSP-BF537, ADSP-BF538, and ADSP-BF539) do not require a boot
kernel—the on-chip boot ROM allows the entire application program’s
body to be booted into the internal memory of the processor. The on-chip
boot ROM for the former Blackfin processors behaves similar to the
second-stage loader of the ADSP-BF535 processors. The boot ROM has
the capability to parse address and count information for each bootable
block.
Loader Tasks
Common tasks performed by the loader include:
•Processing loader option settings or command-line switches.
•Formatting the output
Supported formats are binary, ASCII, hex-32, and more. Valid file
formats are described in “File Formats” on page A-1.
•Packing the code for a particular data format: 8-, 16- or 32-bit for
some processors.
•Adding the code and data from a specified initialization executable
file to the loader file, if applicable.
•Adding a boot kernel on top of the user code.
VisualDSP++ 4.0 Loader Manual1-9
.LDR file according to user specifications.
Boot Streams
g
•If specified, preprogramming the location of the
.LDR file in a
specified PROM space.
•Specifying processor IDs for multiple input
.DXE files for a
multiprocessor system, if applicable.
Boot Streams
The loader output (.LDR file) is essentially the same executable code as in
the input .DXE file; the loader simply repackages the executable as shown
in Figure 1-2).
.DXE FILE
CODE
DATA
SYMBOLS
DEBUG
INFORMATION
.LDR FILE
CODE
DATA
SYMBO LS
DEBUG
INF ORM ATION
A.DXEfileincludes:
- DSP instructions (code and data)
- Symbol table and section information
-Target processor me m ory layout
- Debu
inform a tio n
An .LDR file includes:
- DSP instructions (code and data)
- Rudimentary formatting
(all debug inform ation has
been taken out)
Figure 1-2. A .DXE File Versus an .LDR File
Processor code and data in a loader file (also called a boot stream) is split
into blocks. Each code block is marked with a tag that contains information about the block, such as the number of words or destination in the
processor’s memory. Depending on the processor family, there may be
1-10VisualDSP++ 4.0 Loader Manual
Introduction
additional information in the tag. Common block types are “zero” (memory is filled with 0s); nonzero (code or data); and final (code or data).
Depending on the processor family, there may be other block types.
Refer to the following chapters to learn more about boot streams.
File Searches
File searches are important in the loader operation. The loader supports
relative and absolute directory names and default directories. File searches
occur as follows.
•Specified path—If relative or absolute path information is included
in a file name, the loader searches only in that location for the file.
•Default directory—If path information is not included in the file
name, the loader searches for the file in the current working
directory.
•Overlay and shared memory files—The loader recognizes overlay
and shared memory files but does not expect these files on the
command line. Place the files in the directory that contains the
executable file that refers to them, or place them in the current
working directory. The loader can locate them when processing the
executable file.
When providing an input or output file name as a loader/splitter command-line parameter, use these guidelines:
•Enclose long file names within straight quotes,
“long file name”.
•Append the appropriate file extension to each file.
VisualDSP++ 4.0 Loader Manual1-11
Boot Streams
1-12VisualDSP++ 4.0 Loader Manual
2LOADER/SPLITTER FOR
BLACKFIN PROCESSORS
This chapter explains how the loader/splitter program (elfloader.exe) is
used to convert executable (.
files for the ADSP-BF5xx Blackfin processors.
Refer to “Introduction” on page 1-1 for the loader overview; the introduc-
tory material applies to all processor families. Loader operations specific to
ADSP-BF5xx Blackfin processors are detailed in the following sections.
•“Blackfin Processor Booting” on page 2-2
Provides general information on various booting modes, including
information on second-stage kernels:
DXE) files into boot-loadable or non-bootable
•“ADSP-BF535 Processor Booting” on page 2-2
•“ADSP-BF531/BF532/BF533/BF534/BF536/BF537/
BF538/BF539 Processor Booting” on page 2-17
•“ADSP-BF561 and ADSP-BF566 Processor Booting” on
page 2-37
•“Blackfin Processor Loader Guide” on page 2-49
Provides reference information on the loader’s command-line
syntax and switches.
VisualDSP++ 4.0 Loader Manual 2-1
Blackfin Processor Booting
Blackfin Processor Booting
A Blackfin processor can be booted from an 8- or 16-bit flash/PROM
memory or an 8-,16-, or 24-bit addressable SPI memory. (Only the
ADSP-BF531/BF532/BF533/BF534/BF535/BF536/BF537/BF538/
BF539 processors support 24-bit addressable SPI memory booting.) There
is also a no-boot option (bypass mode) in which execution occurs from a
16-bit external memory.
At power-up, after the reset, the processor transitions into a boot mode
sequence configured by the
bits in the System Reset Configuration Register (
are dedicated mode-control pins; that is, no other functions are shared
with these pins.
BMODE pins. These pins can be read through
SYSCR). The BMODE pins
L
more information on system configuration, peripherals, registers,
and operating modes.
ADSP-BF535 Processor Booting
Upon reset, an ADSP-BF535 processor jumps to an external 16-bit memory for execution (if BMODE = 000) or to the on-chip boot ROM (if
Boot from a 16-bit address SPI0 serial EEPROM0110xF000 0000
Reserved111—100N/A
1 The processor jumps to this location after the booting is complete.
1
A description of each boot mode is as follows.
•“ADSP-BF535 Processor On-Chip Boot ROM” on page 2-3
•“ADSP-BF535 Processor Second-Stage Loader” on page 2-5
•“ADSP-BF535 Processor Boot Streams” on page 2-8
•“ADSP-BF535 Processor Memory Ranges” on page 2-15
ADSP-BF535 Processor On-Chip Boot ROM
The on-chip boot ROM for the ADSP-BF535 processor does the following (Figure 2-1).
1. Sets up Supervisor mode by exiting the
RESET interrupt service rou-
tine and jumping into the lowest priority interrupt (IVG15).
2. Checks whether the RESET was a software reset and if so, whether to
skip the entire boot sequence and jump to the start of L2 memory
(
0xF000 0000) for execution. The on-chip boot ROM does this by
checking bit 4 of the System Reset Configuration Register (
SYSCR).
If bit 4 is not set, the on-chip boot ROM performs the full boot
sequence. If bit 4 is set, the on-chip boot ROM bypasses the full
boot sequence and jumps to
0xF000 0000. The register settings are
shown in Figure 2-2.
VisualDSP++ 4.0 Loader Manual 2-3
Blackfin Processor Booting
ADSP-BF535 Processor
0xEF00 0000
On-Chip
BootROM
L2 Memory
(0xF000 0000)
2ndStage
2ndStage Lo ader
Loader
or
or
Application
Code
Application
PROM/Flash or SPI Device
4-Byte Header (N)
2ndStage Loader
or
Application
Code
Figure 2-1. ADSP-BF535 Processors: On-Chip Boot ROM
0x0
N
Bytes
System Reset Configuration Register (SYSCR)
X - state is initialized from mode pins during hardware reset
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
00000000 00 00XXX
No Boot on Software Reset
0 - Use BMODE to determine
boot source.
1 - Start executing from the
beginning of on-chip L2 memory
(or the beginning of ASYNC Bank 0
when BMODE[2:0] = b#000).
0
Reset = dependent on pin values
BMODE 2-0 - RO
000 - Bypass boot ROM,
execute from 16-bit-wide
external memory.
001 - Use boot ROM to load
from 8-bit/16-bit flash.
010 - Use boot ROM to configure
and load boot code from
SPI0 serial ROM
(8-bit address range).
011 - Use boot ROM to configure
and load boot code from
SPI0 serial ROM
(16-bit address range).
100-111 - Reserved
Figure 2-2. ADSP-BF535 Processors: System Reset Configuration Register
2-4VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
3. Finally, if bit 4 of the
SYSCR register is not set, performs the full
boot sequence. The full boot sequence includes:
D Checking the boot source (either flash/PROM or SPI mem-
ory) by reading
D Reading the first four bytes from location 0x0 of the exter-
BMODE[2:0] from the SYSCR register.
nal memory device. These four bytes contain the byte
count (
D Booting in N bytes into internal L2 memory starting at loca-
tion
D Jumping to the start of L2 memory for execution.
N), which specifies the number of bytes to boot in.
0xF000 0000.
The on-chip boot ROM boots in N bytes from the external memory. These
N bytes can define the size of the actual application code or a second-stage
loader (called a boot kernel) that boots in the application code.
ADSP-BF535 Processor Second-Stage Loader
The only situation where a second-stage loader is unnecessary is when the
application code contains only one section starting at the beginning of L2
memory (
0xF000 0000).
A second-stage loader must be used in applications in which multiple segments reside in L2 memory or in L1 memory and/or SDRAM. In
addition, a second-stage loader must be used to change the wait states or
hold time cycles for a flash/PROM booting or to change the baud rate for
an SPI boot (see “Command-Line Switches” on page 2-51 for more information on these features).
VisualDSP++ 4.0 Loader Manual 2-5
Blackfin Processor Booting
When a second-stage loader is used for booting, the following sequence
occurs.
1. Upon
second-stage loader) from external memory to address
RESET, the on-chip boot ROM downloads N bytes (the
0xF000 0000
in L2 memory (Figure 2-3).
ADSP-BF535 Processor
0xEF00 0000
On-Chip
Boot ROM
L2 Memory
(0xF000 0000)
2ndStage Load er
PROM/Flash or SPI Device
4-Byte H eader (N)
2ndStageLoader
Application
Code/Data
0x0
Bytes
N
Figure 2-3. ADSP-BF535 Processors: Booting With Second-Stage Loader
2-6VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
2. The second-stage loader copies itself to the bottom of L2 memory.
The loader generates the boot stream and places the boot stream in the
output loader (.
LDR) file. The loader prepares the boot stream in a way that
enables the on-chip boot ROM and the second-stage loader to load the
application code and data to the processor memory correctly. Therefore,
the boot stream contains not only the user application code but also
header and flag information that is used by the on-chip boot ROM and
the second-stage loader.
2-8VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Diagrams in this section illustrate boot streams utilized by the
ADSP-BF535 processor’s boot kernel:
•“Loader Files Without a Second-Stage Loader” on page 2-9
•“Loader Files With a Second-Stage Loader” on page 2-11
•“Global Headers” on page 2-13
•“Blocks, Block Headers, and Flags” on page 2-14
Loader Files Without a Second-Stage Loader
Figure 2-7 is a graphical representation of an output loader file for 8-bit
PROM/flash booting and 8-/16-bit addressable SPI booting without the
second-stage loader (kernel).
Output . LDR File
4-Byte Heade rfor
Byte Count (N)
Byte Count for
Application Code
Byte 0
Byte 1
Byte 2
Byte 3
........
........
........
D7
Figure 2-7. Loader
Application
Code
(N Words)
D0
File for 8-/16-bit PROM/Flash Booting Without Kernel
VisualDSP++ 4.0 Loader Manual 2-9
Blackfin Processor Booting
Figure 2-8 is a graphical representation of an output loader file for 16-bit
PROM/flash booting without the second-stage loader (kernel).
Output .LDR Fi le
0x00
4-Byte Headerfor
Byte Count (N)
Byte Count for
Application Code
0x00
0x00
0x00
0x00
0x00
0x00
0x00
D15D8 D7D0
Figure 2-8. Loader
Byte 0
Byte 1
Byte 2
Byte 3
........
........
........
File for 16-bit PROM/Flash Booting Without Kernel
Application
Code
(N Words)
2-10VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Loader Files With a Second-Stage Loader
Figure 2-9 is a graphical representation of an output loader file for 8-bit
PROM/flash booting and 8- or 16-bit addressable SPI booting with the
second-stage loader (kernel).
Output .LDR File
4-Byte Header for
Byte Coun t(N)
Byte 0
Byte Count for
nd
2
Stage Loader
Byte 1
Byte 2
........
Byte 0
Byte 1
Byte 2
........
D7
Figure 2-9. Loader
2ndStage Loader
(N Bytes)
Application
Code
(in Blocks)
D0
File for 8-/16-bit PROM/Flash/SPI Booting With Kernel
See also
Figure 2-12
See also
Figure 2-14
VisualDSP++ 4.0 Loader Manual 2-11
Blackfin Processor Booting
An output loader file for 16-bit PROM/flash booting with the
second-stage loader is illustrated in Figure 2-10.
Out put .L DR Fi le
0x00
0x00
0x00
0x00
0x00
4-ByteH eaderfor
Byte Count (N)
Byte 0
Byte 1
Byte 2
........
Byte Count for
nd
2
Stage Loader
2ndStage
Loader
See also
Figure 2-12
Byte 1
Byte 3
Byte 5
........
D15D8 D7D0
Byte 0
Byte 2
Byte 4
........
Application
Code
(in Blocks)
See also
Figure 2-14
Figure 2-10. Loader File for 16-bit PROM/Flash Booting With Kernel for
ADSP-BF531/BF532/BF533 Silicon Revision 0.2 and Below
2-12VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Global Headers
Following the second-stage loader code and address in a loader file, there
is a 4-byte global header. The header provides the global settings for a
booting process (see Figure 2-11).
Output .LDRFile
4Bytes
Byte Count (N)
Byte Count for
nd
2
Stage Loader
NBytes
4Bytes
4Bytes
4Bytes
N1 Bytes
nd
Stage Loader
2
2nd Stage Loader
Address
Global Header
Size of Application
Code (N1)
Application C ode
Address of the Bottom of L2 Memory
from which 2
See Figure 2-13
nd
Stage Loader runs
Figure 2-11. Global Header
A global header for 8- and 16-bit PROM/flash booting is illustrated in
Figure 2-13. Addressable SPI Booting: Global Header Bits
Blocks, Block Headers, and Flags
A block is the basic structure of the output
.LDR file for application code
when the second-stage loader is used. All the application code is grouped
into blocks. A block always has a block header and a block body if it is a
non-zero block. A block does not have a block body if it is a zero block. A
block header is illustrated in Figure 2-14.
4Bytes
NBytes
4Bytes
4Bytes
4Bytes
N1 Bytes
Output . LDR Fi le
Byte Count (N)
nd
2
Stage Loade r
2ndStage Loader
Address
Global Header
Size of Application
Code (N1)
Ap plica tio n Co d e
Sizeof Ap plication
Code (N1)
Start Address
of Block1
Byte Count
of Block 1
Flag for Blo ck 1
Body of B lock 1
Start Address
of Block2
Byte Count
of Block2
......
4Bytes
4Bytes
2Bytes
Block
Header
Block
Figure 2-14. Application Block
2-14VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
A block header has three words: 4-byte clock start address, 4-byte block
byte count, and 2-byte flag word.
The ADSP-BF535 block flag word’s bits are illustrated in Figure 2-15.
015 14 13 12 11 10 9 8 7 6 5
Bit 15: 1 = Last Block, 0 = Not Last Block
321
4
Bit 0: 1 = Zero-Fill, 0 = No Zero-Fill
Figure 2-15. Block Flag Word Bits
ADSP-BF535 Processor Memory Ranges
Second-stage loaders are available for ADSP-BF535 processors in
VisualDSP++ 3.0 and higher. They allow booting to:
•L2 memory (
0xF000 0000)
•L1 memory
D Data Bank A SRAM (0xFF80 0000)
D Data Bank B SRAM (0xFF90 0000)
D Instruction SRAM (0xFFA0 0000)
D Scratchpad SRAM (0xFFB0 0000)
•SDRAM
D Bank 0 (0x0000 0000)
D Bank 1 (0x0800 0000)
D Bank 2 (0x1000 0000)
D Bank 3 (0x1800 0000)
SDRAM must be initialized by user code before any instructions or
L
data are loaded into it.
VisualDSP++ 4.0 Loader Manual 2-15
Blackfin Processor Booting
For more information, see “Using the Second-Stage Loader” on
page 2-59.
Second-Stage Loader Restrictions
Using the second-stage loader imposes the following restrictions.
•The bottom of L2 memory must be reserved during booting. These
locations can be reallocated during runtime. The following locations pertain to the current second-stage loaders.
D For 8- and 16-bit PROM/flash booting, reserve
0xF003 FE00—0xF003 FFFF (last 512 bytes).
D For 8- and 16-bit addressable SPI booting, reserve
0xF003 FD00—0xF003 FFFF (last 768 bytes).
•If segments reside in SDRAM memory, configure the SDRAM registers accordingly in the second-stage loader kernels before booting.
D Modify section of code called “SDRAM setup” in the
second-stage loader and rebuild the second-stage loader.
•Any segments residing in L1 instruction memory
(
0xFFA0 0000–0xFFA0 3FFF) must be 8-byte aligned.
D Declare segments, within the .LDF file, that reside in L1
instruction memory at starting locations that are 8-byte
aligned (for example,
0xFFA0 0010, and so on).
D Use the .ALIGN 8; directives in the application code.
0xFFA0 0000, 0xFFA0 0008,
2-16VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
L
The two reasons for these restrictions are:
•Core writes into L1 instruction memory are not allowed.
•DMA from an 8-bit external memory is not possible since
the minimum width of the External Bus Interface Unit
(EBIU) is 16 bits.
Load bytes into L1 instruction memory by using the instruction test command and data registers, as described in the Memory chapter of the
appropriate Hardware Reference manual. These registers transfer 8-byte
sections of data from external memory to internal L1 instruction memory.
ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539
Processor On-Chip Boot ROM
The on-chip boot ROM for ADSP-BF531/BF532/BF533/BF534/
BF536/BF537/BF538/BF539 processors does the following.
1. Sets up Supervisor mode by exiting the
routine and jumping into the lowest priority interrupt (
2. Checks whether the
RESET was a software reset and, if so, whether
to skip the entire sequence and jump to the start of L1 memory
(
0xFFA0 0000 for ADSP-BF533/BF534/BF536/BF537/BF539
processors;
0xFFA0 8000 for ADSP-BF531/BF532/BF538) for
execution. The on-chip boot ROM does this by checking bit 4 of
the System Reset Configuration Register (
If bit 4 is not set, the on-chip boot ROM performs the full boot
sequence. If bit 4 is set, the on-chip boot ROM bypasses the full
boot sequence and jumps to the start of L1 memory.
System Reset Configuration Register (SYSCR)
X - state is initialized from mode pins during hardware reset
0xFFC0 0104
No Boot on Software Reset
0 - Use BMODE to determine
boot source.
1 - Start executing from the
beginning of on-chip L1
memory (or the beginning of
ASYNC Bank 0 when
BMODE[1:0] = b#00).
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0
00000000XX
0
RESET interrupt service
IVG15).
SYSCR). See Figure 2-16.
Reset = dependent on pin
0
values
0000
BMODE[1:0] (Boot Mode) - RO
00 - Bypass boot ROM,
execute from 16-bit
external memory.
01 - Use boot ROM to load
from 8-bit flash.
10 - Use boot ROM to configure
and load boot code from
SPI serial ROM
(8-bit address range).
11 - Use boot ROM to configure
and load boot code from
SPI serial ROM
(16-bit address range).
The booting sequence for ADSP-BF531/BF532/BF533/BF534/BF536/
BF537/BF538/BF539 processors is quite different from that for
ADSP-BF535 processors. The on-chip boot ROM for the former
processors behaves similar to the second-stage loader of ADSP-BF535
processors. The boot ROM has the capability to parse address and count
information for each bootable block. This alleviates the need for a
second-stage loader for ADSP-BF531/BF532/BF533/BF534/BF536/
BF537/BF538/BF539 processors because a full application can be booted
to the various memories with just the on-chip boot ROM.
The loader converts the application code (.
DXE) into the loadable file by
parsing the code and creating a file that consists of different blocks. Each
block is encapsulated within a 10-byte header, which is illustrated in
Figure 2-17 and detailed in the following section. These headers, in turn,
are read and parsed by the on-chip boot ROM during booting.
2-20VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
The 10-byte header provides all the information the on-chip boot ROM
requires—where to boot the block to, how many bytes to boot in, and
what to do with the block.
The following sections describe the boot stream, header, and flag framework for the ADSP-BF531, ADSP-BF532, ADSP-BF533, ADSP-BF534,
ADSP-BF536, ADSP-BF537, ADSP-BF538, and ADSP-BF539
processors.
The ADSP-BF531/BF532/BF533 processor boot stream is similar to the
boot stream that uses a second-stage kernel of ADSP-BF535 processors
(detailed in “Loader Files With a Second-Stage Loader” on page 2-11).
However, since the former processors do not employ a kernel, their boot
streams do not include the kernel code and the associated 4-byte header
on the top of the kernel code. There is also no 4-byte global header.
ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539 Blocks,
Block Headers, and Flags
As the loader converts the code from an input
.DXE file into blocks com-
prising the output loader file, each block is getting preceded by a 10-byte
header (Figure 2-18), followed by a block body (if it is a nonzero block) or
no block body (if it is a zero block). A description of the header structure
can be found in Table 2-3.
Address4-byte address at which the block resides in memory.
Count4-byte number of bytes to boot.
Flag2-byte flag containing information about the block; the following text
describes the flag structure.
Block
Header of DXE1 Count
10-Byte Header
4-Byte Address
4-Byte Count
2-Byte Flag
Boot Stream of the
First Executable (DXE1)
DXE1 Byte Count
Header of Block 1
Body of Block 2
Header for Block 2
Body of Block 2
......
......
Header of DXE2 Count
Boot Stream of the
Second Executable (DXE2)
Figure 2-18.
ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538
DXE2 Byte Count
......
......
BF539 Processors: Boot Stream Structur
e
See Flag Information
/
2-22VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Refer to Figure 2-19 and Table 2-4 for the flag’s bit descriptions.
Table 2-4. Flag Structure
Bit FieldDescription
Zero-Fill Block Indicates that the block is for a buffer filled with zeros. Zero block is not
included within the loader file. When the loader parses through the
and encounters a large buffer with zeros, it creates a zero-fill block to reduce
.LDR file size and boot time. If this bit is set, there is no block body in the
block.
Ignore Block Indicates that the block is not to be booted into memory; skips the block and
moves on to the next one. Currently is not implemented for application code.
.DXE file
Initialization
Block
Processor Type Indicates the processor, either ADSP-BF531/BF532/BF538 or
Last Block Indicates that the block is the last block to be booted into memory. After the
Indicates that the block is to be executed before booting. The initialization
block indicator allows the on-chip boot ROM to execute a number of instructions before booting the actual application code. When the on-chip boot ROM
detects an Init Block, it boots the block into internal memory and makes a
CALL to it (initialization code must have an RTS at the end).
This option allows the user to run initialization code (such as SDRAM initialization) before the full boot sequence proceeds. Figure 2-20 and Figure 2-21
illustrate the process. Initialization code can be included within the
by using the
ADSP-BF533/BF534/BF536/BF537/BF539. After booting is complete, the
on-chip boot ROM jumps to
ADSP-BF533/BF536/BF537/BF539 processor and to
ADSP-BF531/BF532/BF538 processor.
last block, the processor jumps to the start of L1 memory for application code
execution. When it jumps to L1 memory for code execution, the processor is
still in Supervisor mode and in the lowest priority interrupt (
-init switch (see “-init filename” on page 2-52).
0xFFA0 0000 for an
0xFFA0 8000 for an
.LDR file
IVG15).
Note that the ADSP-BF537 processor may have a special last block if the
boot mode is TWI (Two Wire Interface). The loader will save all the data
from
0xFF903F00 to 0xFF903FFF and will make the last block with the
data. The loader, however, will create a regular last block if no data is in
that memory range. The space of
0xFF903F00 to 0xFF903FFF is saved for
the boot ROM to use as a data buffer during a booting process.
VisualDSP++ 4.0 Loader Manual 2-23
Blackfin Processor Booting
015 14 13 12 11 10 9 8 7 6 5
Last Block:
1 = Last Block, 0 = Not Last Block
Programmable Flag:
0 = Default, Selectable from 0–15
Ignore Block: 1 = Ignore Block, 0 = Do Not Ignore Block
Zero-Fill: 1 = Zero-Fill Block, 0 = No Zero-Fill Block
Bits 14–9 are reserved for future use
321
4
Figure 2-19. Flag Bit Assignments for the 2-Byte Block Flag Word
Initialization Blocks
The
-init filename option directs the loader to produce the initialization
block from the code of the initialization section of the named file. The initialization blocks are placed at the top of a loader file. They are executed
before the rest of the code in the loader file is booted into the memory (see
Figure 2-20).
Following execution of the initialization blocks, the booting process
continues with the rest of data blocks until it encounters a final block (see
Figure 2-21). The initialization code example follows in Listing 2-1.
Listing 2-1. Initialization Block Code Example
/*This file contains 3 sections: */
/*1) A Pre-Init Section–this section saves off all the
processor registers onto the stack.
2) An Init Code Section–this section is the initialization
code which can be modified by the customer
As an example, an SDRAM initialization code is supplied.
The example setups the SDRAM controller as required by
certain SDRAM types. Different SDRAMs may require
different initialization procedure or values.
2-24VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
ADSP-BF531/BF532/BF533 Processor
L1 Memory
0xEF00 0000
On-Chip
Boot ROM
Init Block
PROM/Flash or SPI Device
Figure 2-20. ADSP-BF531/BF532/BF533/
BF539
Processors: Initialization Block Execution
ADSP-BF531/BF532/BF533 Processor
L1 Memory
0xE F00 0 000
On-Ch p
Boot R OM
i
Init Block
L1 Block
A
PROM/Flash or SPI D evice
Header for InitBlock
Init Block
Headerfor L1 Block
L1 Block
Header for SDRAM Block
SDRAM Block
........
10-Byte H eader for B lock n
Block n
SDRAM
App.
Code/
Data
BF534/BF536/BF537/BF538
Header forInit Blo ck
Init B lock
Header for L1Block
L1 Block
Headerf or SDRAM Block
SDR AM B lock
........
10- B yt e Hea d er f or B l ock n
Block n
SDR AM
SDRAM Block
App
Code
Data
.
/
/
Figure 2-21. ADSP-BF531/BF532/BF533/
BF539
Processors: Booting Application Code
BF534/BF536/BF537/BF538
/
VisualDSP++ 4.0 Loader Manual 2-25
Blackfin Processor Booting
3) A Post-Init Section–this section restores all the register
from the stack. Customers should not modify the Pre-Init
and Post-Init Sections. The Init Code Section can be
modified for a particular application.*/
#include <defBF532.h>
.SECTION program;
/**********************Pre-Init Section************************/
[--SP] = ASTAT;/* Stack Pointer (SP) is set to the end of */
[--SP] = RETS;/* scratchpad memory (0xFFB00FFC) */
[--SP] = (r7:0);/* by the on-chip boot ROM */
[--SP] = (p5:0);
[--SP] = I0;[--SP] = I1;[--SP] = I2;[--SP] = I3;
[--SP] = B0;[--SP] = B1;[--SP] = B2;[--SP] = B3;
[--SP] = M0;[--SP] = M1;[--SP] = M2;[--SP] = M3;
[--SP] = L0;[--SP] = L1;[--SP] = L2;[--SP] = L3;
/*******************Init Code Section**************************/
/*******Please insert Initialization code in this section******/
/***********************SDRAM Setup****************************/
Setup_SDRAM:
For SPI slave mode booting, the ADSP-BF531/BF532/BF533/
BF536
and a host is used to boot the processor.
L
Figure 2-22 shows the pin-to-pin connections needed for SPI slave mode.
The host does not need any knowledge of the loader file stream to boot
the Blackfin processor. It must be configured to send one byte at a time
from the loader file (in ASCII format). In the above setup,
back strobe from the Blackfin processor to the master host device. This
will be the signal used by the Blackfin processor to hold off the host during certain times within the boot process (specifically during init code
execution and zero-fill blocks). When
host device must discontinue sending bytes to the Blackfin processor.
When
bytes from where it left off. Since the
until the first block has been processed, consider using a resistor to pull
down the feedback strobe.
SDRAM must be initialized by user code before any instructions or
data are loaded into it.
BF534/
/
BF537/BF538/BF539
This boot mode is not supported in silicon revision 0.2 and earlier
of the ADSP-BF531/BF532/BF533/
BF539
PFx is de-asserted (low), the master host device will resume sending
processors.
processor is configured as an SPI slave device
BF534/BF536/BF537/BF538
PFx is the feed-
PFx is asserted (high), the master
PFx pin is not driven by the slave
/
2-30VisualDSP++ 4.0 Loader Manual
Host
(Master SPI
Device)
Loader/Splitter for Blackfin Processors
ADSP-BF533
(Slave SPI)
Device)
SPICLK
S_SEL
MOSI
MISO
FLAG /
Interrupt
SPICLK
SPISS
MOSI
MISO
PFx
Figure 2-22. Pin-to-Pin Connections for ADSP-BF531/BF532/BF533
Processor SPI Slave Mode
This PFx number is going to be user-defined and will be embedded within
the loader file. The elfloader utility will embed this number in bits [8:5] of
the
FLAG field within every 10-byte header. It does this by using the
-pflag number command-line switch where number is the intended PF
flag used by the Blackfin slave and has a value between 1 and 15.
If the -pflag number switch is not used, the default value placed
L
within bits 8:5 of the
FLAG will be 0, indicating that PF0 will be
assumed as the feedback signal to the host. Since PF0 is multiplexed
with the
boot, always use the
/SPISS pin, which is mandatory for successful SPI slave
For SPI master mode booting, the ADSP-BF531/BF532/BF533/
BF536/BF537/BF538/BF539
nected to a SPI memory. The following shows the pin-to-pin connections
needed for this mode.
Figure 2-23 shows the pin-to-pin connections needed for SPI master
mode.
L
Although the pull-up resistor on the
pull-up resistors might also be worthwhile as well. Pull up the
to ensure the SPI memory is not activated while the Blackfin processor is
in reset.
L
A pull-up resistor on MISO is required for this boot mode to work
properly. For this reason, the ADSP-BF531/BF532/BF533/
BF536/BF537/BF538/ BF539
pin if the SPI memory is not responding (that is, no data written
on the
On silicon revision 0.2 and earlier, the CPHA and CPOL bits within
the SPI Control (SPICTL) register were both set to 1. (Refer to the
ADSP-BF533 Blackfin Processor Hardware Reference for information on these bits.) For this reason, the SPI memory may detect an
erroneous rising edge on the clock signal when it recovers from
three-state. If the boot process fails because of this situation, a
pull-up resistor on the
silicon revision 0.3, this was fixed by setting CPHA = CPOL = 0 within
the SPI Control register.
MISO pin by the SPI memory).
processor is configured as a SPI master con-
processor reads a 0xFF on the MISO
MISO line is mandatory, additional
SPICLK signal will alleviate the problem. On
BF534
BF534
PF2 signal
/
/
The SPI memories supported by this interface are standard 8/16/24-bit
addressable SPI memories (the read sequence is explained below) and the
following Atmel SPI DataFlash devices: AT45DB041B, AT45DB081B,
AT45DB161B.
2-32VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
ADSP-BF533
(Master SPI
Device)
SPICLK
PF2
MOSI
MISO
V
DDEXT
10KΩ
SPI Memory
(Slave SPI
Device)
SPICLK
CS
MOSI
MISO
Figure 2-23. Pin-to-pin connections for ADSP-BF531/BF532/BF533 Processor SPI Master Mode
Standard 8/16/24-bit addressable SPI memories take in a read command
byte of 0x03, followed by one address byte (for 8-bit addressable SPI
memories), two address bytes (for 16-bit addressable SPI memories), or
three address bytes (for 24-bit addressable SPI memories). After the correct read command and address are sent, the data stored in the memory at
the selected address is shifted out on the
MISO pin. Data is sent out sequen-
tially from that address with continuing clock pulses. Analog Devices has
tested the following standard SPI memory devices.
•8-bit addressable SPI memory: 25LC040 from Microchip
•16-bit addressable SPI memory: 25LC640 from Microchip
•24-bit addressable SPI memory: M25P80 from STMicroelectronics
VisualDSP++ 4.0 Loader Manual 2-33
Blackfin Processor Booting
SPI Memory Detection Routine
Since
BMODE = 11 supports booting from various SPI memories, the
on-chip boot ROM will detect what type of memory is connected. To
determine the type of memory (8-, 16-, or 24-bit addressable) connected
to the processor, the on-chip boot ROM sends the following sequence of
bytes to the SPI memory until the memory responds back. The SPI memory does not respond back until it is properly addressed. The on-chip boot
ROM does the following.
1. Sends the read command,
dummy read of the
MISO pin.
0x03, on the MOSI pin then does a
2. Sends an address byte, 0x00, on the MOSI pin then does a dummy
read of the
3. Sends another byte,
MISO pin.
0x00, on the MOSI pin and checks whether the
incoming byte on the MISO pin is anything other than 0xFF (This is
the value from the pull-up resistor. For more information, refer to
the following note.) An incoming byte that is not
0xFF means that
the SPI memory has responded back after one address byte and an
8-bit addressable SPI memory device is assumed to be connected.
4. If the incoming byte is
0xFF, the on-chip boot ROM sends another
byte, 0x00, on the MOSI pin and checks whether the incoming byte
on the MISO pin is anything other than 0xFF. An incoming byte
other than
0xFF means that the SPI memory has responded back
after two address bytes and a 16-bit addressable SPI memory device
is assumed to be connected.
5. If the incoming byte is
0xFF, the on-chip boot ROM sends another
byte, 0x00, on the MOSI pin and checks whether the incoming byte
on the
other than
MISO pin is anything other than 0xFF. An incoming byte
0xFF means that the SPI memory has responded back
after three address bytes and a 24-bit addressable SPI memory
device is assumed to be connected.
2-34VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
6. If an incoming byte is
0xFF (meaning no devices have responded
back), the on-chip boot ROM assumes that one of the following
Atmel DataFlash devices are connected: AT45DB041B,
AT45DB081B, or AT45DB161B. These DataFlash devices have a
different read sequence than the one described above for standard
SPI memories. The on-chip boot ROM determines which of the
above Atmel DataFlash memories are connected by reading the status register.
For the SPI memory detection routine explained above, the
L
on-chip boot ROM in silicon revision 0.2 and earlier checks
whether the incoming data on the
MISO pin is 0x00 (first byte of the
loader file). The on-chip boot ROM in silicon revision 0.3 checks
whether the incoming data on the
0xFF. For this reason, SPI loader files built for silicon revision 0.2
and earlier must have the first byte as
the first byte of the loader file is set to
MISO pin is anything other than
0x00. For silicon revision 0.3,
0x40.
The SPI baud rate register is set to 133, which, when based on a 54 MHz
system clock, results in a 54 MHz/(2*133) = 203 kHz baud rate. On the
ADSP-BF533 EZ-KIT Lite board, the default system clock frequency is
54 MHz.
ADSP-BF534/BF536/BF537 Processor Booting
The ADSP-BF534/BF536/BF537 processors support the boot modes
listed in Table 2-5. They include all the boot modes supported in the
ADSP-BF531/BF532/BF533 processors in addition to booting from a
TWI (Two Wire Interface) serial device, a TWI host, and a UART host.
000Executes from external 16-bit memory connected to ASYNC Bank0 (bypass
boot ROM)
001Boots from 8/16-bit flash/PROM
010Reserved
011Boots from a 8/16/24-bit addressable SPI memory in SPI Master mode with
support for Atmel AT45DB041B, AT45DB081B, and AT45DB161B
DataFlash® devices
100Boots from a SPI host in SPI Slave mode
101Boots from an TWI serial device
110Boots from an TWI Host
111Boots from a UART Host
2-36VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
ADSP-BF561 and ADSP-BF566 Processor Booting
The booting sequence for the ADSP-BF561 and ADSP-BF566 dual-core
processors is similar to the ADSP-BF531/BF532/BF533 processor booting
sequence (described on page 2-17). Differences occur because the
ADSP-BF561 processor has two cores: core A and core B. After reset,
core B remains idle, but core A executes the on-chip boot ROM located at
address
0xEF00 0000.
L
Hardware Reference manual for information about the processor’s
operating modes and states. Please refer to the “System Reset and
Power-up Configuration” section for background information on
reset and booting.
The boot ROM loads an application program from an external memory
device and starts executing that program by jumping to the start of
Please refer to Chapter 3 of the ADSP-BF561 Blackfin Processor
core A’s L1 instruction SRAM, at address
0xFFA0 0000.
Table 2-6 summarizes the boot modes and execution start addresses for
Boot from 8-bit/16-bit PROM/flash memory0010xFFA0 0000
Boot from 8-bit addressable SPI0 serial EEPROM 010 0xFFA0 0000
Boot from 16-bit addressable SPI0 serial EEPROM 011 0xFFA0 0000
Reserved111–100 Not applicable
Just like the ADSP-BF531/BF532/BF533 processor, the ADSP-BF561
boot ROM uses the interrupt vectors to stay in Supervisor mode.
VisualDSP++ 4.0 Loader Manual 2-37
Blackfin Processor Booting
The boot ROM code transitions from the
into the lowest priority user interrupt service routine (
RESET interrupt service routine
Int 15) and remains
in the Interrupt Service Routine. The boot ROM then checks to see if it
has been invoked by a software reset by examining bit 4 of the System
Reset Configuration Register (
SYSCR).
If bit 4 is not set, the boot ROM presumes that a hard reset has occurred
and performs the full boot sequence. If bit 4 is set, the boot ROM understands that the user code has invoked a software reset and restarts the user
program by jumping to the beginning of core A’s L1 memory
(
0xFFA0 0000), bypassing the entire boot sequence.
When developing an ADSP-BF561 processor application, you start with
compiling and linking your application code into an executable file
(
.DXE). The debugger loads the.DXE into the processor’s memory and exe-
cutes it. With two cores, two.DXE files can be loaded at once. In the
real-time environment, there is no debugger, which allows the boot ROM
to load the executables into memory.
ADSP-BF561 Processor Boot Streams
The loader converts the
.DXE into a boot stream file (.LDR) by parsing the
executable and creating blocks. Each block is encapsulated within a
10-byte header. The
.LDR file is burned into the external memory device
(flash, PROM, or EEPROM). The boot ROM reads the external memory
device, parsing the headers and copying the blocks to the addresses where
they reside during program execution. After all the blocks are loaded, the
boot ROM jumps to address
0xFFA0 0000 to execute the core A program.
L
ble for releasing core B from the idle state by clearing bit 5 in
core A’s System Configuration Register. Then core B begins execu-
When code is run on both cores, the core A program is responsi-
tion at address
Multiple
.DXE files are often combined into a single boot stream.
0xFF60 0000.
2-38VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Unlike the ADSP-BF531/BF532/BF533 processor, the ADSP-BF561
boot stream begins with a 4-byte global header, which contains information about the external memory device. A bit-by-bit description of the
global header is presented in Table 2-7. The global header also contains a
signature in the upper 4 bits that prevents the boot ROM from trying to
read a boot stream from a blank device.
Table 2-7. ADSP-BF561 Global Header Structure
Bit FieldDescription
01 = 16-bit flash, 0 = 8-bit flash; default is 0
1–4
5
6–7Number of hold time cycles for flash; default is 3
Following the global header is a
byte count for the first
Number of wait states; default is 15
Unused bit
.DXE count block, which contains a 32-bit
.DXE in the boot stream. Though this block con-
tains only a byte count, it is encapsulated by a 10-byte block header, just
like the other blocks.
The 10-byte header tells the boot ROM where in memory to place each
block, how many bytes to copy, and whether the block needs any special
processing. The block header structure is the same as that of the
ADSP-BF531/BF532/BF533 processors (described in
“ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539
Blocks, Block Headers, and Flags” on page 2-21). Each header contains a
4-byte start address for the data block, a 4-byte count for the data block,
and a 2-byte flag word, indicating whether the data block is a “zero-fill”
block or a “final block” (the last block in the boot stream).
VisualDSP++ 4.0 Loader Manual 2-39
Blackfin Processor Booting
For the
.DXE count block, the address field is irrelevant since the block is
not going to be copied to memory. The “ignore bit” is set in the flag word
of this header, so the boot loader does not try to load the
.DXE count but
skips the count. For more details, see
“ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539
Blocks, Block Headers, and Flags” on page 2-21.
Following the .
DXE count block are the rest of the blocks of the first .DXE.
A bit-by-bit description of the boot steam is presented in Table 2-8.
When learning about the ADSPP-BF561 boot stream structure, keep in
mind that the count byte for each
…LSB of the byte count field of the nth block of 1st .DXE
…8–15 of the byte count field of the nth block of 1st .DXE
…16–23 of the byte count field of the nth block of 1st .DXE
…MSB of the byte count field of the nth block of 1st .DXE
…LSB of the flag word of the nth block of 1st .DXE
…MSB of the flag word of the nth block of 1st .DXE
…And so on …
…Byte 1 of the nth block of 1st .DXE
…Byte 0 of the nth block of 1st .DXE
…LSB of the address field of 2nd .DXE count block (no care)
…8–15 of the address field of 2nd .DXE count block (no care)
…And so on…
2-42VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
ADSP-BF561/BF566 Processor Memory Ranges
The on-chip boot ROM of the ADSP-BF561/BF566 processor can load a
full application to the various memories of both cores. Booting is allowed
to the following memory ranges. The boot ROM clears these memory
ranges before booting in a new application.
•Core A
D L1 Instruction SRAM (0xFFA0 0000 – 0xFFA0 3FFF)
D L1 Instruction Cache/SRAM (0xFFA1 0000 – 0xFFA1 3FFF)
D L1 Data Bank A SRAM (0xFF80 0000 – 0xFF80 3FFF)
D L1 Data Bank A Cache/SRAM (0xFF80 4000 –
0xFF80 7FFF)
D L1 Data Bank B SRAM (0xFF90 0000 – 0xFF90 3FFF)
D L1 Data Bank B Cache/SRAM (0xFF90 4000 – 0xFF90 7FFF)
•Core B
D L1 Instruction SRAM (0xFF60 0000 – 0xFF6 03FFF)
D L1 Instruction Cache/SRAM (0xFF61 0000 – 0xFF61 3FFF)
D L1 Data Bank A SRAM (0xFF40 0000 – 0xFF40 3FFF)
D L1 Data Bank A Cache/SRAM (0xFF40 4000 – 0xFF40 7FFF)
D L1 Data Bank B SRAM (0xFF50 0000 – 0xFF50 3FFF)
D L1 Data Bank B Cache/SRAM (0xFF50 4000 – 0xFF50 7FFF)
•128K of Shared L2 Memory (
FEB0 0000 – FEB1 FFFF)
•Four Banks of Configurable Synchronous DRAM
(
0x0000 0000 – (up to) 0x1FFF FFFF)
VisualDSP++ 4.0 Loader Manual 2-43
Blackfin Processor Booting
[
0xFFB0 0000 – 0xFFB0 0FFF) and to core B scratch memory
ory (
(
0xFF70 0000 – 0xFF70 0FFF). Data that needs to be initialized
prior to runtime should not be placed in scratch memory.
ADSP-BF561/BF566 Processor Initialization Blocks
The initialization block or a second-stage loader must be used to initialize
the SDRAM memory of the ADSP-BF561/BF566 processor before any
instructions or data are loaded into it.
The initialization blocks are identified by a bit in the flag word of the
10-byte block header. When the boot ROM encounters the initialization
blocks in the boot stream, it loads the blocks and executes them immediately. The initialization blocks must save and restore registers and return
to the boot ROM, so the boot ROM can load the rest of the blocks. For
more details, see
“ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539
Blocks, Block Headers, and Flags” on page 2-21.
Both the initialization block and second-stage loader can be used to force
The boot ROM does not support booting to core A scratch mem-
the boot ROM to load a specific
.DXE from the external memory device if
the boot ROM stores multiple executable files. The initialization block
can manipulate the
R0 or R3 register, which the boot ROM uses as external
memory pointers for flash/PROM or SPI memory boot, respectively.
After the processor returns from the execution of the initialization blocks,
the boot ROM continues to load blocks from the location specified in the
R0 or R3 register, which can be any .DXE in the boot stream. This option
requires the starting locations of specific executables within external memory. The
R0 or R3 register must point to the 10-byte count header, as
illustrated in “ADSP-BF53x and ADSP-BF561/BF566 Multiple .DXE
Booting” on page 2-46.
2-44VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
ADSP-BF561/BF566 Multiple .DXE Booting
A typical dual-core application is separated into two executable files; one
for each core. The default linker description file (LDF) for the
ADSP-BF561/BF566 processor creates two separate executable files
(
p0.dxe and p1.dxe) and some shared memory files (sml2.sm and
sml3.sm). By modifying the LDF, it is possible to create a dual-core
application that combines both cores into a single
.DXE file. This is not
recommended unless the application is a simple assembly language program which does not link any C run-time libraries. When using shared
memory and/or C run-time routines on both cores, it is best to generate a
separate
shared memory files (
(
p0.dxe).
.DXE file for each core. The loader combines the contents of the
sml2.sm, sml3.sm) into the .DXE file for core A
The boot ROM only loads one single executable before the ROM jumps
to the start of core A instruction SRAM (
0xFFA0 0000). When two .DXE
files are loaded, a second-stage loader is used. The second-stage boot
loader must start at
0xFFA0 0000. The boot ROM loads and executes the
second-stage loader. A default second-stage loader is provided for each
boot mode and can be customized by the user.
Unlike the initialization blocks, the second-stage loader takes full control
over the boot process and never returns to the boot ROM.
The second-stage loader can use the
cific
.DXE files in external memory.
.DXE byte count blocks to find spe-
The default second-stage loader uses the last 1024 bytes of L2
[
memory. The area must be reserved during booting but can be
reallocated at runtime.
VisualDSP++ 4.0 Loader Manual 2-45
Blackfin Processor Booting
ADSP-BF53x and ADSP-BF561/BF566 Multiple .DXE
Booting
This section describes how to boot more than one .DXE file into an
ADSP-BF531/BF532/BF533/
BF534/ BF536/BF537/BF538/BF539
ADSP-BF561/BF566 processor. The information presented in this section
applies to all of the named processors. For additional information on the
ADSP-BF561/BF566 processor, refer to “ADSP-BF561/BF566 Multiple
.DXE Booting” on page 2-45.
and
The ADSP-BF531/BF532/BF533/
BF534/ BF536/BF537/BF538/BF539
and ADSP-BF561/BF566 loader file structure and the silicon revision of
0.1 and higher allow the booting of multiple
.DXE files into a single
processor from external memory. As illustrated in Figure 2-24, each executable file is preceded by a 4-byte count header, which is the number of
bytes within the executable, including headers. This information can be
used to boot a specific
.DXE into the processor. The 4-byte .DXE count
block is encapsulated within a 10-byte header to be compatible with the
silicon revision 0.0. For more information, see
“ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539
Blocks, Block Headers, and Flags” on page 2-21.
Booting multiple executables can be accomplished by one of the following
methods.
•Use the second-stage loader switch, “-l userkernel”. This option
allows the use of your own second-stage loader or kernel.
After the second-stage loader gets booted into internal memory via
the on-chip boot ROM, it has full control over the boot process.
Now the second-stage loader can use the
in one or more
•Use the initialization block switch, “-init filename”, where
“filename” is the name of the executable file containing the initialization code. This option allows you to change the external
memory pointer and boot a specific
.DXE file via the on-chip boot
ROM.
A sample initialization code is included in Listing 2-2. The
R3 registers are used as external memory pointers by the on-chip
boot ROM. The
R0 register is for flash/PROM boot, and R3 is for
R0 and
SPI memory boot. Within the initialization block code, change the
value of
R0 or R3 to point to the external memory location at which
the specific application code starts. After the processor returns
from the initialization block code to the on-chip boot ROM, the
on-chip boot ROM continues to boot in bytes from the location
specified in the
R0 or R3 register.
VisualDSP++ 4.0 Loader Manual 2-47
Blackfin Processor Booting
Listing 2-2. Initialization Block Code Example for Multiple .DXE Boot
/**************************************************************/
/*******Init Code Section**************************************
R0.H = High Address of DXE Location (R0 for flash/PROM boot,
R3 for SPI boot)
R0.L = Low Address of DXE Location. (R0 for flash/PROM boot,
R3 for SPI boot)
***************************************************************/
/*******Post-Init Section**************************************/
Loader operations depend on the loader options, which control how the
loader processes executable files. You select features such as boot mode,
boot kernel, and output file format via the loader options. These options
are specified on the loader’s command line or via the Load page of the
Project Options dialog box in the VisualDSP++ environment. The Load
page consists of multiple panes and is the same for all Blackfin processors.
When you open the Load page, the default loader settings for the selected
processor are already set.
L
These sections describe how to produce a bootable or non-bootable loader
file (
Option settings on the Load page correspond to switches displayed
on the command line.
.LDR):
•“Using the ADSP-BF5xx Blackfin Loader Command Line” on
page 2-49
•“Using the Base Loader” on page 2-57
•“Using the Second-Stage Loader” on page 2-59
•“Using the ROM Splitter” on page 2-62
Using the ADSP-BF5xx Blackfin Loader Command
Line
The ADSP-BF5xx Blackfin loader uses the following command-line
syntax.
inputfile—Name of the executable file (.DXE) to be processed
into a single boot-loadable or non-bootable file. An input file name
can include the drive and directory. For multiprocessor or
multi-input systems, specify multiple input
.DXE files. Put the
input file names in the order in which you want the loader to process the files. Enclose long file names within straight quotes,
file name”
.
•-proc processor—Part number of the processor (for example,
ADSP-BF531) for which the loadable file is built. Provide a processor
part number for every input
.DXE if designing multiprocessor
systems.
“long
•
-switch …—One or more optional switches to process. Switches
select operations and modes for the loader.
Command-line switches may be placed on the command line in
L
any order, except the order of input files for a multi-input system.
For a multi-input system, the loader processes the input files in the
order presented on the command line.
File Searches
File searches are important in loader processing. The loader supports relative and absolute directory names, default directories, and user-selected
directories for file search paths. File searches occur as described
on page 1-11.
2-50VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
File Extensions
Some loader switches take a file name as an optional parameter. Table 2-9
lists the expected file types, names, and extensions.
Table 2-9. File Extensions
ExtensionFile Description
.DXELoader input files, boot kernel files, and initialization files
.LDRLoader output file
.KNLLoader output files containing kernel code only when two output files are selected
In some cases the loader expects the overlay input files with the file extension of
.OVL, shared memory input files with the extension of .SM, or both,
but does not expect those files to appear in a command line or on the
Load property page. The loader will find them in the directory of the
associated
specified in the
.DXE files, in the current working directory, or in the directory
.LDF file.
Command-Line Switches
A summary of the loader command-line switches appears in Table 2-10.
Table 2-10. Blackfin Loader Command-Line Switches
SwitchDescription
-b prom
-b flash
-b spi
-b spislave
-b UART
-b TWI
Specifies the boot mode. The -b switch directs the loader to prepare a
boot-loadable file for the specified boot mode. Valid boot modes
include PROM, Flash, SPI, SPI Slave, UART, and TWI. SPI Slave,
UART, and TWI are for the ADSP-BF531/BF532/BF533/BF534/
BF536/BF537/BF538/BF539/ processors only.
-b does not appear on the command line, the default is -b flash.
-baudrate #Accepts a baud rate for SPI booting only.
Note: Currently supports only ADSP-BF535 processors.
Valid baud rates and corresponding values (#) are:
500K – 500 kHz, the default
•
1M – 1 MHz
•
•
2M – 2 MHz
Boot kernel loading supports an SPI baud rate up to 2 MHz.
-enc dll_filenameEncrypts the data stream from the application input .DXE files with
the encryption algorithms in the dynamic library file
If the
dll_filename parameter does not appear on the command
line, the encryption algorithm from the default ADI’s file is used.
dll_filename.
-f hex
-f ASCII
-f binary
Specifies the format of a boot-loadable file (Intel hex-32, ASCII,
binary). If the
default boot mode format is
-f switch does not appear on the command line, the
hex for flash/PROM and ASCII for SPI,
SPI Slave, UART, and TWI.
-ghc #Specifies a 4-bit value (global header cookie) for bits 31–28 of the
global header. This switch is for ADSP-BF561/BF566 processors
only.
-h
or
-help
Invokes the command-line help, outputs a list of command-line
switches to standard output, and exits. By default, the
-h switch alone
provides help for the loader driver. To obtain a help screen for your
target Blackfin processor, add the
line. For example: type
elfloader -proc ADSP-BF535 -h to
-proc switch to the command
obtain help for the ADSP-BF535 processor.
-HoldTime # Allows the loader to specify a number of hold time cycles for
PROM/flash boot. The valid values (#) are from
default value is
3.
0 through 3. The
Note: Currently supports only ADSP-BF535 processors.
-init filenameDirects the loader to include the initialization code from the named
file. The loader places the code from the initialization section of the
specified .
DXE file in the boot stream. The kernel loads the code and
then calls it. It is the responsibility of the code to save/restore
state/registers and then perform a RTS back to the kernel.
Note: This switch cannot be applied to ADSP-BF535 processors.
Specifies the boot mode (PROM, Flash, SPI, SPI Slave, UART, or
TWI) for the boot kernel output file if you generate two output files
from the loader: one for boot kernel and another for user application
code. SPI Slave, UART, and TWI are for the ADSP-BF531/BF532/
BF533/BF534/ BF536/BF537/BF538/BF539/ processors only.
This switch must be used in conjunction with the
-kb switch is absent on a command line, the loader generates
If the
-o2 switch.
the file for the boot kernel in the same boot mode as used to output
the user application program.
-kf hex
-kf ascii
-kf binary
Specifies the output file format (hex, ASCII, or binary) for the boot
kernel if you output two files from the loader: one for boot kernel
and one for user application code.
This switch must be used in conjunction with the
-kf switch is absent from the command line, the loader generates the
-o2 switch. If the
file for the boot kernel in the same format as for the user application
program.
-kenc dll_filenameSpecifies the user encryption dynamic library file for the encryption
of the data stream from the kernel file. If the
filename parameter
does not appear on the command line, the encryption algorithm from
the default ADI’s file is used.
-kp #Specifies a hex PROM/flash output start address for kernel code. A
valid value is between [
0x0, 0xFFFFFFFF]. The specified value is not
used if no kernel or/and initialization code is included in the loader
file.
-kWidth # Specifies the width of the boot kernel output file when there are two
output files: one for boot kernel and one for user application code.
Valid values are:
8 or 16 for PROM or flash boot kernel
•
8 for SPI boot kernel
•
If this switch is absent from the command line, the default file width
is:
-l userkernelSpecifies the user’s boot kernel. The loader utilizes the user-specified
kernel and ignores the default boot kernel if there is one.
Note: Currently, only ADSP-BF535 processors have default kernels.
-MGenerates make dependencies only, no output file is generated.
-maskaddr # Masks all EPROM address bits above or equal to #.
For example,
including
0x2000 0000 becomes 0x0000 0000. The valid #s are integers 0
through
within a subset of
This switch requires
address only.
-MaxBlockSize #Specifies the maximum block byte count, which must be a multiple
of 16.
-MMGenerates make dependencies while producing the output files.
-maskaddr 29 (default) masks all the bits above and
A29 (ANDed by 0x1FFF FFFF). For example,
32, but based on your specific input file, the value can be
[0,32].
-romsplitter and affects the ROM section
-Mo filenameWrites make dependencies to the named file.
The
-Mo option is for use with either the -M or -MM option. If -Mo is
not present, the default is
-Mt filenameSpecifies the make dependencies target output file.
-Mt option is for use with either the -M or -MM option. If -Mt is
The
not present, the default is the name of the input file with the .
a <stdout> display.
LDR
extension.
-no2kernelProduces the output file without the boot kernel but uses the
boot-strap code from the internal boot ROM. The boot stream generated by the loader is different from the one generated by the boot kernel.
Note: Currently supports only ADSP-BF535 processors.
-o filenameDirects the loader to use the specified filename as the name of the
loader output file. If the
name of the input file with an .
-o2Produces two output files: one for the Init block (if present) and boot
kernel and one for user application code.
To have a different format, boot mode, or output width from the
application code output file, use the
specify the boot mode, the boot format, and the boot width for the
output kernel file.
If you intend use the
-p #Specifies a hex PROM/flash output start address for the application
code. A valid value is between [
must be greater than that specified by
tialization and application code are in the same output file (a single
output file).
-kb -kf -kwidth switches to
0x0, 0xFFFFFFFF]. A specified value
-kp if both kernel and/or ini-
-pFlag #Specifies a 4-bit hex value for strobe (programmable flag). The
default value is zero (0). This switch is for ADSP-BF531/BF532/
BF533/BF534/BF536/BF537/BF538/BF539/ BF561/BF566
processors only.
-proc processorSpecifies the target processor.
processor can be one of the following: ADSP-BF531,
-si-revision #|noneProvides a silicon revision of the specified processor.
The switch parameter represents a silicon revision of the processor
specified by the
•The
•The
This switch either generates a warning about any potential anomalous
conditions or generates an error if any anomalous conditions occur.
Note: In the absence of the silicon revision switch, the loader selects
the greatest silicon revision it is aware of, if any.
Note: In the absence of the switch parameter (a valid revision
value)—
generates an error.
-proc switch. The parameter takes one of two forms:
none value indicates that the VDSP++ tool should
ignore silicon errata.
# value indicates one or more decimal digits, followed
by a point, followed by one or two decimal digits. Examples
of revisions are:
from and “lower” than revision
0.0; 1.12; 23.1. Revision 0.1 is distinct
0.10. The digits to the left
of the point specify the chip tapeout number; the digits to
the right of the point identify the metal mask revision number. The number to the right of the point cannot exceed
decimal
-si-revision alone or with an invalid value—the loader
255.
-vOutputs verbose loader messages and status information as the loader
processes files.
-waits # Specifies the number of wait states for external access. Valid inputs
0 through 15. Default is 15. Wait states apply to the flash/PROM
are
boot mode only.
Note: Currently supports only ADSP-BF535 processors.
width #Specifies the loader output file’s width in bits. Valid values are 8 and
-
16, depending on the boot mode. The default is 8.
The switch has no effect on boot kernel code processing on
ADSP-BF535 processors. The loader processes the kernel in 8-bit
widths regardless of selection of the output data width.
•For flash/PROM booting, the size of the output file depends on
-width # switch.
the
•For SPI booting, the size of the output
both
-width 8 and -width 16. The only difference is the
.LDR file is the same for
header information.
2-56VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Using the Base Loader
The Load page of the Project Options dialog consists of multiple panes
and is shared with all Blackfin processors. When you open the Load page,
the default loader settings (Loader options) for the selected processor are
already set. As an example, Figure 2-25 shows the ADSP-BF532 processor’s default Load settings for PROM booting. Command-line switches
equivalent to the dialog box options are also identified. Refer to “Com-
mand-Line Switches” on page 2-51 for more information on the switches.
Figure 2-25. Loader File Options Page for Blackfin Processors
Using the page controls, select or modify the loader settings. Table 2-11
describes each loader control and corresponding setting. When satisfied
with default settings, click OK to complete the loader setup.
VisualDSP++ 4.0 Loader Manual 2-57
Blackfin Processor Loader Guide
Table 2-11. Base Loader Page Settings
SettingDescription
LoadSelections for the loader. The options are:
•Options – default booting options (this section)
•Kernel – specification for a second-stage loader (see on page 2-59)
•Splitter – specification for the no-boot mode (see on page 2-62)
If you do not use the boot kernel for ADSP-BF535 processors, the Kernel page
appears with all kernel option fields grayed out. The loader does not search for
the boot kernel if you boot from the on-chip ROM by setting the -no2kernel
command-line switch as described on page 2-54.
For
ADSP-BF531/BF532/BF533/BF534/BF536/BF537/BF538/BF539/BF561/
BF566 processors, which do not have software boot kernels by default, select
the boot kernel to use one.
Boot modeSpecifies PROM, Flash, SPI, SPI Slave, UART, or TWI as a boot source.
Boot formatSpecifies Intel hex, ASCII, or binary formats.
Output widthSpecifies 8 or 16 bits.
BMODE = 01 or 001 and flash/PROM is 16-bit wide, the 16-bit option must
If
be selected.
Start addressSpecifies a PROM/flash output start address in hex format for the application
code.
VerboseGenerates status information as the loader processes the files.
Wait st a t eSpecifies the number of wait states for external access (
The selection is active for ADSP-BF535 processors. For ADSP-BF531/BF532/
BF533/BF534/BF536/BF537/BF538/BF539/BF561/BF566 processors, the
field is grayed out.
Hold timeSpecifies the number of the hold time cycles for PROM/flash boot (
The selection is active for ADSP-BF535 processors. For ADSP-BF531/BF532/
BF533/BF534/BF536/BF537/BF538/BF539/BF561/BF566 processors, the
field is grayed out.
Baud rateSpecifies a baud rate for SPI booting (500 kHz, 1 MHz, and 2 MHz).
The selection is active for ADSP-BF535 processors. For ADSP-BF531/BF532/
BF533/BF534/BF536/BF537/BF538/BF539/BF561/BF566 processors, the
field is grayed out.
0–15).
0–3).
2-58VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Table 2-11. Base Loader Page Settings (Cont’d)
SettingDescription
Programmable
flag
Initialization
file
Kernel fileSpecifies the boot kernel file. Can be used to override the default boot kernel if
Output fileNames the loader’s output file.
Additional
options
Selects a programmable flag number (from 0 to 15) as strobe. This box is active
if SPI Slave is selected for ADSP-BF531/BF532/BF533/BF534/BF536/BF537/
BF538/BF539 processors.
Directs the loader to include the initialization file (Init code). The Initialization
file selection is active for ADSP-BF531/BF532/BF533, and ADSP-BF561
processors. For ADSP-BF535 processors, the field is grayed out.
there is one by default, as on ADSP-BF535 processors.
Specifies additional loader switches. You can specify additional input files for a
multi-input system. Type the file names with the paths (they are not in the
current working directory) separated with a space between two names, and the
loader will retrieve these input files.
Note: The loader processes the input files in the order in which the files appear
on the command line generated form the property page.
Using the Second-Stage Loader
If you use a second-stage loader, select Kernel (under Load in the Project
Options tree control). The page shows how to configure the loader for
boot loading and to output file generation using the boot kernel.
Figure 2-26 shows a sample Kernel page, with boot options for a Blackfin
processor.
VisualDSP++ 4.0 Loader Manual 2-59
Blackfin Processor Loader Guide
Figure 2-26. Kernel Page – Boot Options for an ADSP-BF53x Blackfin
Processor
To create a loader file which includes a second-stage loader:
1. Select Options (under Load) to set up base booting options (see
“Using the Base Loader” on page 2-57).
2. Select Kernel (under Load) to open the Kernel page for the
second-stage loader settings, shown in Figure 2-26.
3. Select Use boot kernel. By default, this option is selected for
ADSP-BF535 and grayed out for ADSP-BF531/BF532/BF533/
BF534/ BF536/BF537/BF538/BF539/
BF561/BF566 processors.
2-60VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
4. To produce two output files (Init code and/or boot kernel file and
application code file), select the Output kernel in separate file
check box. This option boots the second-stage loader from one
source and the application code from another source. If the Output kernel in separate file box is selected, you can specify the kernel
output file options such as the Boot mode (source), Boot format,
and Output width.
5. Enter the Kernel file (
(in case of an ADSP-BF535 processor) or enter a kernel’s file name
if Use boot kernel in step 3 is selected.
The following second-stage loaders are currently available for the
ADSP-BF535 processor.
BF539/
required; hence, no default kernel files are provided. Users can
supply their own second-stage loader file, if so desired.
6. Specify the Start address (flash/PROM output address in hexadeci-
mal format) for the kernel code. This option allows you to place
the kernel file at a specific location within the flash/PROM in the
loader file.
BF561/BF566 processors, no second-stage loaders are
.DXE). You must either use the default kernel
BF534/ BF536/BF537/BF538
7. For ADSP-BF535 processors only, modify the Wait states and
Hold time cycles for flash/PROM booting or the Baud rate for SPI
booting.
8. Click OK to complete the loader setup.
VisualDSP++ 4.0 Loader Manual 2-61
Blackfin Processor Loader Guide
Using the ROM Splitter
Unlike the loader utility, the splitter does not format the application data
when transforming an
Whether data and/or instruction segments are processed by the loader or
by the splitter utility depends upon the LDF’s
ments declared with
segments declared by
Figure 2-27 shows a sample Splitter page, with ROM splitter options.
With the Enable ROM splitter box unchecked, only
are processed and all
ity. If the box is checked,
segments are processed by the splitter utility.
The Mask Address field masks all EPROM address bits above or equal to
the number specified. For example, Mask Address =
the bits above and including A29 (ANDed by 0x1FFF FFFF). Thus,
0x2000 0000 becomes 0x0000 0000. The valid numbers are integers 0
through
32 but, based on your specific input file, the value can be within a
subset of [0, 32].
.DXE file to an .LDR file. It emits raw data only.
TYPE() command. Seg-
TYPE(RAM) are consumed by the loader utility, and
TYPE(ROM) are consumed by the splitter.
TYPE(RAM) segments
TYPE(ROM) segments are ignored by the elfloader util-
TYPE(RAM) segments are ignored, and TYPE(ROM)
29 (default) masks all
No-Boot Mode
The hardware settings of
BMODE = 00 for ADSP-BF531/BF532/BF533/
BF538
/
BF539
processors select the no-boot option. In this mode of opera-
BMODE = 000 for ADSP-BF535 processors or
BF534/ BF536/BF537/
tion, the on-chip boot kernel is bypassed after reset, and the processor
starts fetching and executing instructions from address
0x2000 0000 in the
Asynchronous Memory Bank 0. The processor assumes 16-bit memory
with valid instructions at that location.
2-62VisualDSP++ 4.0 Loader Manual
Loader/Splitter for Blackfin Processors
Figure 2-27. Splitter Page – ROM Splitter Options for Blackfin Processors
To create a proper .LDR file that can be burned into either a parallel flash
or EPROM device, you must modify the standard LDF file in order for
the reset vector to be located accordingly. The following code fragments
(Listing 2-3 and Listing 2-4) illustrate the required modifications in case
of an ADSP-BF533 processor.