C6472 DEVSTAT_KEY

Are you trying to boot through SRIO. the Devstat register is latched only during the power on Reset.

Thanks,

Arun.

I am not booting through SRIO - I simply want to use it for interprocessor communication. My reading of the little documentation there is tells me that DEVSTAT is read-only.

My problm is that, having enabled the power/clock domains, all SRIO registers read as zero.

The message from EPIC about this was:

"To be able to enable SRIO on C6472 it is required to enter a valid key in DEVSTAT register DEVSTAT_KEY = 0x0E3C5A78.
 Afterwards you can initialize PSC and enable the clock for SRIO."

I need documentation for this incantation, not just a general comment about it. If this isn't the reason SRIO registers read as zero, what is?

I get this behaviour on C6472 boards from two different manufacturers.

Regards,

Peter

Peter,

you need to chagne the hardware as well. See the table 2-5 in datasheet, you need to pull the RIOEN pin high to enable SRIO.

regards,

yanmin

Peter,

Are you using your own board, or one of our EVMs?  If it is one of our EVMs, the included gel file will setup all the device level configuration and the CSL examples will initialize the SRIO peripheral.  You shouldn't need any other setup.  Even if you are using your own board, you can have a look at the gel file to see what needs to be configured.  Essentially, if you are just trying to read C6472 SRIO registers via the configuration bus, you need to have the clock domain enabled as pointed out.  When it comes to initializing the peripheral through register writes, a sequence is needed to make sure that the SerDes PLL is enabled first and then other registers are programmed before the last step of writing boot_complete is performed.  Again, this is all managed by the CSL srio_init functions.

I looked at the cslr_dev.h and cslUtils.c file, and it looks like we have some issues to clean up there.  I will look into this further with the developers asap.

Regards,

Travis

I do not use CSL. Also, I do not believe that you should need to plough through code to work
out how to drive a device--that's what proper documentation is for.

I have wasted a huge amount of effort on this problem and that has been for two reasons.

The minor reason is that TI support pointed me at a non-existent register on the C6472. There
is no DEVSTAT_KEY as far as I can determine. The bits it is supposed to control are statically
determined by the state of signals at reset.

The major reason is that your documentation is simply wrong. The texts describing the SRIO
and PSC do not bother to state explicitly which power and clock domains are relevant. At the
very best, that description might exist, but is hidden so deeply that I cannot find it. If you can't
find information it's essentially not there - a big problem with most computer-related documentation.
The other, of course, is that the documentation is clearly not written to help users; it's written
either so you can say there is documentation or to show off the knowledge of the writers.
The most obvious clue to that is the way that there is never a simple overview of how everything
fits together from which increasingly explicit descriptions can follow. Instead, before you are much
more than one page in, you are immersed in minuscule detail. The only place the SRIO clock
domain is mentioned is in a diagram in sprueg3b where SRIO is shown in clock domain 7.
In fact it is clock domain 6 - cue hours of wasted effort.

Peter,

I'm glad to hear that you have worked past this now.  We will clean up the DIOLib cslUtils.c file to remove the erroneous reference to DEVSTAT_KEY register.  Although this snippet of code did not affect DIOLib's functional operation, we understand the confusion it caused and apologize for the delay that resulted.

Regarding SPRUEG3B, figure 2 shows that the only components on separate power domains are Gem0-5 and the SMC.  All other components are in the Always On power domain.  The clock domains are labeled 1-14 in the same figure, SRIO is clock domain 7.  However, the cooresponding MDCTL registers are numbered 0-13, so everything is shifted by one, not just SRIO.  I can request this to be clarified in the next revision of the doc in table 6.

Finally, I realize that you are trying to write your code from scratch, but I highly recommend that you start with either the DIOLib or simply the loopback example in the CSL itself, which has an enableSRIO function (note this is not in CSL, it is part of example of using the CSL).  As I mentioned before, sequencing on the register programming, as well as, bit settings themselves are very important and some of these vary device-to-device.  If you start with the latest CSL examples, which are verified, I believe it will save you time and frustration in the future.

Regards,

Travis

The best way to prevent problems like these is to document the hardware adequately. If there are ordering constraints (especially if these differ from implementation to implementation) they should be clearly documented What is so difficult about that? It suggests that hardware is getting too complex even to be documented properly. Requiring someone to trace through an example program, while instructive, is no substitute for correct and well-written documentation. Examples rarely do exactly what is needed in a particular program, so how can you know that your changes are sensible unless the documentation is clear?

A perfect example of totally inadequate documentation is the SRIO problem I am currently (still) trying to solve on the C6472. When attempting to send data, the cc field in the TX Buffer Descriptor always returns with the value 2_100. The ONLY documentation I have been able to find on this is in SPRUE13h page 54 where it says "DMA data transfer error" -- that is all it bothers to say about the eror. Requests to epic return silence. I found one reference to this message on these forums and it suggests that memory addresses are wrong. I have checked all of the memory addresses involved and they are all sensible. The code is based on a working example from the C6455, so I know there is nothing fundamentally wrong, but without some clues as to what this error means, I am completely stuck.

Is there any real documentation about this or does anyone know what the error actually means?

DMA data transfer error means that SRIO peripheral could not access the buffer memory location you are programming into the TX descriptor.  This error code was added to flag/indicate improper programming of the descriptor.  Generally this means the buffer address is pointing to a reserved memory location, but you must also use the global addresses, not local addresses.  Where are your data buffers, DDR, or SL2 or L2?