总结：K66 带有SDRAM Controller，但是速度使用起来实在慢的揪心，本文从实用角度找到如何使用cache的方案提高SDRAM的访问速度；
最近公司将原来运行在PowerPC上的项目进行了简化，准备跑在了freescale Kinetis K66上(ヾ(≧O≦)〃嗷~不对是NXP Kinetis K66。靠，好像还不对，是Qualcomm Kinetis K66，哈哈哈哈，正好我的一个朋友进了飞思卡尔，不久就被NXP收购了，结果NXP没过多久又要被高通收购了。厉害了，word哥）；
最初采用方案的时候发现K66自身带了SDRAM控制器，可以挂载比较大的SDRAM芯片提高可使用内存；后来逐步使用中发现，Kinetis的自带SDRAM控制器是一个比较简化的版本，其框图如下下所示：
K66P144M180SF5RMV2.pdf 881页
可以看出内部不具备单独的锁相环，查阅手册最终发现其时钟来源如下图所示：
K66P144M180SF5RMV2.pdf 880页
既然发现来源是FlexBus clock，为了提速就必须要了解FlexBus clock的速度配置了，结果发现了如下图：
K66P144M180SF5RMV2.pdf 122页
这不是坑爹嘛，好好的SDRAM动不动100-200M的速度活生生的限制到了60MHZ（最高）；
这也没办法，将就着调试出来用用试试看吧。于是乎写了一个程序，将链接地址修改到SDRAM中（代码段和数据段均在），搞了搞没办法用简单的办法运行起来，于是写了一个bootloader程序进行初始化搬运以及启动工作；
以下贴出测试代码：
个人代码
PS：以上代码有跑MQX系统；
测试结果是大伤脑筋，程序运行的特别慢，本来一个测试在FLASH的程序可以7.5s跑完的，结果到了SDRAM中需要73.9s才能够跑完；这样下去可不行，必须想办法提高速度：
于是想到了使用cache来提高命中率提高运行速度；
翻阅K66 数据手册，得到如下结构图：
K66P144M180SF5RMV2.pdf 681页
发现只有连接在Process Code（PC）bus 总线上的 Code cache controller；对比一下K70的数据手册发现其具有另外一个cache；
K70数据手册
这就又比较坑爹了。上面SDRAM控制器不全，这里也不全，还缩减了System cache controller；这也没办法，选都选了，硬着头皮用吧；
翻阅数据手册，发现了如下的映射表：
K66P144M180SF5RMV2.pdf 679页
再由于cache实际上有对应的管理区的，如下图所示：
K66P144M180SF5RMV2.pdf 680页
卧槽，瞬间发现处处埋地雷啊，必须一个一个的挖起来：少了一个很重要的cache后发现，什么0x6000_0000地址后的cache都是扯淡，都是没有物理模块处理，完全就是留空的；给我们使用的仅仅是前面一些：不过还是让我看到了希望，这里0x0800_0000这个区段是映射到SDRAM的0x8800_0000区段的，如下图所示：
K66P144M180SF5RMV2.pdf 102页
应该有办法让其为SDRAM加速。好，说干就干，重新处理下SDRAM的初始化，让其CM0 地址掩码变为：0x83FC_0000，BA地址改为0x8800_0000；
通过IAR的memory工具发现确实是可以访问到映射的区域了：
IAR相关界面
由于结合到我们项目的实际情况，我们的程序实际上是跑在FLASH上，需要使用SDRAM存取数据速度提高；所以此处直接上程序跑到了FLASH上进行测试相关结果：
先打开LMEM的寄存器开关，使能cache，由于芯片region R1 复位时候值就是 直写模式，所以此处不用修改：
LMEM_PCCCR |= LMEM_PCCCR_ENCACHE(1);
然后直接进行测试，先测试程序在0x8800_0000段（没有cache加速的）：
测试代码依然不变：
无cache 测试代码
测试结果如下：
直接访问内部SRAM需要时间：7.5s左右（测试时间）
写SDRAM需要时间：39.4s
读SDRAM需要时间：43.8s
以上是测试没有cache 加速的区域；
下面修改一下代码：直接访问0x0800_0000区域测试cache的加速效果：
使用了cache加速
测试结果比较令人满意：
写入内部SRAM的时间：7.5s左右
写入SDRAM的时间：37.5s
读取SDRAM的时间：17.6s
结论，提速特别明显，还进行了其他的测试，发现process code bus总线上挂载的cache不仅能够加速代码，还能够加速数据的读写；
测试使用比较简单的统计办法：在MQX系统中开了一个任务，每隔100ms发送一个 “.” 然后进行统计：多次统计后得到以上数据；
