Joe-
> I've got an FPGA on board, but the
'C6205 does not have a HPI only the
> PCI. Unless I'm mistaken it's always a PCI bus. There is no way
to
> reconfigure it.
Yes that seems to be correct. We've used a lot of C62xx and C64xx devices,
and
typically they have HPI port muxed with PCI port based on Reset-time config Rs.
But
C6205 seems to have only the PCI.
> The FPGA is on the DSP's bus anyway, not the
PCI bus (it
> glues the DSP to another proprietary bus structure). I'm exploring
the
> idea of placing the secondary bootloader code in the FPGA, but this
> approach is beginning to look like a Rube Goldberg mechanism as I may
have
> to dynamically re-assign chip selects after the secondary bootloader is
> done loading the application... Looks like the timing could be tricky.
Well if you ever wondered what the "RG Logic Support" feature means
for FPGAs...
-Jeff
> Jeff Brower <jbrower@jbro...>
> 10/13/2005 10:59 AM
>
> To
> Joe Futey <joe.futey@joe....>
> cc
> c6x@c6x@...
> Subject
> Re: [c6x] C6205 hardware boot loader / SDRAM problem
>
> Joe-
>
> > The PCI bus is totally embedded. The other devices on the bus do
not
> have
> > the memory resources to store the application code. The only path in
is
> > through a USB 1.1 controller which would make the application
download
> > time in excess of 20 seconds (too slow of a boot for our
customers).
> >
> > The application needs to be loaded into SDRAM because of it's
size, and
> > the DSP executing from cache to achieve performance. Using the ROM
seems
> > to be the only way to keep the boot time within customer
expectations.
>
> Ya Ok. I was thinking there might be another processor on this board.
>
> You don't have a CPLD on the board? A CPLD could read the Flash and
> download to DSP
> HPI at boot-time, then change the config R and reset the DSP into PCI
> mode.
>
> -Jeff
>
> > Jeff Brower <jbrower@jbro...>
> > 10/12/2005 06:24 PM
> >
> > To
> > Joe Futey <joe.futey@joe....>
> > cc
> > c6x@c6x@...
> > Subject
> > Re: [c6x] C6205 hardware boot loader / SDRAM problem
> >
> > Joe-
> >
> > > We are using the 'C6205 in an embedded system that is not
part of a
> PC.
> > > The 'C6205 is on an internal PCI bus used to communicate to
other PCI
> > > peripherals. Consequently it takes too long to load the boot code
into
> > the
> > > DSP in host boot mode. The DSP application is larger than 64K
and
> > requires
> > > that the internal RAM be used as cache to support the required
> execution
> > > speed, so MAP 1 cannot be used. That leaves MAP 0 boot from flash
as
> > the
> > > best possible option for us. After all, it is an advertised
option...
> > > I performed the following experiments in an attempt to debug the
SDRAM
> > > problem.
> >
> > I think you may be making this too hard. Can you boot a small amount
of
> > code via PCI
> > at boot-time, then once PCI bus stablizes and everybody is playing
> nicely
> > and
> > quietly, then have the DSP code signal the PCI host to download the
rest
> > of the
> > code? Or just have the PCI host wait a while?
> >
> > -Jeff
>
C6205 hardware boot loader / SDRAM problem
Started by ●October 12, 2005
Reply by ●October 13, 20052005-10-13
Reply by ●October 14, 20052005-10-14
Mike & Jeff,
TI DSP support has agreed to investigate the 'C6205 hardware boot loader /
SDRAM problem. They have arranged to get an EVM6205 board from eInfochips
sent to their facility so they can debug the issue.
Meanwhile, we have successfully implemented two work arounds...
The goal is to have the 1 MB application stored in ROM, moved into SDRAM
and the 'C6205 DSP executing the application out of the internal cache. We
were able to achieve this two different ways.
Method 1 (aka Tony's idea): By pass the hardware boot loader entirely.
1.) Burn only the application into the ROM.
2.) Boot mode is PCI, MAP 0, EXTERNAL memory @ 0x0000 0000 h.
3.) RESET board, DSP stalled waiting to be released by PCI bus.
3.) Through the PCI bus set SDRAM EMIF parameters and initialize SDRAM.
4.) Download a very small software boot loader into SDRAM @ 0x0000 0000 h.
5.) "Unstall" DSP.
6.) Software boot loader completes transfer of code from ROM to SDRAM,
enables cache.
7.) Application is resident in SDRAM and DSP is running from cache.
Method 2 (aka Mike's idea): Use the hardware boot loader mode that we know
works.
1.) Burn software boot loader and application into ROM.
2.) Boot mode is 8 bit ROM, MAP 1, INTERNAL memory @ 0x0000 0000 h.
3.) RESET board, hardware loads first 64K into internal memory.
4.) Software boot loader sets SDRAM EMIF parameters, initialize SDRAM. and
moves application from ROM to SDRAM.
5.) Control jumps to application in SDRAM.
6.) Application enables the cache wiping out the software boot loader
which is no longer needed.
7.) Application is resident in SDRAM and DSP is running from cache.
Both methods work. I think we are sticking with method 2 because the code
is encapsulated in a single entity and requires less effort to track and
maintain. It also allows the system to boot the DSP without intervention
over the PCI bus which can be useful for debugging other problems later.
Thank you for your help. I will post again with the results of TI's
investigation when they are available.
Best regards,
Joe
TI DSP support has agreed to investigate the 'C6205 hardware boot loader /
SDRAM problem. They have arranged to get an EVM6205 board from eInfochips
sent to their facility so they can debug the issue.
Meanwhile, we have successfully implemented two work arounds...
The goal is to have the 1 MB application stored in ROM, moved into SDRAM
and the 'C6205 DSP executing the application out of the internal cache. We
were able to achieve this two different ways.
Method 1 (aka Tony's idea): By pass the hardware boot loader entirely.
1.) Burn only the application into the ROM.
2.) Boot mode is PCI, MAP 0, EXTERNAL memory @ 0x0000 0000 h.
3.) RESET board, DSP stalled waiting to be released by PCI bus.
3.) Through the PCI bus set SDRAM EMIF parameters and initialize SDRAM.
4.) Download a very small software boot loader into SDRAM @ 0x0000 0000 h.
5.) "Unstall" DSP.
6.) Software boot loader completes transfer of code from ROM to SDRAM,
enables cache.
7.) Application is resident in SDRAM and DSP is running from cache.
Method 2 (aka Mike's idea): Use the hardware boot loader mode that we know
works.
1.) Burn software boot loader and application into ROM.
2.) Boot mode is 8 bit ROM, MAP 1, INTERNAL memory @ 0x0000 0000 h.
3.) RESET board, hardware loads first 64K into internal memory.
4.) Software boot loader sets SDRAM EMIF parameters, initialize SDRAM. and
moves application from ROM to SDRAM.
5.) Control jumps to application in SDRAM.
6.) Application enables the cache wiping out the software boot loader
which is no longer needed.
7.) Application is resident in SDRAM and DSP is running from cache.
Both methods work. I think we are sticking with method 2 because the code
is encapsulated in a single entity and requires less effort to track and
maintain. It also allows the system to boot the DSP without intervention
over the PCI bus which can be useful for debugging other problems later.
Thank you for your help. I will post again with the results of TI's
investigation when they are available.
Best regards,
Joe
