Hi,
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...
Questions:
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?
Thanks,
Joel
<<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).
-Joel