Table of Contents
Advertisement
Each DXE application is represented by a complete boot stream in the
file. By definition, each boot stream is preceded by a special
.LDR
IGNORE block. Currently, this IGNORE block contains a 4-byte pointer
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
application.
This relative Next DXE Pointer (NDP) guides to the start address of the
next boot stream. In the most likely case, when one boot stream appends
to the other contiguously, the NDP also represents the byte count of the
boot stream it is heading, with the exception of the first IGNORE block.
This is why the NDP is often called "DXE byte count" as in
Note that each IGNORE block is headed by a 10-byte header.
Currently, the initial IGNORE block contains only 4 bytes of data
to store the NDP. In future VisualDSP++ versions the length of
initial IGNORE blocks may increase without further notice.
With this NDP, the boot streams are structured like a chained list. The
user can essentially "jump" through whole DXE applications within the
file until the DXE application chosen to be booted in is reached.
.LDR
User-callable Boot ROM Functions
The boot ROM contains a set of functions that can be called at runtime
from the user code. The major purpose of these functions is to support
multi-DXE and second-stage loader scenarios.
Booting a Different Application
As discussed in
page
19-26, Blackfin hardware must often execute different applications.
In slave boot modes the host device may be required to pull the processor's
pin and to provide new application data through the interface
RESET
ADSP-BF537 Blackfin Processor Hardware Reference
"Multi-Application (Multi-DXE) Management" on
System Reset and Booting
Figure
19-9.
19-27
Advertisement
Table of Contents
