Analog Devices EE240v03 Application Notes

Engineer-to-Engineer Note EE-240

Technical notes on using Analog Devices DSPs, Processors and development tools

a

Contact our technical support at [e-mail] and at [e-mail]
Or vi sit our o n-li ne r esou rces htt p:/ /www.analog.com/ee-notes and http://www.analog.com/processors

ADSP-BF533 Blackfin® Booting Process

Contributed by Hiren Desai Rev 3 – January 11, 2005

Introduction

This EE-Note describes the booting process for the ADSP-BF531, ADSP-BF532, and ADSP-BF533
Blackfin® processors. Differences between silicon revision levels are noted.

This EE-Note discusses:

 Boot modes
 Loader file header information
 Initialization code
 Multi-application (multi-DXE) management

The Booting Process

Booting is the process of loading application code/data, stored in an external memory device (or external
host), into the various internal and external memories of the Blackfin processor. This is handled by the on­chip Boot ROM which is located in Blackfin memory at address 0xEF00 0000 to 0xEF00 03FF. Figure 1
shows the sequence of operations taken from source code to the final target stand-alone system.

Source Files

.ASM, .C, .CPP

Assembler and/or

Compiler

ADSP-BF53x
Processor

.DOJ(s)

Target System

Booting
Upon
RESET

Linker

External
Memory

.DXE(s)

.LDR

Loader

Figure 1. ADSP-BF531/BF532/BF533 Stand-Alone System

Copyright 2005, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of
customers’ products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property
of their respective holders. Information furnished by Analog Devices applications and development tools engineers is believed to be accurate and reliable, however
no responsibility is assumed by Analog Devices regarding technical accuracy and topicality of the content provided in Analog Devices’ Engineer-to-Engineer Notes.

a

Boot Modes (Silicon Revision 0.3)*

Blackfin processors can boot from a flash/PROM via asynchronous Bank 0 of the EBIU or an SPI device
(memory or host) via the SPI interface. Table 1 lists ADSP-BF531/BF532/BF533 processor booting
modes, which are selected by the state of the BMODE[1:0] pins when the RESET signal is de-asserted.

BMODE[1:0] Description (See Also Specific Blackfin Boot Modes on page 10

00 Executes from external 16-bit memory connected to ASYNC Bank0 (bypass Boot ROM)
01 Boots from 8/16-bit flash/PROM
10 Boots from a SPI host in SPI Slave mode
11 Boots from a 8/16/24-bit addressable SPI memory in SPI Master mode with support for

Atmel AT45DB041B, AT45DB081B, and AT45DB161B DataFlash® devices

Table 1. Blackfin ADSP-BF531/BF532/BF533 Booting Modes

* For boot modes supported on previous revisions of silicon, refer to the

Appendix: Boot Modes vs. Silicon Revisions.

As Figure 1 illustrates, the loader utility (elfloader.exe) parses the input executable file (.DXE) and
creates a loader file (

.LDR)*, consisting of blocks preceded by headers. This loader file is then

programmed/burned into the external memory/device. The headers are read and parsed by the on-chip
Boot ROM during booting.

* Refer to the VisualDSP++ 3.5 Loader Manual for 16-Bit Processors [1] for information on switches loader files

Loader File is programmed/burned into the External Memory/Device

ADSP-BF531/BF532/BF533 Processor

10-Byte Header for Block 1

Block 1

10-Byte Header for Block 2

Block 2

10-Byte Header for Block 3

Block 3

10-Byte Header for Block n

Block n

……………..

Loader File

0xEF00 0000

On-Chip Boot

ROM

Figure 2. ADSP-BF531/BF532/BF533 Boot Process

L1 Memory

Block 1

Block 3

Flash/PROM or SPI

10-Byte Header for Block 1

Block 1

10-Byte Header for Block 2

Block 2

10-Byte Header for Block 3

Block 3

...........

10-Byte Header for Block n

Block n

SDRAM
Block 2

App.

Code/

Data

Booting into scratchpad memory (0xFFB0 0000 – 0xFFB0 0FFF) is not supported. If booting to

L

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 2 of 29

scratchpad memory is attempted, the processor will hang within the on-chip Boot ROM.

a

Header Information

As shown in Figure 3, each 10-byte header within the loader file consists of a 4-byte ADDRESS field, a 4­byte COUNT field, and a 2-byte FLAG field.

10-Byte Header for Block 1

10-Byte Header for Block 2

10-Byte Header for Block 3

10-Byte Header for Block n

Block 1

Block 2

Block 3

……………..

32-Bit ADDRESS

32-Bit COUNT

16-Bit FLAG

Figure 3. 10-Byte Header Contents

This 10-byte header, which precedes each block in the loader file, contains the following information used
by the on-chip Boot ROM during the boot process:

 ADDRESS (4 bytes) – the target address, to which the block will be booted within memory
 COUNT (4 bytes) – the number of bytes in the block
 FLAG (2 bytes) – block type and control commands:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

ZEROFILL

FINAL

0 - Non-Last Block
1 - Last Block

Figure 4. Individual Control Bits of the FLAG Word

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 3 of 29

PFLAG 3:0

PF number for
SPI slave booting

INIT

0 - Non-Init Block
1 - Init Block

IGNORE

0 - Non-Ignore Block
1 - Ignore Block

0 - Non-Zero Fill Block
1 - Zero-Fill Block

RESVECT

0 - ADSP-BF531/BF532
1 - ADSP-BF533

The FLAG bits include:

 Bit 0: ZEROFILL - Indicates that the block is a buffer with zeros. ZEROFILL blocks have no

payload data. They simply instruct the on-chip Boot ROM to zero COUNT bytes starting from

ADDRESS in memory. This yields a condensed loader file for applications with large zero buffers. It

is also very helpful for ANSI-C compliant projects which often require large buffers to be zeroed
during boot time.

 Bit 1: RESVECT – Indicates the reset vector after booting. All ADSP-BF531/BF532/BF533

derivatives use the same Boot ROM. This bit is set to 0 for the ADSP-BF531/BF532 and it is set to
1 for the ADSP-BF533. After booting is complete, the on-chip Boot ROM uses this bit to jump to
address
BF531/BF532.

L

0xFFA0 0000 for the ADSP-BF533 or to address 0xFFA0 8000 for the ADSP-

After a hardware reset, the reset vector (stored in the EVT1 register) is set to 0xFFA0 0000
or 0xFFA0 8000, depending on the RESVECT bit. If bit 4 (No Boot on Software Reset) of
the SYSCR register is set and a software reset is issued, the processor will vector to the
address set in the EVT1 register. This reset vector can be reconfigured to another address
during runtime and hence, an application can vector to an address other than 0xFFA0 0000
or 0xFFA0 8000 after a software reset. If the reset vector is modified during runtime,
ensure that the reset vector address within the EVT1 register is a valid instruction address.
This address can be internal instruction memory, SDRAM memory, or asynchronous
memory. The EVT1 register does not have a default value. The value within this register
will be retained after a reset is issued. When BMODE = 00, the on-chip Boot ROM is
bypassed and you must initialize the EVT1 register before issuing a software reset.

a

 Bit 3: INIT – An initialization block (Init Block) is a block of code that executes before the actual

application code boots over it. 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). After the initialization code is executed, it is typically overwritten with application code. See

