【经验共享】vxWorks5 PowerPC架构的cache刷新问题

文件cacheAlib.s 中的 cachePpcDisable函数，约第 779 行附近。
cacheAlib.s负责vxWorks的cache操作，在cachePpcDisable函数执行时需要在关闭cache前把内容flush到内存。这里对cache size的定义是有问题的：
# if (CPU == PPC604)
# define MPC_IMP_DCACHE_SIZE 32768
# else /* CPU == PPC604 */
# define MPC_IMP_DCACHE_SIZE 16384
# endif /* CPU == PPC604 */

604架构统一定义成了32K，603架构统一定义成了16K，而实际上E300内核即MPC83XX也使用了603架构编译，但它的cache是 32K，所以在83XX使用cachePpcDisable的时候有一半的entry没有刷到内存。使用时需要注意。如果用到了83XX请自行修改一下这个文件编译到系统中。
作为对603内核笼统的处理，把cache的entry定义成512有着历史的原因。在vxWorks5.5.1发布的时候，E300的内核还没出来，windriver为了简单处理，默认凡是603的内核都具有16K或者更小的cache size。最近几年，freescale把内核的版本划的更细，G2、G4、E300 、E500等，每种内核有不同的cache size，这种情况windriver当年肯定是预料不到的。
在vxWorks5.4版本，把603和604归一处理，entry数都定义成2048，这样做没有错，但是对于82XX只有128*4的entry数量，相当于3/4的cache刷新时间是“浪费”的。对于604，通常只有128*8个entry，即使最多的74XX等，也只有1536个entry，所以个人感觉vxWorks5.5.1将其按照架构划分，更“精确”的处理了这个问题，节省cache flush时间。
但是对于当前遇到的E300内核32K的cache，又使用了603架构的问题，由于vxWorks5.5.1没有正式的发布过支持E300内核，83XX的bsp大多数都是用户从vxWorks6上自己移植的。都使用了603的架构标识，基于现状没有办法做更详细的区分。用户只能针对遇到的 ppc603 cpu设置不同的cache size，自己修改一下cacheAlib.s编译在bsp中，这种修改做起来应该不难。