由于系统内存的变化,需要在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后,问题依旧....除此之外,与其它设备的内存地址并没有冲突,而且设备与设备之间的内存地址也没冲突....