关于6410+WinCE6.0开机界面logo的问题

trason

关于6410+WinCE6.0开机界面logo的问题 [复制链接]

关于开机logo一般有两种实现方法：
方法一：以头文件的形式打包在EBOOT.bin中，但是该方法往往导致EBOT.bin太大；
方法二：将bmp转换成bin文件，烧写在NandFlash某个固定的地址，Eboot运行时读取该地址内容，放入显示缓冲里实现。

第一种方法在此不讨论，关于第二种方法，刚开始做就遇到问题，（我用的是UT-6410），问题如下：
1、在image_cfg中有以下配置：
   #define DRAM_BASE_PA_START            (0x50000000)                //DRAM物理起始地址？
   #define DRAM_BASE_CA_START            (0x80000000)                //
   #define DRAM_BASE_UA_START            (0xA0000000)                //DRAM经过MMU映射后的虚拟起始地址？
   后面的注释是我加的，请问加的是否正确？0x80000000是什么地址？难道是DMA缓存地址？这个问题很菜，哈哈
2、在使用SD卡进行烧写EBOOT.bin时，提示地址是：
   ImageStart = 0x80030000, ImageLength = 0x42F38, LaunchAddr = 0x80066D64
   这个0x80030000肯定不是NandFlash物理地址，问题就是什么时候将EBOOT.bin的内容写到了NandFlash里？写到了什么地
   方？谁干的？
   因为在烧写NK.bin的时候，提示地址是：mageStart = 0x80100000, ImageLength = 0x1F3C49C, LaunchAddr =
   0x801076EC，在写完后要等待一段时间（1分钟？）系统才能自启动，这一分钟肯定是将先写到0x80030000（到底是DRAM还
   是缓存）中NK.bin解析到NandFlash中，同样我也不知道烧到了NandFlash的什么地方？

   先问两个问题吧，有关开机界面遇到的问题以及最终解决方法，努力在这个帖子有个完整结贴。

kailern

看我的博客说明，有一个内存地址的两次重映射。
http://fpcfjf.blog.163.com/blog/static/55469793201001511245449/edit/

天目

#define DRAM_BASE_PA_START            (0x50000000)                // ARM,物理地址
#define DRAM_BASE_CA_START            (0x80000000)                // WINCE系统物理地址
#define DRAM_BASE_UA_START            (0xA0000000)                // 加了0X20000000

ImageStart = 0x80030000, 内存映像载入地址
ImageLength = 0x42F38, 映像长度
LaunchAddr = 0x80066D64  映像执行地址

NK.BIN是从闪存运到内存的,在内存中解压缩....


开机的LOGO可以在EBOOT阶段加入初始化DISPlay,阶段内存开辟一端控制放LOGO,然后系统起来的加载...............

wuxiangyun

继续啊~
     平台是：WinCE6.0+S3C6410，想实现的事情是：实现开机logo。但由于Eboot.bin 512KBytes大小的限制，想将logo.bin（750KBytes）下载到NandFlash的第6block开始的地址处，然后在Eboot中读出这段内容放入显示缓冲区进行显示。
    遇到的问题是：由于Eboot对NandFlash一开始就进行了分区：具体为0 block放Nboot； 1 block 放TOC；2~5block放EBOT；6~7FFblock（2K/page, 64pages/block共256M）后被格式化为Binfs放NK；现在想把logl.bin放到6~10block的地方，请问该做哪些工作？当通过USB OTG把.bin文件读到一个缓冲区后，在什么地方判断出是NBoot、EBoot、RAM image的？这应该和TOC有关，但没搞明白？

apple0731

第一种已经实现了
  学习第二种

jiyu29009

我们做的每个产品都有开机Logo，甚至产品序列号、PCB版本号等等。都是以二进制形式存储在Nand Flash中的，至于存在哪里？怎么写入？怎么读？你自己完全可以在代码中自己控制啊！

关于你的问题，看我的解答：

1、在image_cfg中有以下配置：
? #define DRAM_BASE_PA_START? ? ? ? ? ? (0x50000000)? ? ? ? ? ? ? ? //DRAM物理起始地址？
? #define DRAM_BASE_CA_START? ? ? ? ? ? (0x80000000)? ? ? ? ? ? ? ? //
? #define DRAM_BASE_UA_START? ? ? ? ? ? (0xA0000000)? ? ? ? ? ? ? ? //DRAM经过MMU映射后的虚拟起始地址？
? 后面的注释是我加的，请问加的是否正确？0x80000000是什么地址？难道是DMA缓存地址？这个问题很菜，哈哈
    注释基本都是对的，第一行是DRAM的物理地址，第二行是经过MMU映射之后的虚拟地址，第三行是在虚拟地址的基础上增加了Cache（即缓存）后的地址。和DMA没什么关系，这些地址你在MMU映射转换表中应该能看得到的。

