Hi, I am trying to have a working dsplink on a DM3730 based board. DVSDK is 4.03 Kernel is the kernel provided by the DVSDK What happens is the __second__ test I run, if different from the first, fails with a MMU fault. The faulting adress vary, and is never a "valid" address, where valid means somewhere in the DSPLINK memory map. I checked the DSPLink Troubleshooting page [1], and everything seems ok to me. I did not change the memory map, but checked the tci file mentioned in [2], and my mem command line arg is mem==55M which should be ok. What is strange is the first app run fine. For example in the following test runs (dsp is powered off between each run) : -- test # 1 -- ./loopgpp ./loop.out 100 1000 ./messagegpp ./message.out 2000 <-- faulting app -- test #2 -- ./messagegpp ./message.out 2000 ./loopgpp ./loop.out 100 1000 <-- faulting app -- test #3 -- ./messagegpp ./message.out 2000 ./messagegpp ./message.out 4000 ./loopgpp ./loop.out 100 1000 <-- faulting app DSP MMU Error Fault! MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0xbebebeb8]. I think what leads to the MMU fault is the DSP is executing garbage with something like this going on : - DSP does not stop running, and when new code is loaded, at some point old and new code is mixed, leading to fault - Code loading works Ok, but there is a cache or cache flush problem, leading to old and new code being mixed. Thank you for reading this, any hint on what to test next is welcome. Jean-Philippe François [1] http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues [2] http://processors.wiki.ti.com/index.php/Changing_DSPLink_Memory_Map -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
