TI中文支持网ARM端跑linux，DSP端还是跑sysbios，使用TI提供的双核例子，在TI提供的DSP例子里面的cfg文件中，将双核通讯的SR_0和SR_1这两块双核共享区定义在片外DDR里面，而且把这块区域的DSP L2cache功能关闭了，一开始也没注意，关闭就关闭了吧，就是速度慢一点而已，双核通讯正常就没事儿，慢慢的加上我自己的应用代码，在后期调试的时候发现DSP中IQ数据的解析和滤波处理很慢了，对照之前调试成功的代码（ARM也是跑sysbios）发现，以前的双核通讯这块内存区域也是定义在DDR的，只是DSP端将这块区域的L2 cache功能开启来了。
将DSP端的双核通讯这部分区域的L2 cache功能也开启来，用linux进行引导，DSP端IQ数据的解析和滤波处理速度上来了，但是双核通讯失败了（双核通讯使用TI给的例子做的），一直都通不起来，不知道大神们有没有遇到过这样的情况，只是将DDR中的双核通讯定义的共享区域的DSP MAR寄存器中对应的16M空间L2 cache空间开起来而已。
Tony Tang：
在通讯前的代码加上Cache操作，BIOS有Cache操作的API，Cachewriteback, Cacheinvalid等。
bingliang chen：
回复 Tony Tang:
tony哥，按照你的说法我是否可以理解为arm端的cache部分操作已经被Linux接管了，而dsp端使用sys/bios，即使在cfg文件里面把L2 cache功能打开之后还是要在使用双核接口（初始化、通讯）的时候每次都要调用L2 cache的回写和有效，岂不是很麻烦？
我在你的另一个关于L2 cache的帖子里面说过对cache的配置只要在初始化的时候配置就好了，在程序运行的时候可以不需要管的，如果在应用代码运行的时候都要每次配置cache的话，这个cache还有什么意义呢？不知道你是否明白我的疑问？
这是不是sys/bios的一个Bug还是Omapl138的一个bug？
Tony Tang：
回复 bingliang chen:
这不叫bug吧，CACHE用了就要做一致性维护的。只是ARM侧系统LINUX做了，而DSP侧需要用户程干预。
你也可以看一下这个双核通讯的源代码，看里面是否加了CACHE的操作，以求放心:)
这里不是配置CACHE，是做CACHE一致性维护。配置是只要初始化时一次就可以了。
bingliang chen：
回复 Tony Tang:
谢谢tony哥的耐心回答，但是你还是没有回答我的问题，因为在ARM和DSP都用sysbios系统的时候，我也配置到L2 CACHE，也没有对cache进行一致性维护，应用代码跑正常了，然后只是把ARM操作系统改成了Linux而已，DSP端没有任何变化，莫非是跟Linux通讯的双核通讯代码里面没有cache维护，而两边都是跑sysbios的双核驱动代码里面有L2 cache维护？
但是这样也说不通，L2 cache是通过sysbios里面的cfg文件进行配置的，难道CCS能识别cfg已经配置了L2 cache，然后在双核接口里面加入了L2 cache维护功能吗？如果这样子的话，L2 cache也不需要自己维护的。
其实我最想知道的是为什么两边都用sysbios系统，双核空间配置同个片外DDR空间，打开L2 cache可以正常工作，双核空间没有变化，而ARM端换成了Linux而已，打开L2 cache功能双核握手就不行了，而关闭L2 cache功能，双核就可以正确运行了呢？
luo qi：
回复 bingliang chen:
cache是一定要维护的，没有遇到问题不代表不存在问题
cache和内存是2个东西，只是耦合性很大
每一个cpu都认为自己是内存的唯一使用者，每一个cpu会在合适的时间对cache进行inv和writeback
举个简单的例子
1.CPU A向内存1000地址写了128个字节数据，CPU A认为数据已经写到内存里了，但其实数据很可能只是写到了CPU A的cache里（要看该段内存是否已经映射到cache里，这是个自动的过程，cache根据访问频繁度来决定这个事）
2.CPU A这时如果直接通知CPU B来取数据，那么这个时候CPU B很可能取到的是还没更新过的旧数据，新的数据还在CPU A的cache里，因此CPU A要维护cache一致性，将cache里的数据强制写入内存，然后再通知B即可。
3.CPU B 返回数据时候也是一样，处理完成后，需要将cache里的数据强制写入内存，然后再通知A即可。
这个cache的特性不是bug
如果能够关闭cache功能的话，是可以不维护cache的。
bingliang chen：
回复 luo qi:
那也就是说单核的话可以不用手动维护，双核的可以就需要手动维护了。