Figure 5.

 Bit 4: IGNORE – Indicates a block that is not booted into memory. It instructs the Boot ROM to

skip COUNT bytes of the boot stream. In master boot modes, the Boot ROM can just modify its
source address pointer. In slave boot modes, the Boot ROM must actively trash the payload data.
The current VisualDSP++® tools support IGNORE blocks for global headers only (currently the 4­byte DXE Count, see Multi-Application (Multi-DXE) Management section below).

 Bits 8:5: PFLAG - These bits are used for SPI Slave mode boot (BMODE = 10). PFLAG indicates the

PFx number used for the host wait (HWAIT) signal from the Blackfin processor to the Master SPI

host. This value can be between 1 – 15 (
Refer to the SPI Slave Mode Boot via Master Host (BMODE = 10) section below for further
information on the usage of this PF strobe.

 Bit 15: FINAL – Indicates boot process is complete after this block. After processing a FINAL

block, the on-chip Boot ROM jumps to the reset vector address stored in the
processor is still in Supervisor mode and in the lowest priority interrupt (IVG15) when it jumps to
L1 memory for code execution.

0x1 – 0xF) for ADSP-BF531/BF532/BF533 processors.

EVT1 register. The

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 4 of 29

A

A

A

A

a

Unlike ADSP-BF535 processors, ADSP-BF531/BF532/BF533 processors do not require a second-

L

stage loader. The FLAG field of the 10-byte header provides ADSP-BF531/BF532/BF533
processors with all the information needed to execute a single-stage boot sequence without the
need for a second-stage loader.

Initialization Code (Init Code)

Init Code is a feature that allows the execution of a piece code before the actual application is booted in.
This code can serve a number of purposes including initializing the SDRAM controller, or changing PLL
settings, the SPI baud rate, or EBIU wait states for faster boot time, etc. The Init Code is added to the
beginning of the loader file stream via the elfloader –Init Init_Code.DXE command-line switch, where

Init_Code.DXE refers to the user-provided custom initialization code executable.

ADSP-BF531/BF532/BF533 Processor

L1 Memory

0xEF00 0000

On-Chip Boot

ROM

After Init Code
Execution

Init Block

