On Wed, 25 Apr 2001 11:14:44 -0400, Waldron, Donald M (N-BAE Systems)
wrote:
> I have a system with a Quad-SHARC (14060 with four
ADSP-21060's) and no
> host. Unique images for each 21060 plus two shared images will initially
> reside in 8-bit EPROM.
Similar system here, but 2 21065L's with shared SDRAM and 8-bit EPROM.
The EPROM is mapped through both BMS (boot memory select) and MS1
(memory space 1) so I can both boot from it and read it at runtime
without DMA, using ordinary CPU reads.
> According to the ADSP-2106x SHARC User's
Manual (chapter 11), there are two
> methods of booting a multiprocessor system:
>
> 1. Boot in turn from a single EPROM (all 21060's wired for PROM
Boot)
> 2. One 21060 is booted, which then boots others (DSP ID 1 wired for PROM
> boot; others Host Boot).
We use option 1, but we also load more code later.
> Our system needs to boot as fast as possible (to
meet a boot-time
> requirement). I'm inclined to use the PROM boot loader (060_prom.ldr)
in
> each 21060.
Can you give more info? How fast do you need to boot? Can you do this
in two steps, getting important stuff loaded immediately to meet your
spec and then loading less important stuff at your leisure?
You could get yet more speed by using a wider boot source and hacking
the loader.
> Q1. Are there changes needed to the Analog
Devices-provided 060_prom.ldr
> to support multiprocessor PROM Boot?
Didn't need to for 21065L, which I believe uses almost the same boot
loader, except for the addresses of the internal memory blocks (0x8000
vs. 0x20000?).
> Q2. Will each 21060 start executing the boot
loader at the same time and
> arbitrate for the external bus?
Correct.
> Q3. Should I plan on loading the shared images
from PROM to internal
> memory in my user application (the elfloader doesn't seem to allow
multiple
> .dxe files having the same ID using the -id<n>exe switch)?
I don't know what you're trying to do. The PROM image has a table
that,
for each ID, has an offset pointer to the matching code image. The
loader kernel simply scans this table for the CPU's ID and uses the
pointer found to resume loading that CPU. It wouldn't help to have a
second image with the same ID, as it would never be seen.
You *can* use the same image for multiple ID's, but the elfloader
doesn't support using only one copy; it will write a separate copy in
the EPROM for each CPU using it. It wouldn't be hard to write a
post-processor that cleaned out the duplicates and fixed the pointers,
though. (The load images are position-independent, so merging is
simple.)
If you're trying to implement a 2-stage boot, with more than one image
per CPU, use the unused CPU indices for the secondary images. Elfloader
doesn't support more than a 7-entry table, so you'd need to run it
twice to create 2 4-entry PROM images, then write a post-processor that
assembled the result into an 8-entry image.
There are appnotes on the ADI site explaining the PROM image format and
how the loader kernel works that I found quite helpful for this kind of
stuff.
|