2、在使用SD卡进行烧写EBOOT.bin时，提示地址是：
? ImageStart = 0x80030000, ImageLength = 0x42F38, LaunchAddr = 0x80066D64
? 这个0x80030000肯定不是NandFlash物理地址，问题就是什么时候将EBOOT.bin的内容写到了NandFlash里？写到了什么地方？谁干的？
? 因为在烧写NK.bin的时候，提示地址是：mageStart = 0x80100000, ImageLength = 0x1F3C49C, LaunchAddr =
? 0x801076EC，在写完后要等待一段时间（1分钟？）系统才能自启动，这一分钟肯定是将先写到0x80030000（到底是DRAM还
? 是缓存）中NK.bin解析到NandFlash中，同样我也不知道烧到了NandFlash的什么地方？

   EBoot的ImageStart=0x80030000是指Eboot运行时在DRAM中的地址，这是在Build Eboot时在Eboot.bib中指定的。后面的LaunchAddr是指Eboot运行起来时真正执行代码的地方，因为Paltform Builder做出来的Eboot.bin中，前面有一段头的，最开始是跳转指令，后面一部分是空的，真正的代码在后面偏移0x76EC的地方。至于将Eboot.bin烧到了什么地方，这里是看不出来的，要看你的具体代码。
  同理，NK.bin显示的ImageStart=0x80100000也是指NK将来在DRAM中运行时的地址。LaunchAddr也是跳转过去真正执行的代码的位置。NK.bin烧的位置也要看你代码。

18545862

我们做的每个产品都有开机Logo，甚至产品序列号、PCB版本号等等。都是以二进制形式存储在Nand Flash中的，至于存在哪里？怎么写入？怎么读？你自己完全可以在代码中自己控制啊！

关于你的问题，看我的解答：

1、在image_cfg中有以下配置：
  #define DRAM_BASE_PA_START            (0x50000000)                //DRAM物理起始地址？
  #define DRAM_BASE_CA_START            (0x80000000)                //
  #define DRAM_BASE_UA_START            (0xA0000000)                //DRAM经过MMU映射后的虚拟起始地址？
  后面的注释是我加的，请问加的是否正确？0x80000000是什么地址？难道是DMA缓存地址？这个问题很菜，哈哈
    注释基本都是对的，第一行是DRAM的物理地址，第二行是经过MMU映射之后的虚拟地址，第三行是在虚拟地址的基础上增加了Cache（即缓存）后的地址。和DMA没什么关系，这些地址你在MMU映射转换表中应该能看得到的。

2、在使用SD卡进行烧写EBOOT.bin时，提示地址是：
  ImageStart = 0x80030000, ImageLength = 0x42F38, LaunchAddr = 0x80066D64
  这个0x80030000肯定不是NandFlash物理地址，问题就是什么时候将EBOOT.bin的内容写到了NandFlash里？写到了什么地方？谁干的？
  因为在烧写NK.bin的时候，提示地址是：mageStart = 0x80100000, ImageLength = 0x1F3C49C, LaunchAddr =
  0x801076EC，在写完后要等待一段时间（1分钟？）系统才能自启动，这一分钟肯定是将先写到0x80030000（到底是DRAM还
  是缓存）中NK.bin解析到NandFlash中，同样我也不知道烧到了NandFlash的什么地方？

  EBoot的ImageStart=0x80030000是指Eboot运行时在DRAM中的地址，这是在Build Eboot时在Eboot.bib中指定的。后面的LaunchAddr是指Eboot运行起来时真正执行代码的地方，因为Paltform Builder做出来的Eboot.bin中，前面有一段头的，最开始是跳转指令，后面一部分是空的，真正的代码在后面偏移0x76EC的地方。至于将Eboot.bin烧到了什么地方，这里是看不出来的，要看你的具体代码。
  同理，NK.bin显示的ImageStart=0x80100000也是指NK将来在DRAM中运行时的地址。LaunchAddr也是跳转过去真正执行的代码的位置。NK.bin烧的位置也要看你代码

xnmilo

谢谢“yangcuncunzhang”!，在Eboot.bin中我确实找到了：

MEMORY
;-----------------------------------------------------
;    NAME        ADDRESS    SIZE        TYPE
;-----------------------------------------------------
    PTS         80000000    00020000    RESERVED        ; Page Table    : 128 KB
    ARGS        80020800    00000800    RESERVED        ; BSP Args    : 2 KB
    EBOOT       80030000    00080000    RAMIMAGE        ; Eboot Image    : 512 KB
    RAM         800B0000    00010000    RAM             ; RAM        : 64 KB
    BINFS       800C0000    00030000    RESERVED        ; Bin FS        : 192 KB
    STACK       800FC000    00004000    RESERVED        ; Stack        : 16 KB (sharing with Step Loader)我的理解是Eboot.bib定义的这个表（上表只是部分代码……）是在Eboot运运行阶段对虚拟地址的分配，当真正进入操作系统后，这个就没用了（好像还有个共享区，是ARGS吗？），重新对虚拟地址进行分配靠的是config.bib，这样理解对吗？那g_OEMAddresstable，还有platform.bib，好像还有project.bin又都是什么关系呢？关键是config.bin和g_OEMAderesstable的关系，这是问题一！

