7759|22

75

帖子

0

TA的资源

一粒金砂(初级)

楼主
 

eboot, TOC,NK 地址跳转的问题 [复制链接]

平台:S3C2440+WINCE5。0+EBOOT
问题1:在Eboot输出的调试信息中TOC的ID[1],打印出来的信息中dwLoadAddress:0x80200000 dwJumpAddress:0x8037cf88
       其中dwLoadAddress是把nk.bin拷贝到RAM的虚拟地址,dwJumpAddress应该就是EBOOT完成拷贝之后,跳转到这个地址
        去执行,问题是拷贝内核到RAM地址和跳转去执行的内核地址是不一样的。0x80200000 这个地址是在config.bib中确定,
        那么dwJumpAddress又是在那里确定,为什么这两个地址可以不一样?
问题2:在boot.bib中 BINFS 0x80080000 00021000关于BINFS地址的设置又有什么需要注意的?跟什么有关系,怎么换算,它的
       大小是如何确定的,跟内核大小有什么关系?
      

最新回复

mark   详情 回复 发表于 2009-12-18 19:39
点赞 关注

回复
举报

65

帖子

0

TA的资源

一粒金砂(初级)

沙发
 
自己先回,我想到第一个问题的答案,是否就是因为EBOOT下载的是BIN文件,而不是NB0文件,所以造成拷贝内核到RAM的地址和跳转去执行内核的RAM地址不一样???讨论哈!
 
 

回复

80

帖子

0

TA的资源

一粒金砂(初级)

板凳
 
第二个问题,BINFS 0x80080000 00021000中是保留了一段内存给BOOTPART库使用,
大小与NK无关,跟FLASH的大小有关,具体计算方法如下:
BOOL BP_Init(
  LPBYTE pMemory,
  DWORD dwSize,
  LPCTSTR lpActiveReg,
  PPCI_REG_INFO pRegIn,
  PPCI_REG_INFO pRegOut);

dwSize
[in]This value should be at least the size of one flash block plus one sector plus sectors divided by blocks multiplied by eight, or as expressed as a mathematical statement: block + sector + (sectors/block) * 8.
 
 
 

回复

71

帖子

0

TA的资源

一粒金砂(初级)

4
 
问题是跳转去执行内核的RAM地址是在那里设置的,config.bib和boot.bib都找不到
问题三:eboot中的全局变量g_TOC的地址,书上说是RomImage确定了它的位置,那么RomImage是如何确定的,是自动设置的还是通过文件固定的,譬如象.bib文件设置一样??
 
 
 

回复

61

帖子

0

TA的资源

一粒金砂(初级)

5
 
引用 3 楼 fan227 的回复:
问题是跳转去执行内核的RAM地址是在那里设置的,config.bib和boot.bib都找不到
问题三:eboot中的全局变量g_TOC的地址,书上说是RomImage确定了它的位置,那么RomImage是如何确定的,是自动设置的还是通过文件固定的,譬如象.bib文件设置一样??


楼主,0x80200000 这个地址是在config.bib中确定的,这个0x80200000 是虚拟地址啊。但在eboot中MMU都没有打开,不能用0x80200000 这个地址跳转,而是用0x80200000 对应的物理地址跳转的啊

这个0x80200000 对应的物理地址在oemaddrtab_cfg中有,现在2440的BSP一般对应的是0x30200000,这个才是bootloader启动的地址啊。
至于g_TOC,因为我使用的不是eboot,还不明白,不过《Windows CE工程实践完全解析 》——这本书讲的不错。我在网上看目录专门有讲的。
 
 
 

回复

62

帖子

0

TA的资源

一粒金砂(初级)

6
 
引用 4 楼 gooogleman 的回复:
引用 3 楼 fan227 的回复:
问题是跳转去执行内核的RAM地址是在那里设置的,config.bib和boot.bib都找不到
问题三:eboot中的全局变量g_TOC的地址,书上说是RomImage确定了它的位置,那么RomImage是如何确定的,是自动设置的还是通过文件固定的,譬如象.bib文件设置一样??


