Hi all
I am just starting to learn about the sharc family of ADSP-...,
previously I have only been using ADSP-218x processors so please bear
with me if this question is trivial to experienced sharc users.
Due to an expected memory constraint in the project I have just been
assigned to which will be using the ADSP-21375, we want to split out
some of the software to different builds which must only run just
after power on. There could be one or several builds with special
start up functions - I don't know yet, but expect 2-3 builds (boot
images) all together.
Therefore I have been trying to figure out a way to boot several boot
images - one at a time - to a single sharc ADSP-21375, And I have been
reading the following in my pusuit for a solution:
EE272 (does sort of the same thing but for a black fin, and with a
second stage boot loader. I am not sure how to use this example, or if
I even can since 1. it is meant for a black fin, and 2. it uses a
second stage loader to perform the magic, and I need all input and
output (i.e. intrrupts) enabled for each boot image, and the image
needs to perform a certain task before loading the next image.)
EE55, 56, 108 and 117 as well as skimming through the loader and
utilities manuals for the sharc and Visual DSP++ 4.5.
I think what I should do is make a modified boot loader and include in
each intermediate boot image, and when the intermediate program has
finished it's job it will call the modified boot loader which must
then load the next boot image.
My question(s) are:
1. Does anyone have any advice on porting the blackfin example from
EE272 to a sharc multi boot with a second stage loader, and does this
example allow the interrupt vector table to be present while the
second stage bootloader is controlling the system?
2. Does anyone have any advice or comments regarding my proposed
modified boot loader ?
3. If you think neither approach satisfies the requirements, do you
have a better idea you will share with me?
Best regards Lars Olesen
Single processor multiple boot from 8 bit EPROM
Started by ●July 14, 2006
Reply by ●July 14, 20062006-07-14
On Fri, 14 Jul 2006, olesenlars wrote:
> I think what I should do is make a modified boot loader and include in
> each intermediate boot image, and when the intermediate program has
> finished it's job it will call the modified boot loader which must
> then load the next boot image.
That sounds like an excellent plan. If you have to skip one stage, or add
another stage later this will easily handle the exceptions. Sounds like
you are on the right track to me!
Patience, persistence, truth,
Dr. mike
> I think what I should do is make a modified boot loader and include in
> each intermediate boot image, and when the intermediate program has
> finished it's job it will call the modified boot loader which must
> then load the next boot image.
That sounds like an excellent plan. If you have to skip one stage, or add
another stage later this will easily handle the exceptions. Sounds like
you are on the right track to me!
Patience, persistence, truth,
Dr. mike
Reply by ●July 14, 20062006-07-14
I did a similar design on a 21262.
I modified the bootloader so that I could specify the starting address
with a #define that I would set when I compiled the code.
Then I included a loader (with a specific address) into each link so
that I could call that loader from image B and go to image C.
The next challenge after that is to put all of these images into FLASH
properly. I ended up writing a script using SED to piece everything
together.
It sounds like you want the interrupts to run while all of this is
happening. This will be the interesting part.
You can probably get that to happen by enabling interrupts in the
loader, and making sure the interrupt handler is and IVT is only
defined in the first image.
--- In a..., "olesenlars" wrote:
>
> Hi all
>
> I am just starting to learn about the sharc family of ADSP-...,
> previously I have only been using ADSP-218x processors so please bear
> with me if this question is trivial to experienced sharc users.
> Due to an expected memory constraint in the project I have just been
> assigned to which will be using the ADSP-21375, we want to split out
> some of the software to different builds which must only run just
> after power on. There could be one or several builds with special
> start up functions - I don't know yet, but expect 2-3 builds (boot
> images) all together.
>
> Therefore I have been trying to figure out a way to boot several boot
> images - one at a time - to a single sharc ADSP-21375, And I have been
> reading the following in my pusuit for a solution:
> EE272 (does sort of the same thing but for a black fin, and with a
> second stage boot loader. I am not sure how to use this example, or if
> I even can since 1. it is meant for a black fin, and 2. it uses a
> second stage loader to perform the magic, and I need all input and
> output (i.e. intrrupts) enabled for each boot image, and the image
> needs to perform a certain task before loading the next image.)
> EE55, 56, 108 and 117 as well as skimming through the loader and
> utilities manuals for the sharc and Visual DSP++ 4.5.
>
> I think what I should do is make a modified boot loader and include in
> each intermediate boot image, and when the intermediate program has
> finished it's job it will call the modified boot loader which must
> then load the next boot image.
>
> My question(s) are:
> 1. Does anyone have any advice on porting the blackfin example from
> EE272 to a sharc multi boot with a second stage loader, and does this
> example allow the interrupt vector table to be present while the
> second stage bootloader is controlling the system?
>
> 2. Does anyone have any advice or comments regarding my proposed
> modified boot loader ?
>
> 3. If you think neither approach satisfies the requirements, do you
> have a better idea you will share with me?
>
> Best regards Lars Olesen
>
I modified the bootloader so that I could specify the starting address
with a #define that I would set when I compiled the code.
Then I included a loader (with a specific address) into each link so
that I could call that loader from image B and go to image C.
The next challenge after that is to put all of these images into FLASH
properly. I ended up writing a script using SED to piece everything
together.
It sounds like you want the interrupts to run while all of this is
happening. This will be the interesting part.
You can probably get that to happen by enabling interrupts in the
loader, and making sure the interrupt handler is and IVT is only
defined in the first image.
--- In a..., "olesenlars" wrote:
>
> Hi all
>
> I am just starting to learn about the sharc family of ADSP-...,
> previously I have only been using ADSP-218x processors so please bear
> with me if this question is trivial to experienced sharc users.
> Due to an expected memory constraint in the project I have just been
> assigned to which will be using the ADSP-21375, we want to split out
> some of the software to different builds which must only run just
> after power on. There could be one or several builds with special
> start up functions - I don't know yet, but expect 2-3 builds (boot
> images) all together.
>
> Therefore I have been trying to figure out a way to boot several boot
> images - one at a time - to a single sharc ADSP-21375, And I have been
> reading the following in my pusuit for a solution:
> EE272 (does sort of the same thing but for a black fin, and with a
> second stage boot loader. I am not sure how to use this example, or if
> I even can since 1. it is meant for a black fin, and 2. it uses a
> second stage loader to perform the magic, and I need all input and
> output (i.e. intrrupts) enabled for each boot image, and the image
> needs to perform a certain task before loading the next image.)
> EE55, 56, 108 and 117 as well as skimming through the loader and
> utilities manuals for the sharc and Visual DSP++ 4.5.
>
> I think what I should do is make a modified boot loader and include in
> each intermediate boot image, and when the intermediate program has
> finished it's job it will call the modified boot loader which must
> then load the next boot image.
>
> My question(s) are:
> 1. Does anyone have any advice on porting the blackfin example from
> EE272 to a sharc multi boot with a second stage loader, and does this
> example allow the interrupt vector table to be present while the
> second stage bootloader is controlling the system?
>
> 2. Does anyone have any advice or comments regarding my proposed
> modified boot loader ?
>
> 3. If you think neither approach satisfies the requirements, do you
> have a better idea you will share with me?
>
> Best regards Lars Olesen
>
Reply by ●August 23, 20062006-08-23
New question:
Up until now I have been looking at the prom loader from the ldr directory
under:
"...\Analog Devices\VisualDSP 4.5\213xx\ldr\" but recently I found out (I
have been away on vacation,
as well as assigned to another project in the meantime) that the device
will be booted from an SPI-flash.
However the multiprocessor tag which I intended to use to select the boot
image when booting from ROM
does not appear in the corresponding loader source code for SPI-flash.
Does anyone know why this is so?
Comments to previous reply from dthuringer:
a... wrote on 14-07-2006 16:22:39:
> I did a similar design on a 21262.
>
> I modified the bootloader so that I could specify the starting address
> with a #define that I would set when I compiled the code.
>
> Then I included a loader (with a specific address) into each link so
> that I could call that loader from image B and go to image C.
>
> The next challenge after that is to put all of these images into FLASH
> properly. I ended up writing a script using SED to piece everything
> together.
I have been reading EE-108 again, because I was told that a colleague of
mine
some time ago asked Analog Devices essentially the same question, and
received an answer
indicating that the approach in EE-108 was usable for what we wish to do.
It seems that with this method, VDSP++ 4.5 does most of the job for me,
putting the images in one
loader file, and I only need to modify the boot loader to use something
other than
the processor ID flag to select the image to boot.
I planned to use a specific memory location along with some crc check or a
bit pattern to ensure
against selecting an invalid boot image after cold boot to choose the image
to boot, but now
I am trying to find out why the 369_SPI boot loader source code does _not_
look for the multiprocessor
tag???
>
> It sounds like you want the interrupts to run while all of this is
> happening. This will be the interesting part.
> You can probably get that to happen by enabling interrupts in the
> loader, and making sure the interrupt handler is and IVT is only
> defined in the first image.
I think with this approach, I can have interrupts enabled, and the IVT
defined in each image,
and simply write a new image number (and either a bitpattern or a checksum
to indicate
that it is not just a random number) and perform a reboot when each image
has completed it's
task.
Best regards
Lars Olesen
Up until now I have been looking at the prom loader from the ldr directory
under:
"...\Analog Devices\VisualDSP 4.5\213xx\ldr\" but recently I found out (I
have been away on vacation,
as well as assigned to another project in the meantime) that the device
will be booted from an SPI-flash.
However the multiprocessor tag which I intended to use to select the boot
image when booting from ROM
does not appear in the corresponding loader source code for SPI-flash.
Does anyone know why this is so?
Comments to previous reply from dthuringer:
a... wrote on 14-07-2006 16:22:39:
> I did a similar design on a 21262.
>
> I modified the bootloader so that I could specify the starting address
> with a #define that I would set when I compiled the code.
>
> Then I included a loader (with a specific address) into each link so
> that I could call that loader from image B and go to image C.
>
> The next challenge after that is to put all of these images into FLASH
> properly. I ended up writing a script using SED to piece everything
> together.
I have been reading EE-108 again, because I was told that a colleague of
mine
some time ago asked Analog Devices essentially the same question, and
received an answer
indicating that the approach in EE-108 was usable for what we wish to do.
It seems that with this method, VDSP++ 4.5 does most of the job for me,
putting the images in one
loader file, and I only need to modify the boot loader to use something
other than
the processor ID flag to select the image to boot.
I planned to use a specific memory location along with some crc check or a
bit pattern to ensure
against selecting an invalid boot image after cold boot to choose the image
to boot, but now
I am trying to find out why the 369_SPI boot loader source code does _not_
look for the multiprocessor
tag???
>
> It sounds like you want the interrupts to run while all of this is
> happening. This will be the interesting part.
> You can probably get that to happen by enabling interrupts in the
> loader, and making sure the interrupt handler is and IVT is only
> defined in the first image.
I think with this approach, I can have interrupts enabled, and the IVT
defined in each image,
and simply write a new image number (and either a bitpattern or a checksum
to indicate
that it is not just a random number) and perform a reboot when each image
has completed it's
task.
Best regards
Lars Olesen
