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.
I need to port an SRIO driver from a C6455 to the C6678 and, as with the equivalent port of an Ethernet driver, I have been stumped by the complexity of the new system.
Does anyone have a simple (non-BIOS) example of two C6678 DSPs communicating over SRIO that uses the absolute minimum of the extra devices that have been put in the way? I do not need or want to do anything complicated, simply move data from A to B.
Even though the Ethernet driver is working perfectly and has been reduced to something of a manageable size, much of it is still a black box, with values and settings that make no obvious sense, but seem to work. Because of this, it does not serve as much of an example for SRIO.
My greatest fear is that things like the Queue Manager are going to add very unpleasant linkage between the otherwise completely-independent Ethernet and SRIO drivers.
If you use memory mapped transactions (directIO), then you don't need QMSS or CPPI involvment. Are you using messaging or directIO? The examples we have are found in the MCSDK... http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html Once installed look at:
C:\ti\pdk_C6678_1_1_2_6\packages\ti\drv\srio\example
Examples use our SRIO LLD, but don't require BIOS.
Regards,
Travis
You say I don't need QMSS (which would be great) but the example you reference clearly does use QMSS:
/* Initialize Queue Manager Sub System */
result = Qmss_init (&qmssInitConfig, &qmssGblCfgParams);
The fundamental problem with QMSS is that is is global to all cores, so if one core is using Ethernet , another is using SRIO, and both are required to use QMSS, you hit very unpleasant and complex issues that would not arise given direct acess to Ethernet and SRIO (as in previous C6000 hardware). The two cores, which are logically completely independent are now forced to have unwanted linkage. Far from simplifying these devices, QMSS and its frriends have made it orders of magnitude more complicated.
To clarify, I am free to use any mechanism to get SRIO to move data between A and B and signal appropriate interrupts; I just need the simplest that involves the fewest entities.
I also note that, once again, the examples all seem to involve loopback. The Ethernet example did so, and failed to work when loopback was disabled to try to make a variant example that fits real-world requirements. I suspect hte SRIO example you have identical problems.
Peter,
C:\ti\pdk_C6678_1_1_2_6\packages\ti\drv\srio\example\SRIOLoopbackDioIsr
I'm not certain why the example here requires QMSS/CPPI. I can guarantee the directIO traffic types using the LSU don't use QMSS or CPPI. I will ask one of my team to take a look and remove those dependencies.
Regarding loopback, this is highlighted in other posts on e2e, but it is a simple a change as follows:
/* Configure SRIO to operate in loopback mode. */
// CSL_SRIO_SetLoopbackMode(hSrio,0);
// CSL_SRIO_SetLoopbackMode(hSrio,1);
// CSL_SRIO_SetLoopbackMode(hSrio,2);
// CSL_SRIO_SetLoopbackMode(hSrio,3);
/* Configure SRIO to operate in normal mode. */
CSL_SRIO_SetNormalMode(hSrio,0);
CSL_SRIO_SetNormalMode(hSrio,1);
CSL_SRIO_SetNormalMode(hSrio,2);
CSL_SRIO_SetNormalMode(hSrio,3);
There is also another example in the MCSDK that can run in loopback or board to board by specifying a variable, but I didn't point you there because it runs directIO as well as messaging.... C:\ti\pdk_C6678_1_1_2_6\packages\ti\drv\exampleProjects\SRIO_TputBenchmarkingTestProject
Regards,
Travis
Peter,
I attached an SRIO DIO loopback example for C6678 here. See if this simplifies things for you.
-Ivan
4/29/2013 EDIT: Added an extra check for LSU busy bit before checking for the full bit: 6406.srio_dio_C6678.zip
Hi Ivan,
I am looking at the code you sent and have noticed something odd.
The code is setting various registers, such as RIO_ASBLY_ID, RIO_ASBLY_INFO, and PE_FEAT, but these are explicitly marked in the documentation (SPRUGW1B) as read only.
Which is wrong: the code or the documentation?
Peter
Peter,
These registers are read only in normal operation, but can be written before the boot_complete is set in the RIO_Per_Set_Cntl register is set. Documentation should be updated to reflect.
Regards,
Travis
The documentation is really a mess in this area.
Of the registers explicitly written to in the example:
ASBLY_ID and ASBLY_INFO are explicitly marked as "Writes have no effect to this register".
PE_FEAT is just marked read-only
DEV_ID is marked "Writes have no effect to this register after boot_complete is set"