Flash/PROM or SPI Device

Header for Init Block

Init Block

Header for L1 Block

L1 Block

Header for SDRAM Block

SDRAM Block

........

Header for Block n

Block n

SDRAM

ADSP-BF531/BF532/BF533 Processor

L1

0xEF00 0000

On-Chip Boot

ROM

Init Block

L1 Block

pp.
Code/
Data

Flash/PROM or SPI Device

Header for Init Block

Init Block

Header for L1 Block

L1 Block

Header for SDRAM Block

SDRAM Block

........

Header for Block n

Block n

SDRAM

SDRAM Block

Code/
Data

pp.

Figure 5. Initialization Code Execution / Boot

When the on-chip Boot ROM detects a block with the INIT bit set, it will first boot it into Blackfin
memory and then execute it, by issuing a

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 5 of 29

CALL to its target address. For this reason, you must terminate

a

the Init Code with an RTS instruction to ensure that the processor vectors back to the on-chip Boot ROM
for the rest of the boot process.

It is your responsibility to save all processor registers modified by Init Code and to restore them

L

before the Init Code returns. At a minimum, it is recommended that every Init Code saves the

ASTAT, RETS, and all Rx and Px registers. The Blackfin processor provides sufficient stack space in

scratchpad memory (

0xFFB0 0000 – 0xFFB0 0FFF). The Init Code can perform push and pop

operations through the stack pointer SP. Listing 1 shows an example Init Code file that
demonstrates the setup of the SDRAM controller.

#include <defBF532.h>
.section program;
/********************************************************************/
[--SP] = ASTAT; // Save registers onto Stack
[--SP] = RETS;
[--SP] = (R7:0);
[--SP] = (P5:0);
/********************************************************************/
/*******Init Code Section********************************************/
/*******SDRAM Setup************/
Setup_SDRAM:
P0.L = lo(EBIU_SDRRC);
P0.H = hi(EBIU_SDRRC); // SDRAM Refresh Rate Control Register
R0 = 0x074A(Z);
W[P0] = R0;
SSYNC;

P0.L = lo(EBIU_SDBCTL);
P0.H = hi(EBIU_SDBCTL); // SDRAM Memory Bank Control Register
R0 = 0x0001(Z);
W[P0] = R0;
SSYNC;

P0.L = lo(EBIU_SDGCTL);
P0.H = hi(EBIU_SDGCTL); // SDRAM Memory Global Control Register
R0.H = 0x0091;
R0.L = 0x998D;
[P0] = R0;
SSYNC;
/********************************************************************/
(P5:0) = [SP++]; // Restore registers from Stack
(R7:0) = [SP++];
RETS = [SP++];
ASTAT = [SP++];
/********************************************************************/
RTS;

Listing 1. Example Init Code

Typically, an Init Code consists of a single section and is represented by a single block within the boot
stream. This block has, of course, the

INIT bit set. Nevertheless, an Init Block can also consist of multiple

sections. Then, multiple blocks represent the Init Code within the boot stream. Only the last block has the

INIT bit set. The elfloader utility ensures that the last of these blocks vectors to the Init Code’s entry

address. If this is too challenging for the elfloader, it keeps the INIT bit cleared even for the last block and
issues one extra block afterward. This extra block has the

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 6 of 29

INIT bit set, but does not provide any payload

t

a

data (COUNT = 0). It only instructs the on-chip Boot ROM to execute a CALL instruction to the given

ADDRESS.

Although Init Code

.DXE files are built through their own VisualDSP++ projects, they differ from

standard projects. Init Codes provide a callable sub-function only, and thus, they look more like a library
than an application. An Init Code is always a heading for the regular application code. Consequently,
regardless whether the Init Code consists of one or multiple blocks, it is not terminated by a FINAL bit
indicator, which would cause the Boot ROM to terminate the boot process.

Multi-Application (Multi-DXE) Management

In addition to pre-boot initialization, the Init Code feature can also be used for boot management. A loader
file (.LDR) can store multiple applications if multiple executables (.DXE files) are listed on the elfloader
command line. The elfloader creates multiple boot streams with the individual executables appended one
after the other with the Init Code DXE located at the beginning (see Figure 6).

s

1

Boot

Stream

2nd

Boot

Stream

3rd

Boot

Stream

th

4

Boot

Stream

Etc..

10-Byte Header for Count

4-Byte Count for Init Code DXE

Init Code

10-Byte Header for Count

4-Byte Count for 1st DXE

1st DXE Application

10-Byte Header for Count

4-Byte Count for 2nd DXE

2nd DXE Application

10-Byte Header for Count

4-Byte Count for 3rd DXE

3rd DXE Application

……………………….

Loader File

10-Byte Header for Block 1

Block 1

10-Byte Header for Block 2

Block 2

