Hello,

I am able to find only the sprn163.pdf paper.  The spra554c.pdf and
spru1861.pdf are not available.


"Suodatin Pussi" <Suodatin_Pussi@kokonaisuutena.hotmail.com> wrote in
message news:40e6cb5f$0$65807$e4fe514c@news.xs4all.nl...
> Peter Choi wrote:
> > Hello,
> >
> > Sorry but what are these QDMA and BSS thing about?  Is there a place
online
> > where I can find a good tutorial of what is the boot loader about and
how do
> > I use it?
> >
> >
> Hi Peter,
>
> I'm just in the process of reading and trying so I have no clear answers
>   for you.
>
> QDMA (quick dma) is a feature of the EDMA module (see spru401e.pdf). At
> boot time the dma controller loads the first 1k from flash to ram.
>
> .bss (blank static storage) is just the section (one of the many) where
> a c-program places its unitialized data. Since this section is totally
> empty, a bootloader could be put here.
>
> read spra554c.pdf, sprn163.pdf, chapter 11 of spru186l.pdf (hex utility)
> you can find them on ti's website.
>
> Btw, I just received a bunch of code from TI (these guys are really
> nice) with examples etc.. I'll keep you informed but for now I wish you
> happy holidays
>
> S

Peter Choi wrote:
> Hello,
> 
> Sorry but what are these QDMA and BSS thing about?  Is there a place online
> where I can find a good tutorial of what is the boot loader about and how do
> I use it?
> 
> 
Hi Peter,

I'm just in the process of reading and trying so I have no clear answers
  for you.

QDMA (quick dma) is a feature of the EDMA module (see spru401e.pdf). At
boot time the dma controller loads the first 1k from flash to ram.

.bss (blank static storage) is just the section (one of the many) where
a c-program places its unitialized data. Since this section is totally
empty, a bootloader could be put here.

read spra554c.pdf, sprn163.pdf, chapter 11 of spru186l.pdf (hex utility)
you can find them on ti's website.

Btw, I just received a bunch of code from TI (these guys are really
nice) with examples etc.. I'll keep you informed but for now I wish you
happy holidays

S

Hello,

Sorry but what are these QDMA and BSS thing about?  Is there a place online
where I can find a good tutorial of what is the boot loader about and how do
I use it?

Brad Griffis wrote:


> 
> When you do the boot from flash the qdma copies the first _1k_ of memory
> from flash to address 0x0.  This is the reason why you need a secondary
> bootloader.  Unless your code all fits into 1k then you need to write code
> to copy the rest of your code to the appropriate place in memory.
> 

true, my mistake. the 64k comes from, i believe, the 62xx series but
even 64k would not be enough.

> 
> I'd go for option 3.  Make sure you read about the hex conversion utility as
> well as various linker commands like load_address, run_address, etc (those
> aren't the exact names but it's something like that).
> 

Thanks, I read about load and run adresses and already flashed a small
assembly program into my dsk. But flashing and bootloading a compiled
c-program seems to have more overhead than assembly (more sections, a
c_init start address).

Thanks

"Suodatin Pussi" <Suodatin_Pussi@kokonaisuutena.hotmail.com> wrote in
message news:40e46e6a$0$34762$e4fe514c@news.xs4all.nl...
> Thanks Brad,
>
> Brad Griffis wrote:
> >
> > The DSP needs to be executing something while the copy occurs.  That
being
> > the case you might as well just have the CPU do the actual copy instead
of
> > the QDMA.  I suppose you could poll something to see when the transfer
> > completes but you might as well just be copying.
>
> The problem is that the dsp only will run from 0x00 on reset. 0x00 is
> ram so there's no code to run at startup. So, as I understand, the
> (quick) dma controller copies 64k from flash to ram at boottime while
> the dsp is held at reset after which it is released and executes from
> 0x00. The 64k is to small to fit a reasonable program (compiled c-code)
> so it must contain a bootloader which loads the actual program. I don't
> think there's an alternative.

When you do the boot from flash the qdma copies the first _1k_ of memory
from flash to address 0x0.  This is the reason why you need a secondary
bootloader.  Unless your code all fits into 1k then you need to write code
to copy the rest of your code to the appropriate place in memory.

