8494|18

1

帖子

0

TA的资源

一粒金砂(初级)

楼主
 

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

最新回复

我也遇到了同样的问题  楼主能说说是如何解决的么  详情 回复 发表于 2010-3-5 11:02
点赞 关注
 

回复
举报

1

帖子

0

TA的资源

一粒金砂(初级)

沙发
 
帮顶
感觉是MMU的地方没有处理好吧?
 
 
 

回复

2

帖子

0

TA的资源

一粒金砂(初级)

板凳
 
to Heaven_Redsky:是呀 绝对是内存初始化失败,但是找不到原因呀,最近在看rominit.s中CPU的初始化是否有问题,但一直没找到问题处在那里....继续关注中...
 
 
 

回复

15

帖子

0

TA的资源

一粒金砂(高级)

4
 
  (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

问题比较怪,用上面的 试试?
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

5
 
是否可以在RomInit.s里少给FLASH分配大概5M左右的空间 以供MMU使用试试
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

6
 
使用你那个编译不过哟,
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  宏定义在那个文件里呢? 能简单说说这些宏的意思么
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

7
 
“是否可以在RomInit.s里少给FLASH分配大概5M左右的空间 以供MMU使用试试”
to Heaven_Redsky: 不太清楚你的意思...
MMU 管理是OS提供的呀,跟FLASH有啥关系呢?
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

8
 
可能没说明白
我以前碰到过这样的情况给FLASH少5M左右的时候 就能够避免出现exception
时间久了忘记当时具体情况
模糊中记得当时有个同事提到MMU。。。 我只是顺便提一句 供楼主参考

是否可以看看RomInit.S里是否有正确初始化MMU的代码
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

9
 
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后问题依旧...

还问下:你们当初也是某一块的内存空间超过一定的大小就导致系统不能正常启动的么?
        启动中的异常有手段进行检测么?
  
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

10
 
再补充下内存资源的使用情况是:
BOOTROM         --CS0
FLASH                --CS1
SDRAM                --CS2
SRAM            --CS3
NANDFLASH        --CS4
CPLD               --CS5
DSP             --CS7


多谢 Heaven_Redsky了...
 
 
 

回复

2

帖子

0

TA的资源

一粒金砂(初级)

11
 
降频试试
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

12
 
wangxin_801115: 能简单解释下原因么?
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

13
 
http://topic.eeworld.net/u/20090321/23/0a637fa9-58ae-4605-8ad8-1fab2fa7c596.html
我也不知道是否管用
我的系统也出现了类似你的问题
我将主频和SDRAM频率减小就好了
但是我的是CE系统
你可以试试这个是最简单的实验方法了!
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

14
 
学习一下,呵呵。
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

15
 
wangxin_801115: 大哥 ,降频不行,我将晶振从100M换成50M,同时修改了代码,仍然不行。100MHz晶振频率作为SDRAM与CPU的时钟源。

    我这样认为的降频的,不知道对不对: 系统在CS7内存超过160M以后,usrMmuInit()需要更多时间去初始化内存,在看门狗定计数值一定的情况下,降频可以造成看门狗清狗的时间延长了,以便内存初始化有更多时间,所以我在prjConfig.c中将删除看门狗,之后让CS7内存超过160M系统仍不能正常启动。不知道wangxin_801115有何看法?

 
 
 

回复

3

帖子

0

TA的资源

一粒金砂(中级)

16
 
vxWorks没有BOOT吗?
应该在BOOT初始化CPU时就设置了主频和SDRAM的频率,应该是在汇编部分
只需要将这个设置减小就行了,别换晶振啊!
 
 
 

回复

4

帖子

0

TA的资源

一粒金砂(初级)

17
 
引用 15 楼 wangxin_801115 的回复:
vxWorks没有BOOT吗?
应该在BOOT初始化CPU时就设置了主频和SDRAM的频率,应该是在汇编部分
只需要将这个设置减小就行了,别换晶振啊!


应该在RomInit.s里吧

LZ是不是再仔细查一下mmu相关的宏定义 看看有没有对其映射关系相关之类的内容?
刚才搜了一下 楼主看看能不能参考一下
http://blog.eeworld.net/makethyme/archive/2006/03/18/628128.aspx
 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

18
 
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频率无关呀...
   

 
 
 

回复

1

帖子

0

TA的资源

一粒金砂(初级)

19
 
我也遇到了同样的问题  楼主能说说是如何解决的么
 
 
 

回复
您需要登录后才可以回帖 登录 | 注册

随便看看
查找数据手册?

EEWorld Datasheet 技术支持

相关文章 更多>>
关闭
站长推荐上一条 1/10 下一条

 
EEWorld订阅号

 
EEWorld服务号

 
汽车开发圈

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: 国产芯 安防电子 汽车电子 手机便携 工业控制 家用电子 医疗电子 测试测量 网络通信 物联网

北京市海淀区中关村大街18号B座15层1530室 电话:(010)82350740 邮编:100190

电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号 Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表