关于VxWorks内存初始化失败的问题！
由于系统内存的变化，需要在BSP中修改内存分配的内容，使用的CPU是MPC8270，内存控制器对应CS0—CS11这12个Bank，现在需要把其中的CS7对应的空间重16M改动到512M（硬件决定的）。接下来是我在BSP中的修改情况：
（1）修改romInit.s文件中内存控制器CS7对应的OR7与BR7的值，分别设置该bank的基地（0x6000,0000）以及地址掩码（0xE000,0000），地址掩码决定了空间大小。
（2）修改syslib.c文件中的虚拟内存表sysPhysMemDesc中的内容,CS7段对应的内容为：
{
(void *)0x60000000,
(void *)0x60000000,
0x20000000,
VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE |
VM_STATE_MASK_MEM_COHERENCY,
VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT |
VM_STATE_MEM_COHERENCY_NOT
}
现在问题来了，修改完后，我们使用该BSP创建Tarnado工程，编译生成Vxworks映像文件后，系统不能正常启动：
Loading...
file down OK!
CRC...CRC OK!
Extracting file(2)...Success!Starting at 0x200000...
解压到此后系统崩溃，后经跟踪调试检测，发现在系统启动的时候在priConfig.c文件中的usrMmuInit()函数处死掉，当把该函数删去（实地址模式），重新编译后系统能启动起来,并且此时对cs7 对应512M的空间能进行操作。
另外，经过这几天的分析发现，在sysPhysMemDesc中每个域的基地址、长度都是page（4K）的整数倍，即页是对齐的,而且 sysPhysMemDesc中的每个域也没有重叠的情况发生。当我把cs7对应的域改成小于等于160M后系统就能正常启动，而一旦超出这个值，系统就启动不起来导致复位....
后来对sysPhysMemDesc中的initialStateMask与initialState也进行了适当的调整，但问题依旧....
很早就怀疑是地址重叠造成的问题，并且发现mpc8270 的IMMR定义的基地址是0x0f00,0000,和SDRAM空间的地址是重叠的，SDRAM地址范围是 0x0000,0000--0x1fff,ffff但是在rominit.s中将IMMR 的基地址改成0xff00,0000后，问题依旧....除此之外，与其它设备的内存地址并没有冲突，而且设备与设备之间的内存地址也没冲突....
[解决办法]
帮顶
感觉是MMU的地方没有处理好吧？
[解决办法]
(VIRT_ADDR) M8260_CS8_MEM_ADDR,
(PHYS_ADDR) M8260_CS8_MEM_ADDR,
M8260_CS8_MEM_SIZE,
MMU_ATTR_VALID_MSK | MMU_ATTR_PROT_MSK | MMU_ATTR_CACHE_MSK,
MMU_ATTR_VALID | MMU_ATTR_SUP_RWX | MMU_ATTR_CACHE_OFF |
MMU_ATTR_CACHE_GUARDED
问题比较怪，用上面的 试试？
[解决办法]
是否可以在RomInit.s里少给FLASH分配大概5M左右的空间 以供MMU使用试试
[解决办法]
可能没说明白
我以前碰到过这样的情况给FLASH少5M左右的时候 就能够避免出现exception
时间久了忘记当时具体情况
模糊中记得当时有个同事提到MMU。。。 我只是顺便提一句 供楼主参考
是否可以看看RomInit.S里是否有正确初始化MMU的代码
[解决办法]
降频试试
！
[解决办法]
http://topic.csdn.net/u/20090321/23/0a637fa9-58ae-4605-8ad8-1fab2fa7c596.html
我也不知道是否管用
我的系统也出现了类似你的问题
我将主频和SDRAM频率减小就好了
但是我的是CE系统
你可以试试这个是最简单的实验方法了！
[解决办法]
vxWorks没有BOOT吗？
应该在BOOT初始化CPU时就设置了主频和SDRAM的频率，应该是在汇编部分
只需要将这个设置减小就行了，别换晶振啊！
[解决办法]
