[VxWorks]
关于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后，问题依旧....除此之外，与其它设备的内存地址并没有冲突，而且设备与设备之间的内存地址也没冲突....
to Heaven_Redsky:是呀 绝对是内存初始化失败，但是找不到原因呀，最近在看rominit.s中CPU的初始化是否有问题，但一直没找到问题处在那里....继续关注中...
(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使用试试
使用你那个编译不过哟，
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使用试试”
to Heaven_Redsky: 不太清楚你的意思...
MMU 管理是OS提供的呀，跟FLASH有啥关系呢？
可能没说明白
我以前碰到过这样的情况给FLASH少5M左右的时候 就能够避免出现exception
时间久了忘记当时具体情况
模糊中记得当时有个同事提到MMU。。。 我只是顺便提一句 供楼主参考
是否可以看看RomInit.S里是否有正确初始化MMU的代码
Heaven_Redsky：
我检查了rominit.s中关于SDRAM初始化的部分内容,对SDRAM的初始化依靠mpc8270的内存控制器来设定的，具体设置如下：
CS0 ：
OR0_VALUE 0xFFF00836
BR0_VALUE 0xFFF80801
CS1
OR1_VALUE 0xFF0008F2
BR1_VALUE 0x40001801
CS2
OR2_VALUE 0xE0002500
BR2_VALUE 0x00000041
CS3
OR3_VALUE 0xFF000EF2
BR3_VALUE 0x50001001
CS4
OR4_VALUE 0xFF000EF2
BR4_VALUE 0x52200801
CS5
OR5_VALUE 0xFF0008F2
BR5_VALUE 0x54000801
CS7
OR7_VALUE 0xE00008F6
BR7_VALUE 0x60001001
这并有设置错呀。另外今天按你说的我把Flash减少5M后问题依旧...
还问下：你们当初也是某一块的内存空间超过一定的大小就导致系统不能正常启动的么？
启动中的异常有手段进行检测么？
再补充下内存资源的使用情况是：
BOOTROM --CS0
FLASH --CS1
SDRAM --CS2
SRAM --CS3
NANDFLASH --CS4
CPLD --CS5
DSP --CS7
多谢 Heaven_Redsky了...
wangxin_801115: 能简单解释下原因么?
http://topic.eeworld.net/u/20090321/23/0a637fa9-58ae-4605-8ad8-1fab2fa7c596.html
我也不知道是否管用
我的系统也出现了类似你的问题
我将主频和SDRAM频率减小就好了
但是我的是CE系统
你可以试试这个是最简单的实验方法了！
wangxin_801115: 大哥 ，降频不行，我将晶振从100M换成50M，同时修改了代码，仍然不行。100MHz晶振频率作为SDRAM与CPU的时钟源。
我这样认为的降频的，不知道对不对： 系统在CS7内存超过160M以后，usrMmuInit()需要更多时间去初始化内存，在看门狗定计数值一定的情况下，降频可以造成看门狗清狗的时间延长了，以便内存初始化有更多时间，所以我在prjConfig.c中将删除看门狗，之后让CS7内存超过160M系统仍不能正常启动。不知道wangxin_801115有何看法？
vxWorks没有BOOT吗？
应该在BOOT初始化CPU时就设置了主频和SDRAM的频率，应该是在汇编部分
只需要将这个设置减小就行了，别换晶振啊！
引用: 引用 15 楼 wangxin_801115 的回复:
vxWorks没有BOOT吗？
应该在BOOT初始化CPU时就设置了主频和SDRAM的频率，应该是在汇编部分
只需要将这个设置减小就行了，别换晶振啊！
应该在RomInit.s里吧
LZ是不是再仔细查一下mmu相关的宏定义 看看有没有对其映射关系相关之类的内容？
刚才搜了一下 楼主看看能不能参考一下
http://blog.eeworld.net/makethyme/archive/2006/03/18/628128.aspx
wangxin_801115：我们系统中的时钟源有4大类，4个独立的晶振源：
1）CPU，SDRAM，CPLD工作的时钟源由一个100Mhz的晶振源提供，通过一个时钟驱动芯片74FCT3807分出6路100Mhz 的时钟,一路给CPU，4路给SDRAM，一路给CPLD。
2）DSP的工作时钟由一个16M的晶振源产生，CPLD使用该源产生DSP的工作时钟、同步时钟等。
3）一个晶振源给RTC时钟。
4）还有一个晶振源给网络数据传输使用的时钟。
所以，根据你们所说的降频，实际上给CPU、SDRAM降频，所以我换掉了晶振，至于你们所说的在rominit.s中降低系统的频率，我看了汇编部分的代码，只是通过系统时控制寄存器【System Clock Control Register (SCCR)】给BRG_CLK的频率进行设置,而BRG_CLK(波特率产生器时钟源)是与设置CPM部分（如FCC,SCC等）各个工作单元的频率有关，而与我们需要的SDRAM频率无关呀...
京公网安备 11010802033920号
