EBOOT通过bin文件形式读取、下载LOGO----韦伯篇之自我分析
2010-03-14 10:08
260 查看
原文内容:http://blog.csdn.net/Veabol/archive/2009/05/07/4157647.aspx
一般的WINCE系统都是在EBOOT阶段初始化LCD,所以要想显示自己的LOGO就需要
在EBOOT阶段将LOGO内容显示出来,读取LOGO的方式可以和从存储器中读取NK一样,具体位置自己来定义。
在EBOOT阶段下载LOGO保存到FLASH中可以采用下载bin文件的方式,bin文件
中的内容可以参考eboot.bin和nk.bin。
根据/WINCE500/PUBLIC/COMMON/OAK/DRIVERS
/ETHDBG/BLCOMMON下blcommon.c文件中各函数分析eboot.bin文件的结构:
Eboot.bin的前7个字节("B000FF/x0A
")用来判断是否为WINCE的bin文件,接下
边分别是4字节映像的起始地址dwImageStart
、4
字节映像大小dwImageLength
,接着分别是4
字节接收地址dwRecAddr
、4字节接收长度dwRecLen
、4字节接收检验和dwRecChk
,接下来是eboot.nb0压缩后的数据,即
eboot运行时的数据,查看eboot.bin文件dwRecLen值为4,即根据dwRecChk后边的4字节数据得到
dwRecChk,VerifyChecksum()函数是将这4字节数据相加得到dwRecChk。
Offset 0 1 2 3 4 5
6 7 8 9 A B C D E F
00000000 42 30 30 30 46 46 0A
00
80 03 80
88 20 07 00
00
B000FF..€.€?...
00000010
80 03 80
04 00 00 00
E2 01 00 00
9B 5C 01 EA
40
€.€....?..沑.闌
00000020 80 03 80 08 00 00 00 F1 02 00 00 45 43 45
43 F0 €.€....?..ECEC?
00000030 67 0A 80
48 80 03 80 04 00 00 00
DD 01 00 00 F0 g.€H€.€....?..
9B 5C 01 EA
正好是我的eboot.nb0的起始4个字节。
所以只要将图片的24位数据再加上前边的结构就可以生成一个bin文件,便可以通过USB或
者Ethernet下载并被eboot正确识别并处理。
Eboot.bin的前7个字节是文件头,内容为42 30 30 30 46 46 0A,即“B000FF/x0A”,这是判别镜像文件是.bin类型的一句。接下来的4字节是操作系统镜像数据的目的起始地址(ImageStart),再4个字节是以字节为单位的镜像数据长度(ImageLength).例如,在上图中ImageStart=0x80038000,ImageLength=0x00072088。再往下就是eboot.bin的逐条记录(Record),也就是EBOOT镜像的数据内容正文,每一条记录由4个字节的存储地址(RecordStart)、4字节的数据长度(RecordLength)、4字节的校验码(RecordCheckSum)和RecordLength个字节的记录数据(RecordData)组成。上入中我们可以知道,80038000是第一条记录的起始地址,存放数据的长度为00000004,校验码为000001E2,4字节的数据为:EA015C9B。上图中用斜体字标记的是一个完整的镜像记录,其存储起始地址是0x80038040,记录数据长度为8个字节。镜像运行时的偏移地址0X40(相对于0x80038000)位置处的数据刚好是0X43454345.紧随其后的4个字节数据恰好等于镜像运行时的ImageStart(0x800A67F0)。
这里必须解释一下:0x80038000是操作系统镜像运行时的起始存储地址,一般情况下它总是等于镜像文件头所记录的IamgeStart.
而0x800A67F0是物理RAM程序内存区域的起始地址。
由此我们可以推断韦伯兄的config.bib文件的部分内容:
EBOOT 80038000 00080000 EBOOT IMAGE :512 KB
EBOOT_RAM 800B0000 00010000 RAM ;RAM : 64KB
首先,声明,以上仅是个人猜测!如有错误和冒犯请见谅!
猜测理由:EBOOT运行的起始地址是0X800A67F0,而EBOOT以及EBOOT_RAM在config.bib文件中都应该定义为RESERVED,也就是说都是保留的。而保留的值是按块存储或者提交(或许预留更好点,仅为个人理解)[1block=64KB,Windows ce操作系统对虚拟内存的分配使用以块为粒度的]对齐所得。所以运行的起始地址这里定义为0X800B0000,至于0X00080000则是第二个4个字节的长度:0X00072088按照64KB的粒度对齐所得。而这个大小0X00010000,纯属个人主观臆断,毕竟是EBOOT运行在虚拟内存空间,不应该太大就好了!
而具体的代码分析正在整理中!
一般的WINCE系统都是在EBOOT阶段初始化LCD,所以要想显示自己的LOGO就需要
在EBOOT阶段将LOGO内容显示出来,读取LOGO的方式可以和从存储器中读取NK一样,具体位置自己来定义。
在EBOOT阶段下载LOGO保存到FLASH中可以采用下载bin文件的方式,bin文件
中的内容可以参考eboot.bin和nk.bin。
根据/WINCE500/PUBLIC/COMMON/OAK/DRIVERS
/ETHDBG/BLCOMMON下blcommon.c文件中各函数分析eboot.bin文件的结构:
Eboot.bin的前7个字节("B000FF/x0A
")用来判断是否为WINCE的bin文件,接下
边分别是4字节映像的起始地址dwImageStart
、4
字节映像大小dwImageLength
,接着分别是4
字节接收地址dwRecAddr
、4字节接收长度dwRecLen
、4字节接收检验和dwRecChk
,接下来是eboot.nb0压缩后的数据,即
eboot运行时的数据,查看eboot.bin文件dwRecLen值为4,即根据dwRecChk后边的4字节数据得到
dwRecChk,VerifyChecksum()函数是将这4字节数据相加得到dwRecChk。
Offset 0 1 2 3 4 5
6 7 8 9 A B C D E F
00000000 42 30 30 30 46 46 0A
00
80 03 80
88 20 07 00
00
B000FF..€.€?...
00000010
80 03 80
04 00 00 00
E2 01 00 00
9B 5C 01 EA
40
€.€....?..沑.闌
00000020 80 03 80 08 00 00 00 F1 02 00 00 45 43 45
43 F0 €.€....?..ECEC?
00000030 67 0A 80
48 80 03 80 04 00 00 00
DD 01 00 00 F0 g.€H€.€....?..
9B 5C 01 EA
正好是我的eboot.nb0的起始4个字节。
所以只要将图片的24位数据再加上前边的结构就可以生成一个bin文件,便可以通过USB或
者Ethernet下载并被eboot正确识别并处理。
Eboot.bin的前7个字节是文件头,内容为42 30 30 30 46 46 0A,即“B000FF/x0A”,这是判别镜像文件是.bin类型的一句。接下来的4字节是操作系统镜像数据的目的起始地址(ImageStart),再4个字节是以字节为单位的镜像数据长度(ImageLength).例如,在上图中ImageStart=0x80038000,ImageLength=0x00072088。再往下就是eboot.bin的逐条记录(Record),也就是EBOOT镜像的数据内容正文,每一条记录由4个字节的存储地址(RecordStart)、4字节的数据长度(RecordLength)、4字节的校验码(RecordCheckSum)和RecordLength个字节的记录数据(RecordData)组成。上入中我们可以知道,80038000是第一条记录的起始地址,存放数据的长度为00000004,校验码为000001E2,4字节的数据为:EA015C9B。上图中用斜体字标记的是一个完整的镜像记录,其存储起始地址是0x80038040,记录数据长度为8个字节。镜像运行时的偏移地址0X40(相对于0x80038000)位置处的数据刚好是0X43454345.紧随其后的4个字节数据恰好等于镜像运行时的ImageStart(0x800A67F0)。
这里必须解释一下:0x80038000是操作系统镜像运行时的起始存储地址,一般情况下它总是等于镜像文件头所记录的IamgeStart.
而0x800A67F0是物理RAM程序内存区域的起始地址。
由此我们可以推断韦伯兄的config.bib文件的部分内容:
EBOOT 80038000 00080000 EBOOT IMAGE :512 KB
EBOOT_RAM 800B0000 00010000 RAM ;RAM : 64KB
首先,声明,以上仅是个人猜测!如有错误和冒犯请见谅!
猜测理由:EBOOT运行的起始地址是0X800A67F0,而EBOOT以及EBOOT_RAM在config.bib文件中都应该定义为RESERVED,也就是说都是保留的。而保留的值是按块存储或者提交(或许预留更好点,仅为个人理解)[1block=64KB,Windows ce操作系统对虚拟内存的分配使用以块为粒度的]对齐所得。所以运行的起始地址这里定义为0X800B0000,至于0X00080000则是第二个4个字节的长度:0X00072088按照64KB的粒度对齐所得。而这个大小0X00010000,纯属个人主观臆断,毕竟是EBOOT运行在虚拟内存空间,不应该太大就好了!
而具体的代码分析正在整理中!
相关文章推荐
- EBOOT通过bin文件形式读取、下载LOGO----韦伯篇之自我分析
- EBOOT通过bin文件形式读取、下载LOGO----韦伯篇之自我分析
- EBOOT通过bin文件形式读取、下载LOGO
- EBOOT通过bin文件形式读取、下载LOGO
- EBOOT通过bin文件形式读取、下载LOGO
- 转载-EBOOT通过bin文件形式读取、下载LOGO
- 实现BIN文件数据读取的TCL脚本分析
- Go1.5从文件读取密码,然后到远端下载文件的小实例.(通过sftp协议下载)
- 读取oracle blob字段内容并以文件形式下载
- 后台通过读取流的形式,实现下载功能
- ASP.NET文件下载简单实现(也可以通过直接读取数据库 大字段文件,如oracle 中的bolg,long raw 等大字段文件)
- 四极管 BIN文件下载数据结构分析(二)
- 四极管 BIN文件下载数据结构分析(一)
- iis 6.0限制通过域名或者ip的形式从外部访问.txt的文件( IIS6.0禁止用户下载指定类型文件)
- java开发:读取ftp服务器文件通过浏览器下载
- 文件下载:POI读取word或Excel,修改内容后以流的形式输出到前端
- 通过form表单的形式下载文件。
- MDK生成的BIN文件用DNW通过USB下载RAM中运行的问题
- Strust2通过“流”下载文件时对结果的处理
- HDFS读文件过程分析:读取文件的Block数据