• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 380 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6457 SRIO Boot not working

Jorgen
Prodigy 110 points

I am working with 2 C6457s directly connected through SRIO.
DSP1 boots from flash memory and copies the program for DSP2 to
the start of L2. A doorbell is sent to wake up DSP2 which should start
executing from L2.

DOORBELL_INTR_0_DOORBELL_ICSR has bit 0 set
DOORBELL_INTR_ROUTE_0_DOORBELL_ICRR routes this bit to INTDST0
INTDST0_DECODE has bit 0 set
and this triggers EVTFLAG_0 (Event 20).

Event 20 through INTMUX1 should set INT4.

IER is however 0x00000001 which means INT4 is masked, and thus my doorbell
never gets there.

**********************************
Tests:

1.
Using CCS I can set the program counter to start of L2 and the program
runs as expected. This leads me to the conclusion that SRIO works fine
including the Doorbell.

2.
Running the example code for the C6457 EVM (SrioBoot) I can see that the
IER is set to 0x00000043. This indicates to me that INT6 is enabled and that
INTMUX1 should route event 20 to INT6 rather than INT4 as I am observing.

3. Reading the GPIO using CCS with no program loaded I observe that the only
   difference between the EVM and my setup is the HPI bus width. 32(EVM) vs
   16. This leads me to beleive that the bootload in L3 rom should initialize
   the board in the same way. (But it is not...).

************************************
Questions:

1. I am wondering what affects interrupt enable setting during startup.
   Are there other factors than the GPIO defined bootmode?
   (SRIO Boot mode 11 - Config 1)
   The reason for this question is that the EVM and my board has the same
   bootmode, but different IER.

2. Are there any way that I could set IER, ISR or even PC in DSP2 from DSP1?


Any help with this issue would be greatly appreciated.

  • 0
    TI__Mastermind 23525 points

    Jorgen,

     

    This may be related to an issue that was already discovered for SRIO boot and described in Bootloader user's guide:

    "The bootloader version for silicon v1.0 is v1.5 Wed Dec 12 14:57:46 2007 i2c mac rapidio. The bootloader
    version for silicon v1.2 is v1.6 Tue Oct 28 11:15:10 2008 i2c mac rapidio.
    There are two known issues in the v1.5 bootloader:
    1. The bootp packet is not sent out in the EMAC boot mode.
    2. In SRIO boot mode when 4x mode falls back to 1x mode in certain hardware configurations, the boot
    does not operate correctly. The workaround is: after the host sends the application image, the host
    needs to write an application entry point to 0x9FFFFC and then, send the doorbell interrupt.

    These problems have been fixed in the v1.6 bootloader."

     

    So you're boot config is for 1 port 4X mode, all are four lanes connected between the DSPs?  This is believed to be a problem only when the 1 port configuration can not establish a 4X connection and falls back to 1X mode on either lane 0 or 2.  Essentially, what happened was the boot rom code had a timer built in to it that expected the port to initialize (Port_ok =1) before it expired.  This is usually not a problem unless it falls back to 1X because the timer value was actually shorter than the SRIO discovery timer (length of time it tries to establish a 4X connection before falling back).  When this situation happens, the DSP goes to the exception handler and spins until the PC is written to something other than 0.  So, even though the program load and Doorbell interrupt through SRIO were successful, the DSP would just sit there an not jump to the PC.  The fix as stated above is to send the program via SRIO, send a NWRITE packet to address 0x9FFFFC that points to your PC (presumably 0x800000) via SRIO, then finally the Doorbell as normal.  That answers your #2 question, I'm not sure about #1. 

    Let me know if that fixes it.

     

    Regards,

    Travis

  • 0 in reply to tscheck
    Prodigy 110 points

    Hi Travis,

    Thank you for your answer. At this point the "solution" to this problem came about while implementing a workaround.

    DSP2 is connected to an FPGA and if DSP1 does a reset of DSP2 before sending the code via SRIO, DSP2 will then come up with the interrupts enabled so that the doorbell has the desired effect.

    The sequnce.

    * Power on

    * Boot DSP1 from flash

    * Configure FPGA

    * DSP1 reset DSP2

    * DSP1 sends code to DSP2

    *DSP1 sends doorbell

    *DSP2 boots.  

     

    What I am seeing is that every time after power on the boot mode is correct and the correct code is loaded at 0x80000 (I have verified the contents), but interrupts are masked.The doorbell interrupt has been received and all the expected status bits are set. Reset the DSP and it comes up with the expected settings.

     

    Thanks,

    Jorgen

     

  • 0 in reply to Jorgen
    TI__Mastermind 23525 points

    Glad you solved it.

     

    Regards,

    Travis