著录项信息
专利名称 | 一种支持多flash设备的机顶盒软件升级方法 |
申请号 | CN201210058096.8 | 申请日期 | 2012-03-07 |
法律状态 | 授权 | 申报国家 | 中国 |
公开/公告日 | 2012-08-01 | 公开/公告号 | CN102622250A |
优先权 | 暂无 | 优先权号 | 暂无 |
主分类号 | G06F9/445 | IPC分类号 | G;0;6;F;9;/;4;4;5;;;H;0;4;N;2;1;/;4;5;8查看分类表>
|
申请人 | 四川长虹电器股份有限公司 | 申请人地址 | 四川省绵阳市高新区绵兴东路35号
变更
专利地址、主体等相关变化,请及时变更,防止失效 |
权利人 | 四川长虹电器股份有限公司 | 当前权利人 | 四川长虹电器股份有限公司 |
发明人 | 熊建勇;周志武;杨艳辉 |
代理机构 | 成都虹桥专利事务所(普通合伙) | 代理人 | 李顺德 |
摘要
本发明涉及数字电视机顶盒,其公开了一种支持多flash设备的机顶盒软件升级方法,在现有的条件接收系统升级规范下支持多flash设备升级,突破升级容量限制,且能实现灵活升级。其技术方案的要点可概括为:a.机顶盒开发商根据机顶盒使用的flash设备个数和各flash设备的使用区域构建配置文件;b.按照配置文件中的定义将针对机顶盒的flash设备的各分区的升级数据合并保存在一个升级文件中,形成合并后的升级文件,并提供给前端系统;c.前端系统将合并后的升级文件进行打包,生成升级数据流并下发;d.机顶盒接收升级数据流,根据配置文件中的定义还原针对机顶盒的flash设备的各分区的升级数据;e.对各分区的升级数据进行写入相应flash分区的处理。本发明适用于机顶盒生产商。
一种支持多flash设备的机顶盒软件升级方法\n技术领域\n[0001] 本发明涉及数字电视机顶,特别涉及一种支持多flash设备的机顶盒软件升级方法。\n背景技术\n[0002] 随着全球数字电视行业的迅猛发展,付费电视已经成为数字电视的主流,各种条件接收方案广泛的被世界各国的数字电视运营商们所采用。因此基于条件接收系统的机顶盒在市场上的使用也越来越多。然而目前在机顶盒上使用的各种应用软件通常都是基于linux系统的;linux系统本身比较庞大,需要占用的flash和内存资源较多,因此机顶盒使用的flash资源也越来越多;单个的flash设备或者容量较小的flash设备已经开始面临容量不足的情况。\n[0003] 因此,目前市面上出现支持多flash设备的机顶盒,以解决单flash容量不足的问题;然而目前大部分的条件接收系统对于机顶盒软件升级的规范仍然是针对单flash升级,且由机顶盒厂家提供的flash使用配置规范也未升级。而对于两种flash设备(即norflash和nandflash)来说,在使用方法有很大差别,因此传统的条件接收系统的升级规范在nandflash的使用中不可避免的出现的了一些问题:比如,传统的条件接收系统规定的升级方法即norflash是按flashblock依次顺序写入的,而nandflash的使用是按分区使用的,nandflash的坏块机制造成每个分区不可能被完全使用,要预留一部分来防止坏块产生,因此nandflash的写flash操作是跳跃的,因此在生成升级流时也需要考虑升级的内容是分段式的。另外传统的norflash容量都较小,市场上流行的较大的norflash容量通常都是64兆,而nandflash容量通常都是都达到了128兆,256兆,甚至更大,因此传统的norflash的升级数据容量是较小的,而与传统条件接收系统升级规范配套的系列打包工具支持的可升级容量也较小,无法支持nandflash的大容量。\n[0004] 由上可以看出传统条件接收系统升级规范主要针对的都是norflash,若使用nandflash,不管是在容量上,还是在规范上都不是非常的契合;如何在现有的条件接收系统升级规范的前提下支持多flash设备升级,突破升级容量限制,且能灵活升级(既支持norflsh升级又支持nandflash升级)是一个亟待解决的问题。\n发明内容\n[0005] 本发明所要解决的技术问题是:提出一种支持多flash设备的机顶盒软件升级方法,在现有的条件接收系统升级规范的前提下支持多flash设备升级,突破升级容量限制,且能实现灵活升级。\n[0006] 本发明解决上述技术问题所采用的技术方案是:一种支持多flash设备的机顶盒软件升级方法,包括以下步骤:\n[0007] a.机顶盒开发商根据机顶盒使用的flash设备个数和各flash设备的使用区域构建flash配置文件;\n[0008] b.机顶盒开发商按照flash配置文件中的定义将针对机顶盒的flash设备的各分区的升级数据合并保存在一个升级文件中,形成合并后的升级文件,并提供给前端系统;\n[0009] c.前端系统将合并后的升级文件进行打包,生成升级数据流并下发;\n[0010] d.机顶盒接收升级数据流,根据flash配置文件中的定义还原针对机顶盒的flash设备的各分区的升级数据;\n[0011] e.机顶盒根据相关信息对各分区的升级数据进行写入相应flash分区的处理。\n[0012] 进一步,该方法还包括步骤:\n[0013] f.机顶盒根据flash配置文件中的定义将flash设备的各分区的升级数据读取出来,并计算CRC校验值,写入到分区信息数据校验区内;\n[0014] g.机顶盒重启,再次根据flash配置文件中的定义将flash设备的各分区的升级数据读取出来,并计算CRC校验值,与分区信息数据校验区内存储的CRC校验值进行比较,如果相同,则升级成功,机顶盒正常启动;如果不相同,则升级失败,返回步骤a。\n[0015] 进一步,步骤a具体包括:\n[0016] a1.机顶盒开发商确定机顶盒使用的flash设备个数和各flash设备的使用区域;\n[0017] a2.机顶盒开发商根据flash设备个数和各flash设备的使用区域构建flash配置文件,并定义每个数据块具体属于哪个flash设备上的哪个使用区域,所述flash配置文件中定义了数据块的偏移地址和长度。\n[0018] 进一步,步骤b中,将针对机顶盒的flash设备的各分区的升级数据合并保存在一个升级文件,该合并后的升级文件包括n个升级文件描述头和n个文件数据;各分区的升级数据的合并规则为:文件1描述头+文件1数据+文件2描述头+文件2数据…文件n描述头+文件n数据,所述n对应flash配置文件里规定的各个flash设备的分区。\n[0019] 进一步,所述升级文件描述头包含以下字段:文件头描述字符串标志、文件头长度、文件属性值、flash设备号、flash设备属性值、升级文件偏移地址、数据段长度、数据段CRC校验值。\n[0020] 进一步,所述文件属性值标明该文件是否需要写入flash:当需要升级某个flash设备的某个分区时,那么就将针对该分区的升级文件的文件属性值设置为1,将其他不需要升级的分区的升级文件的文件属性值设置为0;当需要升级的分区对应的升级文件不在flash配置文件的规定里且需要写入flash时,则将针对该分区的升级文件的文件属性值设置为2。\n[0021] 进一步,步骤e中,机顶盒根据相关信息对各分区的升级数据进行写入相应flash分区的处理的具体方法是:机顶盒读取针对各分区的升级文件的文件属性值,若文件属性值为0,则该分区的升级文件不写入flash;若文件属性值为1,则根据flash配置文件里的规定,将该分区的升级文件写入到相应的flash设备的相应地址;若文件属性值为2,则根据该分区的升级文件的头信息定义的flash设备号和升级文件偏移地址来写入到flash设备的相应地址。\n[0022] 本发明的有益效果是:在现有的条件接收系统升级规范的前提下支持多flash设备升级,突破升级容量限制,既能支持norflsh升级又能支持nandflash升级,升级方式灵活。\n具体实施方式\n[0023] 传统技术中的机顶盒软件升级方式大多都只能支持norflsh单设备升级,升级容量受限,且不能支持nandflash升级;为了解决上述问题,本发明提出了一种支持多flash设备的机顶盒软件升级方法,包括以下步骤:\n[0024] a.机顶盒开发厂家根据机顶盒使用的flash设备个数和各flash设备的使用区域构建flash配置文件;\n[0025] b.机顶盒开发厂家按照flash配置文件中的定义将针对机顶盒的flash设备的各分区的升级数据合并保存在一个升级文件中,形成合并后的升级文件;\n[0026] c.前端系统将合并后的升级文件进行打包,生成升级数据流并下发;\n[0027] d.机顶盒接收升级数据流,根据flash配置文件中的定义还原针对机顶盒的flash设备的各分区的升级数据;\n[0028] e.机顶盒根据相关信息对各分区的升级数据进行写入相应flash分区的处理。\n[0029] 本发明的升级方法与传统技术的区别点在于:(1)在FLASH配置文件里关联了flash设备和分区及分区大小。(2)本方法的最终升级文件是由各个FLASH设备上的各分区文件合并而成的,且是按既定的格式来合成的,该格式包含了符合nandflash升级需要的特性;而传统的升级文件就一个升级文件;(3)本方法的最终升级文件生成方式涵盖了传统升级文件规范与工具无法支持到的升级区域。假如工具只支持升级64兆的数据,那么传统的升级方法只能前64M区域的数据,经过本方法后,可以把任何区域的数据组合到合并文件中,而只要最终的合并文件数据小于64M即可。这样就突破了flash设备和容量的限制。\n[0030] 下面结合具体实施方式对本发明的技术方案作详细阐述:\n[0031] A.机顶盒开发商根据机顶盒使用的flash设备个数和使用区域,构建flash配置文件:\n[0032] a1.确定一个项目的机顶盒固定使用的flash设备的个数;\n[0033] a2.确定每个flash设备的使用区域划分。如:flash0的第一兆区域存放loader,[0034] 第二兆到flash0设备的最后存放主程序;flash1的前20兆存放文件系统,第21兆到30兆存放数据库等;\n[0035] a3.前端系统根据a1,a2的划分,构成flash配置文件,且和机顶盒共同规定每个块的归属。由于条件接收系统的工具只针对一个flash,因此配置文件中的各个数据块的偏移地址是虚拟的,但它与实际的flash的物理地址有具体的对应关系,这就由机顶盒厂家来定义的。如第一个blcok的偏移地址为0x8000,长度0x18000,它对应的flash设备的\n1分区,第二个block偏移为0x2000,长度0x2000可以对应flash设备2的0分区等等。\n[0036] B.实现支持多flash设备的升级文件数据打包:\n[0037] b1.由于条件接收系统的升级流打包工具只支持打包一个升级文件,那么要支持多个flash设备的数据升级,就只有将所有的需要升级的数据按一定的格式封装成一个升级文件用于生成升级流。机顶盒在接收到升级数据后,再按此格式,进行逆向解析,还原出各个flash设备的升级数据,进行升级。\n[0038] b2.根据上述b1的思想,将每个flash设备上的升级数据合并为一个升级文件,合并后的升级文件包含n个升级文件描述头和N个文件数据,其中升级文件的合并规则为:文件1描述头+文件1数据+文件2描述头+文件2数据…文件n描述头+文件N数据,所述1、2……N对应flash配置文件里规定的各个flash设备的分区。上述升级文件描述头信息包含以下字段:文件头描述字符串标志、文件头长度、文件属性值、FLASH设备号、FLASH设备属性值、升级文件偏移地址、数据段长度、数据段CRC校验值;\n[0039] 基于上述,合并后的升级文件的具体结构如下:\n[0040] For(i=0;i<升级数据段个数;i++)\n[0041] {\n[0042] 文件头描述字符串标志;\n[0043] 文件头长度;\n[0044] 文件属性值;\n[0045] FLASH设备号;\n[0046] FLASH设备属性值;\n[0047] 升级文件偏移地址;\n[0048] 数据段长度;\n[0049] 数据段CRC校验值;\n[0050] 文件数据;\n[0051] }\n[0052] 其中文件头长度是指从文件头描述字符串标志开始,到数据段CRC校验值字段长度。文件属性值标明该文件是否需要写入flash:如:当某次升级只需要升级某个flash设备的某个分区,那么就将该分区的升级文件的文件属性值设置为1,其他不需要升级的分区的升级文件的文件属性值设置为0;当需要升级的升级数据所在的分区未在flash配置文件中定义,则将该分区的升级文件的文件属性值设置为2。(由于条件接收系统的升级规范及其工具有升级容量限制,因此根据其规范定义的flash配置文件的容量只是机顶盒FLASH容量的一部分。当需要升级的数据所在的分区未在flash配置文件中定义,那么则将该分区的升级文件的文件属性值设置为2。)\n[0053] b3.按照上述思想对针对各个flash设备的升级数据进行处理:\n[0054] b3.1根据flash配置文件的规定,依次将flash配置文件里包含flash设备上的分区的升级数据,按先根据b2定义的结构,逐个保存到一个升级文件里。直到最后一个需要真正升级的数据被添加。如:flash0设备上有5个分区,我们只想升级第三个分区,那么合并文件就只需要添加前三个分区。后面的两个分区及其他flash设备上的分区均不需要添加。\n[0055] b3.2当某次升级只需要升级某个flash设备的某个分区,那么就将该分区的升级文件的文件属性值设置为1,并且该文件数据使用真实的升级数据。其他不需要升级的分区的升级文件的文件属性值设置为0,且升级数据使用0xff填充。当我们需要升级的数据分区不在flash配置文件的规定里(即超过条件接收系统定义的最大可升级范围),那么我们就在flash配置文件定义的分区里,选择一个分区大小匹配,且本次不需要升级的分区来存放该超出支持范围分区的升级数据,并将文件属性值设置为2。如b3.1里的示例,分区1和2需要将文件属性值设置为0,其数据直接添加0xff.若要升级超过64M后的分区数据,
法律信息
- 2015-01-21
- 2012-09-26
实质审查的生效
IPC(主分类): G06F 9/445
专利申请号: 201210058096.8
申请日: 2012.03.07
- 2012-08-01
引用专利(该专利引用了哪些专利)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 |
1
| |
2006-07-05
|
2005-03-04
| | |
2
| |
2009-09-02
|
2008-12-17
| | |
3
| |
2011-12-28
|
2011-09-08
| | |
被引用专利(该专利被哪些专利引用)
序号 | 公开(公告)号 | 公开(公告)日 | 申请日 | 专利名称 | 申请人 | 该专利没有被任何外部专利所引用! |