Problems integrating DSPLINK with PSP Driver

Hi Matt,

Does the last post of the following thread correspond to the problem you are seeing?

http://community.em.avnet.com/t5/Spartan-6-OMAP-L138-Co/How-to-use-Linux-and-DSP-BIOS-at-the-same-time/td-p/3022

Best regards,

Vincent

Hi Vincent,

I don't that is the same problem we are encountering. The kick unlock was orginally proformed in a GEL file, so If I understand correctly the .out file should not contain any access to the kick register.

Thanks for the quick responce,

Matt

Hi Matt,

I inquired around and the actual issue was that the PSP driver was locking the KICK register through this kind of code sequence:

          SYSTEM->KICKR[0] = 0x83e70b13;  // Kick0 register + data (unlock)

          SYSTEM->KICKR[1] = 0x95a4f1e0;  // Kick1 register + data (unlock)

          ….  (access to the CFGSYS area)

            ….

          SYSTEM->KICKR[0] = 0x00000000;  // Kick0 register + data (lock)

          SYSTEM->KICKR[1] = 0x00000000;  // Kick1 register + data (lock)

But DSPLINK expects the KICK registers to be unlocked at all times in order for cores to notify one another (it unlocks them itself during initialization). So even if you unlock the kick registers in a GEL file, if the PSP code does the above the registers would get locked again at run-time. Could you search through the UPP driver code to see if it is doing something similar to this? Maybe try commenting out the code that touches the kick registers to see if it helps?

Best regards,

Vincent

Hi Vincent,

I looked though the code and don't see the KICK registers being used at all for the OMAPL138 code. The Pinmuxs are being set in configureUpp() a function from the psp driver, and I double checked that source file and saw nothing with the KICK.

-Matt

I'm currently building the dsplink project(memorymapgpp with readwrite.out from dsplink sample programs) with ringio and component disabled, this allows the handshake in proc_start() to be successful. But even if I get past the proc_start() call I am unable to locate the msgq with MSGQ_locate() on the arm side. If I have the lines:

bios.UDEV.create("Upp0");
bios.UDEV.instance("Upp0").fxnTableType = "IOM_Fxns"; 

(In my TCF file these lines and a few others were added for the PSP driver)

The program will loop forever trying to find the MSGQ, MSGQ_Locate returns with DSP_ENOTREADY

If I comment out the line:

bios.UDEV.instance("Upp0").fxnTableType = "IOM_Fxns"; 

The program is able to run successfully. proc_start+ msgq_locate work fine, no error messages.

Any idea what this means?

Thanks,

Matt

Hi Matt,

I think IOM drivers typically insert some code that automatically runs during initialization before and during the context of main(). The action of defining the fxnTableType brought in that code, and it sounds like the code has caused DSPLINK to fail. Could you try to isolate which part of the driver initialization code is causing this (i.e. comment out driver code until you get to a state where the communication works)?

FWIW, DSP_ENOTREADY means that the DSP hasn't yet set a bit in shared memory to tell the GPP side that it is ready to receive notifications. Perhaps the DSP is stuck and never got around to open its MSGQ transport, at which point the transport usually registers itself for notifications.

Best regards,

Vincent

Well it  ended up being a silly mistake. I  remade the TCF file using the sample program's TCF as a starting point. There were lines I was missing from the sample TCF that must of been the problem., in particular I think it was one of these lines:

bios.enableRealTimeAnalysis(prog);
bios.enableMemoryHeaps(prog);
bios.enableRtdx(prog);
bios.enableTskManager(prog);
bios.setMemCodeSections(prog, prog.get("DDR"));

Problem seems to be solveld. I guess this was more of a bios question? None the less, thank you for your help Vincent.

-Matt

-Matt