> >
> >> 1) So I could load the bootloader at 0x00 run it and overwrite it at
the
> >> end with the ivec + data (not a good option I think)
> >
> > This could be a possibility but I think your third idea is the best.
> >
> >> 2) Or is it better to run the booloader from flashrom which means I'll
> >> directly have jump to the flashrom after the bootsequence?
> >
> > This seems like it would work.  Perhaps there is a disadvantage (speed?)
> > which I am overlooking.
>
> It should work but it's slower, but it's only for a short time (during
> copying).
>
> >
> >> 3) Or should I point my blanc static storage (.bss), which is empty
till
> >> the actual program start running, to this lower location. So that it
can
> >> be used by the bootloader before the actual program runs.
> >
> > I think this is how they usually do it.  In your linker command file
(.cmd)
> > you'll need to do a memory overlay.  This can be done using a UNION or
> > INTERSECTION.
> >
>
> Thanks for your response. It gives me some clues where to look. I'll try
> to work out 2 and 3.
>
> S

I'd go for option 3.  Make sure you read about the hex conversion utility as
well as various linker commands like load_address, run_address, etc (those
aren't the exact names but it's something like that).

Cheers,

Brad

Thanks Brad,

Brad Griffis wrote:
> 
> The DSP needs to be executing something while the copy occurs.  That being
> the case you might as well just have the CPU do the actual copy instead of
> the QDMA.  I suppose you could poll something to see when the transfer
> completes but you might as well just be copying.

The problem is that the dsp only will run from 0x00 on reset. 0x00 is
ram so there's no code to run at startup. So, as I understand, the
(quick) dma controller copies 64k from flash to ram at boottime while
the dsp is held at reset after which it is released and executes from
0x00. The 64k is to small to fit a reasonable program (compiled c-code)
so it must contain a bootloader which loads the actual program. I don't
think there's an alternative.

> 
>> 1) So I could load the bootloader at 0x00 run it and overwrite it at the
>> end with the ivec + data (not a good option I think)
> 
> This could be a possibility but I think your third idea is the best.
> 
>> 2) Or is it better to run the booloader from flashrom which means I'll
>> directly have jump to the flashrom after the bootsequence?
> 
> This seems like it would work.  Perhaps there is a disadvantage (speed?)
> which I am overlooking.

It should work but it's slower, but it's only for a short time (during
copying).

> 
>> 3) Or should I point my blanc static storage (.bss), which is empty till
>> the actual program start running, to this lower location. So that it can
>> be used by the bootloader before the actual program runs.
> 
> I think this is how they usually do it.  In your linker command file (.cmd)
> you'll need to do a memory overlay.  This can be done using a UNION or
> INTERSECTION.
> 

Thanks for your response. It gives me some clues where to look. I'll try
to work out 2 and 3.

S

"Suodatin Pussi" <Suodatin_Pussi@kokonaisuutena.hotmail.com> wrote in
message news:40e33d0a$0$36169$e4fe514c@news.xs4all.nl...
> Hi,
>
> Has any of you already successfully written a bootloader for the 6711
> dsk? I'm trying to find out what my options are.
> At the end I need an interrupt vector table at 0x00 and a lot of fast
> internal ram for my data (filters), the same location where the
> bootloader will be loaded at the bootsequence (first 64 k).
> btw the bootsequence is an action of the qdma which copies the first 64k
> from flash to ram after which the dsp resets and executes from 0x00.

The DSP needs to be executing something while the copy occurs.  That being
the case you might as well just have the CPU do the actual copy instead of
the QDMA.  I suppose you could poll something to see when the transfer
completes but you might as well just be copying.

> 1) So I could load the bootloader at 0x00 run it and overwrite it at the
> end with the ivec + data (not a good option I think)

This could be a possibility but I think your third idea is the best.

> 2) Or is it better to run the booloader from flashrom which means I'll
> directly have jump to the flashrom after the bootsequence?

This seems like it would work.  Perhaps there is a disadvantage (speed?)
which I am overlooking.

> 3) Or should I point my blanc static storage (.bss), which is empty till
> the actual program start running, to this lower location. So that it can
> be used by the bootloader before the actual program runs.

I think this is how they usually do it.  In your linker command file (.cmd)
you'll need to do a memory overlay.  This can be done using a UNION or
INTERSECTION.

Brad

Hi,

Has any of you already successfully written a bootloader for the 6711
dsk? I'm trying to find out what my options are.
At the end I need an interrupt vector table at 0x00 and a lot of fast
internal ram for my data (filters), the same location where the
bootloader will be loaded at the bootsequence (first 64 k).
btw the bootsequence is an action of the qdma which copies the first 64k
from flash to ram after which the dsp resets and executes from 0x00.

1) So I could load the bootloader at 0x00 run it and overwrite it at the
end with the ivec + data (not a good option I think)
2) Or is it better to run the booloader from flashrom which means I'll
directly have jump to the flashrom after the bootsequence?
3) Or should I point my blanc static storage (.bss), which is empty till
the actual program start running, to this lower location. So that it can
be used by the bootloader before the actual program runs.

Any suggestions?

Thanks,

S