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.
Part Number: TMS320C6678
We've been using the TMS320C6678 Reset Controller to trigger Soft Reset of a device in legacy EP mode behind a PEX8748 (can provide a more detailed block diagram if useful). This procedure works smoothly for us in Linux 3.12 (SLES 12 SP1) but fails us in Linux 4.4 (SLES 12 SP3).
We've been configuring "master transaction mode" via PRIORITY[MST_PRIV] before trying to write any register in the PLL Controller. We are able to read and write RSTCTRL in Linux 3.12 in "master mode" but read all 1's in Linux 4.4.
Anyone else having mode switch problems in Linux 4.x? It is certainly necessary to be in "supervisory mode" in order to access the PLL Controller but our driver might be missing an event of some kind triggered by the mode switch.
We can provide lots more context including driver source code. Wanted to start with the high-level question in case it rings a bell.
Please make sure you read the forum guidelines first.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Yordan Kovachev:
We in fact have eight 6678 chips clustered on a full length PCIe capture card. The card is installed in a SuperMicro server. The server is running Linux (SUSE Linux Enterprise to be exact).
Each 6678 device on the card enumerates as a distinct PCIe endpoint behind a (transparent) PEX8748 switch. The server software is able to control each 6678 in supervisory mode when running any Linux prior to 4.1.
In reply to Chad Colgur:
In reply to lding:
Thanks for your questions. I will repeat and answer them below.
Q: Did enumeration work?
A: Yes, all 6678 PCI configuration and capability registers are visible through generally available utilities (e.g. lspci) as well as custom application code.
Q: Are you able to access 6678 application registers?
A: Yes, we have read/write access to all PRIORITY as well as translation registers via custom application code. We have not been using generally available utilities for reading and writing (e.g. setpci) nor does our application code depend directly on pcilib. We could experiment with both though as both are at our disposal.
Q: Are you able to read/write other DSP memory?
A: Yes, we have read/write access to all of DDR, MSMC and L2 until we switch to privileged mode via set of PRIORITY[MST_PRIV] at which point all reads from those same offsets return all 1's. We haven't done this yet but suspect that if we clear PRIORITY[MST_PRIV] then we will once again have read/write access to those offsets.
Q: The only issue is to read/write PLL registers like RSTCTRL?
A: Not exactly. We can read RSTCTRL without being in privileged mode but writes have no effect. According to section 184.108.40.206 of the latest data sheet (rev E), for example, we must write 0x5A69 to RSTCTRL[KEY] before we can set RSTCTRL[SWRST] to trigger "software reset". We confirm successful write of RSTCTRL[KEY] by reading 0x000C. We only receive confirmation when in privileged mode (and then only in Linux 3.x).
Q: Have you made any changes to the DSP side code?
A: No changes to the DSP code. I have no doubt this is a Linux OS issue. I was hoping someone here would be able to explain the side-effects of setting PRIORITY[MST_PRIV]. Does the host need to trigger a configuration cycle of some kind having set this bit? Does this bit generate some kind of interrupt that might have been masked in Linux 3.x but unmasked (and mishandled) in Linux 4.x? We are not looking for speculation about what might be happening in the Linux OS. We are trying to interpret the impact of setting this bit from a PCIe standard perspective i.e. What is physically happening on the bus when this bit is set?
We definitely have JTAG access to the card. We also have a PCIe analyzer at our disposal. We can hook up one or both and trigger on the write to PRIORITY but would ideally have some context before launching that investigation.
Our host software defines three regions for BAR2 using guidance from "PCIe Use Cases for Keystone devices" (docid sprabk8) section 3.2.3. This isn't new for us in Linux 4.x but can be reverted if it seems problematic.
Notice also that we use the chip in 64b addressing mode.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.