10-Byte Header for Block 3

Block 3

……………….

Figure 6. Multi-DXE Loader File Contents

The ADSP-BF531/BF532/BF533 loader file (.LDR) structure allows you to determine the boundary
between executables (DXE applications) stored in external memory, and hence, the ability to boot in a
specific DXE application. Each .DXE file that is parsed and placed within the .LDR file is preceded by an

IGNORE block. Currently, this IGNORE block contains a 4-byte count value, which is the number of bytes

contained within the DXE application including headers. In other words, it is the offset to the next DXE

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 7 of 29

a

application. In the future, the IGNORE block might be used to hold information in addition to the 4-byte
count value. Note that each

IGNORE block is headed by a 10-byte header.

With this DXE count information, a user can essentially “jump” through whole DXE application within
the

.LDR file until the DXE application chosen to be booted in is reached. Listing 2 shows a piece of Init

Code that demonstrates how to stream through multiple DXE applications from an 8-bit flash. Assuming
the .LDR file contains one Init Code DXE and two DXE applications, the Init Code jumps through the

.LDR file to boot in the second DXE application.

#include <defbf533.h>
.section program;
[--SP] = ASTAT; // save registers onto Stack
[--SP] = RETS;
[--SP] = (r7:0);
[--SP] = (p5:0);
[--SP] = LC0;
[--SP] = LT0;
[--SP] = LB0;
/******************************/
BOOT_DXE:
R0.H = 0x2000; // R0 = start of ASYNC Bank 0
R0.L = 0x0000;
P1 = 2; // Number of DXEs to jump over (CANNOT BE ZERO!!)
// After first iteration, R0 will point to DXE1
// After second iteration, R0 will point to DXE2
LSETUP(ADD_DXE_COUNT_BEGIN, ADD_DXE_COUNT_END) LC0 = P1;
ADD_DXE_COUNT_BEGIN:
R1 = 0xA; // Skip over 10 bytes for the 1st 10-byte header
R1 = R1 << 1; // Multiply by 2 since we are booting from a 16-bit
// flash (compensate for zero padding)
R0 = R0 + R1;
P0 = R0; // P0 points to 4-Byte DXE COUNT
R0 = W[P0++](Z); // R0 = xx | Bits[7:0] of DXE COUNT
R1 = W[P0++](Z); // R1 = xx | Bits[15:8] of DXE COUNT
R1 = R1 << 8;
R2 = W[P0++](Z); // R2 = xx | Bits[23:16] of DXE COUNT
R2 = R2 << 16;
R3 = W[P0++](Z); // R3 = xx | Bits[31:24] of DXE COUNT
R3 = R3 << 24;
R0 = R0 | R1; // R0 = Bits[15:0] of DXE COUNT
R2 = R2 | R3; // R2 = Bits[31:16] of DXE COUNT
R3 = R0 | R2; // R3 = DXE COUNT
R0 = P0;
R0 = R0 + R3; // Modify pointer by the DXE COUNT so now R0 points
P0 = R0; // to next DXE
ADD_DXE_COUNT_END:
NOP;
/******************************/
DONE:
LB0 = [SP++]; // Restore Regs
LT0 = [SP++];
LC0 = [SP++];
(p5:0) = [SP++];
(r7:1) = [SP++]; //----->DO NOT RESTORE R0<-------
RETS = [SP++]; // Modify SP by one for R0 case
RETS = [SP++]; // Pop off the real value of RETS
ASTAT = [SP++];

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 8 of 29

RTS;

Listing 2. Example Init Code for Multi-DXE Boot

Note that the date register, R0, is not restored at the end of the Init Code because R0 is the external pointer
for a flash/PROM boot (
the RTS instruction, the on-chip Boot ROM will continue booting from the location stored in R0. Similarly,
if the boot mode is set for SPI booting (BMODE = 11), the external pointer is stored in R3. Hence, for an
SPI boot, do not restore R3 within the Init Code for a multi-DXE application.

Attached to this EE-Note is a multi-DXE boot example (BF533 Ez Kit Multiple DXE Boot.zip) that
uses the ADSP-BF533 EZ-KIT Lite® board. The ZIP file contains two blink application projects and an
Init Code project. Upon RESET, the on-chip Boot ROM will boot in the Init Code. The Init Code will then
wait until
booted in and executed. If
that blinks alternate LEDs on the board, and DXE2 is an application that blinks all the LEDs on the board.

PF8 (SW4 push button) or PF9 (SW5 push button) are asserted. If PF8 is asserted, DXE1 will be

BMODE = 01). When the processor returns back to the on-chip Boot ROM after

PF9 is asserted, DXE2 will be booted in and executed. DXE1 is an application

a

ADSP-BF533 Blackfin® Booting Process (EE-240) Page 9 of 29