楼主,0x80200000 这个地址是在config.bib中确定的,这个0x80200000 是虚拟地址啊。但在eboot中MMU都没有打开,不能用0x80200000 这个地址跳转,…

哈哈,我知道这是虚拟地址,你可能没有明白我的问题这个,0x80200000 对应的物理地址在oemaddrtab_cfg中有,现在2440的BSP一般对应的是0x30200000,这个我也知道,问题是现在我装载NK.BIN的地址跟跳转去执行的RAM地址不一致,所有有疑惑,还有0x80200000和0x8037cf88对应的物理地址分是0x30200000和0x3037cf88 ,还有EBOOT中应该开了MMU,后来又关了吧,具体我没研究,不过最后确实跳转去执行内核的是物理地址0x3037cf88,这个没有问题,问题是为什么不跳转到
0x30200000,而且0x3037cf88这个地址是怎么来的,怎么设置的,不太明白
 
 
 

回复

66

帖子

0

TA的资源

一粒金砂(初级)

7
 
看看代码呗,据说NK.nb0在前面有很多0000的空洞,就是没有用那种。是不是程序自己跳过这些0去执行了

你看看代码是不是这个原因。我现在没有时间看这个,你看明白了,通知一声哦。哈哈。
 
 
 

回复

74

帖子

0

TA的资源

一粒金砂(初级)

8
 
引用 4 楼 gooogleman 的回复:
引用 3 楼 fan227 的回复:
问题是跳转去执行内核的RAM地址是在那里设置的,config.bib和boot.bib都找不到
问题三:eboot中的全局变量g_TOC的地址,书上说是RomImage确定了它的位置,那么RomImage是如何确定的,是自动设置的还是通过文件固定的,譬如象.bib文件设置一样??


楼主,0x80200000 这个地址是在config.bib中确定的,这个0x80200000 是虚拟地址啊。但在eboot中MMU都没有打开,不能用0x80200000 这个地址跳转,…


在eboot中MMU只是在startup.s中是关闭的,在退出startup后就开启了,
在eboot的所有c代码中就是用虚拟地址。

 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

9
 
在eboot的所有c代码中就是用虚拟地址。 ??

我记得博客园有个人也是遇到了这个问题。开发bootloader的要注意一下。
总之我的ADS bootloader是没有开的。
 
 
 

回复

72

帖子

0

TA的资源

一粒金砂(初级)

10
 
我去确认了哈,EBOOT在start.s中开了MMU,在util.s中关了,其实这是个很小的问题,以前就记得是先开,后关,不过这个问题,好象跟我提的问题一点关系都没有啊,兄弟有谁知道,我问的问题啊,还有gooogleman,EBOOT下载的是nk.bin文件不是nk.nb0文件,所以应该不存在你说的空洞问题。我要是解决了这个问题,我到时候贴出来,你MARK哈就行了
 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

11
 
EBOOT最后跳转到NK.bin中,是NK.exe的入口处,并非NK的起始地址,
一般都是在起始地址之后的一个地址。
你可以通过viewbin nk.bin查看这个起始地址。
 
 
 

回复

82

帖子

0

TA的资源

一粒金砂(初级)

12
 
引用 9 楼 fan227 的回复:
我去确认了哈,EBOOT在start.s中开了MMU,在util.s中关了,其实这是个很小的问题,以前就记得是先开,后关,不过这个问题,好象跟我提的问题一点关系都没有啊,兄弟有谁知道,我问的问题啊,还有gooogleman,EBOOT下载的是nk.bin文件不是nk.nb0文件,所以应该不存在你说的空洞问题。我要是解决了这个问题,我到时候贴出来,你MARK哈就行了

不是啊,nk.bin是不能执行的,即使下到内存也不行,会解压成NK.nb0的。无论下载什么格式,执行的是NK.nb0不知道微软为什么这么干。
估计NK.bin是为了好管理,和binfs配合。
 
 
 

回复

76

帖子

0

TA的资源

一粒金砂(初级)

13
 
