RealTekFlash架构及使用Flash取代Eeprom方法Part1.docx
《RealTekFlash架构及使用Flash取代Eeprom方法Part1.docx》由会员分享，可在线阅读，更多相关《RealTekFlash架构及使用Flash取代Eeprom方法Part1.docx（12页珍藏版）》请在冰豆网上搜索。
RealTekFlash架构及使用Flash取代Eeprom方法Part1
RealTek-Flash架构及使用Flash取代Eeprom方法--Part-1
*******************************************************************************
学习内容：
1：
RealTek的Flash架构。
2：
RealTek的FlashPage分析。
3：
RealTek的FlashPage存储方式举例。
20111009
*******************************************************************************
1：
RealTek的Flash架构
以LENOVO_LI2361D的CODE为例，此机种使用一颗2Mbit的MX25L2026FLASH
回顾20111008--MCU寻址方式及Bank概念学习.docx那份文件中看到的生成的bin文件，LENOVO_LI2361D_RTD2743PD_LG_LM230WF8.bin，CommonBank及各BankX的大小如下所示：
CommonBank最大范围为0x2BC4+8=0x2BCC，（CommonBank设定范围为0x0000~0x2FFF）
Bank0的最大范围为0xE0ED+1=0xE0EE。
（BanKX设定范围为0x3000~0xFFFF）
Bank1的最大范围为0xBBF5+0x0133=0xBD28。
Bank2的最大范围为0xF946+1=0xF947。
Bank3的最大范围为0xAEDE+1=0xAEDF。
料。
如下所示（Page12～Page14任意一个）：
二：
Page15解析：
前面已经有说过，在Realtek的Code中，Page15是一个比较特殊的Page，它在软体中的功能是唯一的：
只用来存放HDCP-KEY。
Page15的MCU寻址地址为：
0xF000~0xFFFF，可是，Realtek的HDCP-KEY的总长度只有325个byte（包含了前5个byte--包含20个0和20个1的控制key和后320个byte--20组，每组16byte的key）。
325个byte却占用了4Kbyte的空间是不是太浪费了？
？
1：
大部分的FLASH的擦除，只能是以4K为单位来擦除，如果放HDCP-KEY的4K有存放其它需要经常更新的数据，会把HDCP-KEY擦除而不可恢复。
2：
Page15的除了HDCP-KEY占用的之外的那些BYTE，也无法去存放数据，因为MCU软体中已经有占用了一部分的寻址空间，用来作为特殊功能寄存器（XFR）及DDCRAM的寻址使用，即使你往Page15的另外的那些地址存资料，MCU也无法认到（因为用来寻址的地址总线被占用）。
如下所示：
以LENOVO_LI2361D的CODE为例。
在LENOVO_LI2361D的KeilC中，以下步骤打开对话框：
从上可以看到，Off-chipXdatamemory占用的寻址地址为以0xFB00为起始的地址，长度为0x0300的空间，即：
0xFB00～0xFE00，因为我们的Bank0～Bank3使用的都是Xdata的寻址方式，而Bank0～Bank2的寻址地址被用来寻找存放CODE二进制代码，所以，此处占用的Xdata是占用了Bank3的寻址地址，即它占用的是Bank3的Page15的部份地址。
3：
在显示器的规范中，有PC99的要求，即：
当显示器在DCOFF的时候，接上显卡，显卡要有读取显示器的EDID的能力。
在早期的RealteIC，如RTD2122/RTD2120系列，它的主板上没有独立的24C02，不过它在IC内部有独立一块空间，用来与PC进行DDC的数据交换，称之为DDCRAM。
现在的RealtekIC的主板上，都是独立的24C02，在显卡的微弱电力下，可以直接与PC进行DDC数据的传送，所以，已经取消了IC内部DDCRAM功能。
虽然目前的IC已经Disable了DDCRAM功能，可是软体上还是有预留出DDCRAM的寻址地址，如下图所示：
注：
以下这个图片是以RTD2476D的ICSPEC为BASE得到的，不同IC，它的地址不一定相同。
由以上图片可知，它同样占用了Bank3的Page15的部份寻址地址，而且，与特殊功能寄存器的地址0xFB00～0xFE00会有部分的地址重合，这没有关系，因为目前的RealtekIC的软体，已经不需要用DDCRAM功能，DDCRAM的地址实际已经没有什么意义。
由以上几点，可得，Page15的解析图如下：
具体设定可以查看：
3：
RealTek的FlashPage存储方式举例
Realtek的软体中，把Bank3的Page12～Page14这三个page，分别用来存放Mode参数，Global参数，另外一个Freepage，用来做data的搬运使用。
具体哪个page用来存放哪种参数，是不定的，在flash的初始化的时候，page12用来存放MODE参数，page13用来存放global参数，page14用作freepage。
可是，当有一个page的data存满的时候，进行data的搬运后，三个page的角色又会相应变化。
在flash.h文件中，有如下定义：
每个page的最后一个byte存储的就是这组值中的一个，当存的是MODEDATA时，page的最后一个byte值为0x00；当存储的是globaldata时，page的最后一个byte值为0x01。
当某个page被用来存放modedata时，此page中的每一笔资料的16个byte又被用作如下定义，且此page的最后一个byte，存放的值为0x00，表示是modepage：
第一个byte用来指示目前存储的是MODETABLE中的哪一个mode
第二/三个byte用来指示画面的HPOSITION
第四/五个byte用来指示画面的VPOSITION
第六/七个byte用来指示画面的CLOCK是多少
第八个byte用来指示画面的PHASE是多少
第九～十五个byte用来指示画面的中心点的H/VPOSITION,CLOCK,PHASE
第十六个byte用来指示这笔资料的checksum是多少
举例：
把LenovoLi2361的机台，执行一次erase动作，再重新烧CODE，在flash初始化时，page12第一次充当存放modedata的角色。
当PC输入的MODE设定在800x60060HZ时，在画面auto结束后，读Flashpage12的资料，可以看到，page12的起始位置0xC000，存放了一组data。
这笔资料的第一个byte是0x0E=14，表示当前存储的mode是modetable中的第14组mode，如下图所示，modetable第14组mode为_MODE_800x600_60HZ，与目前PC输入的mode完全相同。
第2/3个byte用来指示此MODE的HPOSITION,第2/3个byte为0x10DB，其中，第2个byte中的第一个bit用来指示此MODE是否已经有AUTO过。
为1表示已经有AUTO过；为0表示此mode未做过auto。
除去第一个bit外，byte2/3的值为：
0x00DB=219，为此mode的HstartPostion.
第4/5个byte用来指示此MODE的VPOSTION，第4/5个byte值为0x001A=26,为此mode的VstartPostion.
第6/7个byte用来指示此MODE的CLOCK，第6/7个byte值为0x0420=1056,表示的是inputHTotal值，有些CODE表示的是OSD看到的CLOCK值。
第8个byte用来指示phase是多少，从读出来的资料可以看到，目前的phase为0x3F=63，与OSD里的资料相同，如下图：
Page12的最后一笔资料，用来存储page12的一些参数信息：
当某个page被用来存放globaldata时，此page中的每笔资料16个byte，第一个byte一定是index，用来指示这笔资料存放的是什么资料，最后一个byte一定是这组资料的checksum。
因为globaldata参数多种多样，中间的那些byte没有统一的规则。
在软体中，globaldata的index有如下的定义：
由上可知，globaldata数据多种多样，以最简单的6500K/5800K/9300K的色温值来举例，在上面的定义中，这三个色温值的index分别为10/11/12.
在flash的第一次初始化时，page13被分配用来存储globaldata，读page13的值，找到第一个byte为0x0a,0x0b,0x0c的资料，如下图所示：
与工厂菜单下的OSD看到的值完全一样，如下图所示：
Page13的最后一个byte为0x01，表示此page目前存储的data为globaldata。
ModeData与GlobalData数据量比较大，只能举例分析，基本的存储规则与上述相同，有时间有兴趣可以一个一个去分析。
此文件为Realtek提供flashreplaceeepromPPT文档，供参考。
升级会员 