这两天一直再看Eboot的代码，我理解的是：先是USB OTG将读的数据放入一段缓存，然后再通过读数据的前7个字节的内容，从而判断出是.bin,.nb0等，从而进入相应的下载程序。比如判断出事.bin就进入static BOOL DownloadBin (LPDWORD pdwImageStart, LPDWORD pdwImageLength, LPDWORD pdwLaunchAddr)这个函数进行下载操作。然后再根据‘loader.h’和‘image_cfg.h’中定义的地址下载到相应的地方。现在的问题是：因为要下载的内容有：Nboot\Eboot\NK，同样都是.bin文件，到底是什么时候区分出来的呢？这是第二个问题。

我现在的思路就是'logo.bin'通过USB OTG放到缓存后，EBOOT如何才能把它与Nboot.bin,Eboot.bn,NK.bin区分开来，然后我在‘loader.h’和‘image_cfg.h’也定义相应的下载地址和类型，然后执行下载操作。这样的思路应该没问题吧？求教达人啊

今天继续看代码……

cow_cga

我们做的每个产品都有开机Logo，甚至产品序列号、PCB版本号等等。都是以二进制形式存储在Nand Flash中的，至于存在哪里？怎么写入？怎么读？你自己完全可以在代码中自己控制啊！

我就是向实现这个，可不会啊……

540227699

学习了！
顶！！

eqiqhigh1988

这个挺简单的啊，主要注意一下几点：
1、nandflash的驱动能够正确读写；
2、nandflash的layout；
3、是在BootLoader中实现还是在应用程序实现：在BootLoader里实现比较简单；如果是在应用程序实现，需要在nandflash的驱动里向应用程序提供接口来操作flash；

wawj1819

现在就想在bootloader中实现

hzq23

引用 11 楼 haiou_arm 的回复:
现在就想在bootloader中实现

那你就在display初始化的时候，从flash把数据读出来，然后memcpy到framebuffer不就行了啊

poiuyt

这个要学习，我采用修改代码的方法，第一种没有啥问题哦。

chnyuan

引用 13 楼 gooogleman 的回复:
这个要学习，我采用修改代码的方法，第一种没有啥问题哦。

如果要是分辨率大的图片，以数组的形式编译就不方便了，还是把图片放在flash里比较好，个人认为~~

iceflasher

学习学习

coldarrow

哈哈，在BootLoader中实现很简单的，这个我已经实现；但是，在应用程序中如何实现我不懂，如果咱俩能中和一下就好了，嘻嘻…

w19864h

引用 16 楼 wolfmvp 的回复:
哈哈，在BootLoader中实现很简单的，这个我已经实现；但是，在应用程序中如何实现我不懂，如果咱俩能中和一下就好了，嘻嘻…

在应用程序中实现就是要修改flash驱动，在fmd的iocontrol里添加case就行了，跟BootLoader里的差不多，只不过如果你要是采用multi-bin的话，打开flash的时候跟非multi-bin不太一样，注意下就行了。。

rambo123321

问题是：我怎样将其写到flash中！
紧接着上面的：Eboot是如何判断通过USB OTG读入缓冲区的数据是Nboot.bin\Eboot.bn\NK.bin？这是问题的关键！？

上面已经描述，Eboot是通过OEMReadData，也就是UbootReadData（在usb.c中）读出前7个字节，判断出了.bin还是nb0.
接着分析代码，发现Eboot在判断是Nboot.bin\Eboot.bn\NK.bin？的时候，也是靠UbootReadData读取起始地址和长度的，然后靠这个起始地址和长度来判断的？
我们知道USB OTG是靠中断触发读取的，它只要读进来就随便放到了g_pDownPt指向的一个缓冲区，这个缓冲区的地址和读到的数据的起始地址有何相关呢？

引用 12 楼 hao507 的回复:
引用 11 楼 haiou_arm 的回复:
现在就想在bootloader中实现

那你就在display初始化的时候，从flash把数据读出来，然后memcpy到framebuffer不就行了啊

fastlin

我的图片是：800*480像素的。有750KBytes大，

引用 14 楼 hao507 的回复:
引用 13 楼 gooogleman 的回复:
这个要学习，我采用修改代码的方法，第一种没有啥问题哦。

如果要是分辨率大的图片，以数组的形式编译就不方便了，还是把图片放在flash里比较好，个人认为~~