Eboot下载的是bin,但烧进Flash的是nb0,解压后烧进去的
 
 
 

回复

72

帖子

0

TA的资源

一粒金砂(初级)

14
 
当然Eboot也可以支持下载nb0
 
 
 

回复

72

帖子

0

TA的资源

一粒金砂(初级)

15
 
问题2:在boot.bib中 BINFS 0x80080000 00021000关于BINFS地址的设置又有什么需要注意的?跟什么有关系,怎么换算,它的
      大小是如何确定的,跟内核大小有什么关系?
这啥问题?你是BINFS是用来存放BINFS的Image的?还是。。。,而且是在boot.bib中
 
 
 

回复

55

帖子

0

TA的资源

一粒金砂(初级)

16
 
引用 11 楼 gooogleman 的回复:
引用 9 楼 fan227 的回复:
我去确认了哈,EBOOT在start.s中开了MMU,在util.s中关了,其实这是个很小的问题,以前就记得是先开,后关,不过这个问题,好象跟我提的问题一点关系都没有啊,兄弟有谁知道,我问的问题啊有gooogleman,EBOOT下载的是nk.bin文件不是nk.nb0文件,所以应该不存在你说的空洞问题。我要是解决了这个问题,我到时候贴出来,你MARK哈就行了

不是啊,nk.bin是不能执行的,即使下到内存也不行,会解…

烧写确实nk.bin,在RAM里面运行肯定是nk.bn0,问题是应该也不存在空洞,除非eboot解码nk.bin为nk.bn0时会产生0空洞,那就不是eboot的BUG,另外我用NBOOT时,是直接跳转到0x30200000 去执行内核,而不是象EBOOT一样跳转到0x3037cf88这个地址去执行,我就奇怪这个???0x3037cf88这个地址也不知道是怎么的来,我是通过调试输出TOC信息,得到跳转地址在这里啦
 
 
 

回复

88

帖子

0

TA的资源

一粒金砂(初级)

17
 
引用 14 楼 hzdysymbol 的回复:
问题2:在boot.bib中 BINFS 0x80080000 00021000关于BINFS地址的设置又有什么需要注意的?跟什么有关系,怎么换算,它的
      大小是如何确定的,跟内核大小有什么关系?
这啥问题?你是BINFS是用来存放BINFS的Image的?还是。。。,而且是在boot.bib中

BINFS应该就是ROM-ONLY FILE SYSTEM, 你说是用来存放BINFS的Image,我想是把那部分做为BINFS的Image???

sunrain_hjb 给出的解释是这样的:见2楼
第二个问题,BINFS 0x80080000 00021000中是保留了一段内存给BOOTPART库使用,
大小与NK无关,跟FLASH的大小有关,具体计算方法如下:
BOOL BP_Init(
  LPBYTE pMemory,
  DWORD dwSize,
  LPCTSTR lpActiveReg,
  PPCI_REG_INFO pRegIn,
  PPCI_REG_INFO pRegOut);

dwSize
[in]This value should be at least the size of one flash block plus one sector plus sectors divided by blocks multiplied by eight, or as expressed as a mathematical statement: block + sector + (sectors/block) * 8.
 
 
 

回复

67

帖子

0

TA的资源

一粒金砂(初级)

18
 
我也想知道0x30038000这个地址怎么来的……
 
 
 

回复

54

帖子

0

TA的资源

一粒金砂(初级)

19
 
一行行代码看,就结了。
 
 
 

回复

78

帖子

0

TA的资源

一粒金砂(初级)

20
 
Binfs跟ROM Only File System应该是完全不同的两回事,
Binfs是一种文件系统,跟FAT之类是一个概念;而ROM Only File System则是OS选用的是RAM,RAM+ROM还是ROM Only文件系统中的一个,而且一般这里的ROM文件系统也不会用Binfs,所以说两个之间可以说基本上没有什么关系
 
 
 

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

随便看看
查找数据手册?

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-2025 EEWORLD.com.cn, Inc. All rights reserved
快速回复 返回顶部 返回列表