TI E2E Community
Digital Signal Processors (DSP)
C6000 Multicore DSP
Keystone Multicore Forum (C66, 66A, AM5)
Reset c6678 when used as PCIe EP
In our board design, the c6678 DSP acts as a 'number-crunching' pcie peripheral controlled by a TI DM8148 SOC RC running linux. PCIe memory mapping and pcie-based booting are working fine for me. Occasionally, however I need to 'restart/reload' the DSP. Basically I either need to run different firmware, reload the PCIe driver, or perhaps the device has gotten itself in to a bad state, and needs to be reset. I'm trying to figure out the best way of doing this. I have written device drivers for other hw, and i have always had a register that I could write to tell the device to reset itself. I'm looking for that, but running in to some problems.
Initially I tried doing a soft-reset by writing the necessary registers in the PLL controller via PCIe. Like others have found out, this doesn't work until you set the MST_PRIV bit in the PRIORITY register. When I do that, I can successfully initiate a soft-reset. The problem is that even if I wait for a long time, something seems to have gone wrong on the PCIe bus. The DSP reruns the I2C IBL, but it gets stuck at the PCIeWorkaround bit, and never starts polling the MAGIC address again. Also, on the host (DM8148), something has gone wrong, as running lspci -vv reveals:
00:00.0 Class 0604: Device 104c:8888 (rev ff) (prog-if ff) !!! Unknown header type 7froot@dm816x-evm:/# ./lspci -vv00:00.0 Class 0604: Device 104c:8888 (rev ff) (prog-if ff) !!! Unknown header type 7f01:00.0 Class 0480: Device 104c:b005 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: mio_vpu_pcie_driver
Before the 'reset', lspci -vv shows me all the normal PCI header information, BAR sizes, etc... If i try to load my driver and do a read/write to the device, I get a external abort...
1) Does anyone know what is going wrong here, and how I can make this work?
2) Is there a better way of doing the 'reset' of the device from the RC?
<<What is the difference between all of those memory regions? I'm pretty sure the app registers is for changing board registers (and thus configuration). Local L2...that's memory that is specific to a core? MSMC....don't know what that is, but comments seem to indicate "shared L2". So, L2 memory all cores can access? and DDR....also seems shared. So what's the difference then between MSMC and DDR?
Yes, the application registers (regVirt), are the DSP's PCIE peripheral application registers. They allow 'remote' configuration of the DSP's PCIE subsystem. Local L2 is memory specific to each core (can be configured to act as cache or internal ram). MSMC is just a section of shared memory, which is faster than DDR to access.
2) So, in the code executing on the core itself (say, core 4), then for me to access DDR, I'd just read/write to address 0x80000000? So in theory, if I use core 4 to write 0xFAFAFAFA to 0x80000000, and then use the Linux driver to read from ddrVirt + 0, I should get that value? Seems like something worth trying... Thanks for the help. I knew I was close, but had mental hurdles to get over.
Yes, that will work. Make sure that your DSP program is not using that section of DDR for anything else (check where the linker is placing your program sections).
Did you figure out a good way to get the RC to re-init? I'm looking at exactly the same issue.
It's been a while since I worked on it... I think that I never got the full C6678 reset working, but what I ended up doing is using "core local resets" for each DSP core. Does that make sense? If not, reply back & I can dig up the code & take a look.
I think that makes sense: leave the PCIe link up and just reset the cores.
I'm booting my 6657 endpoint (without IBL) over PCIe from a dm8148 running Linux (RC) -- linux pushes code up to L2 on the 6657 and generates a legacy interrupt kick things off. Ultimately, I want to communicate between 8148 and 6657 via MSI interrupts, but I'm not sure how to initialize the endpoint registers (BAR0 has a length of 0x1000, and I get faults when I try to access the EP configuration registers such as MSI_CAP from the 8148). This is the reason that I'm using the legacy interrupt in the bootloader. Here's what the RC driver spits out at power up:
pci 0000:01:00.0: BAR 0: assigned [mem 0x2a000000-0x2a000fff]pci 0000:01:00.0: BAR 0: set to [mem 0x2a000000-0x2a000fff] (PCI address [0x2a000000-0x2a000fff])
The workaround I was attempting was to bootload code on the 6657 that sets the BAR0_MASK larger, then do link retraining (which I hoped would cause Linux to re-init things). Instead, after re-enabling link training on the EP side PCIe accesses from the RC lead to system faults.
Do you know how to solve my real problem of not being able to access the configuration registers beyond offset 0xFFF so that I can get the RC to generate MSI interrupts on the EP?
Again, I'm just going off my memory from a year ago, so be skeptical of what I say. Here are a few things that come to mind:
1) As I remember, PCI BARs are configurable in size programatically (ie via IBL), but also via boot-config resistors. You mention that you are not using IBL - but RBL should still initialize the PCI peripheral based on your boot-config resistor settings.
2) As I remember, I use BAR0 to reconfigure the inbound address translation for BAR1, and then do my memory access via BAR1. Because you can arbitrarily (and on-the-fly) remap the BAR1 inbound address translation, you can then hit up any C6678 address that you want.
3) Check out the DSP_BOOT_ADDR registers, starting at: DSP_BOOT_ADDR0 0x02620040 . The way I load/reload a core(s) is as follows:
a. place the core(s) in reset
b. load the program/memory segments
c. set DSP_BOOT_ADDR(s) for the core(s).
d. release core(s) from reset
This has been working well for me for over a year.
Again, this is from memory, let me know if you need more clarification or if I've mis-remembered something.
Hope it helps.
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.