CN103136015A - 控制Uboot进入下载操作模式的方法及系统 - Google Patents

Abstract

一种控制Uboot进入下载操作模式的方法及系统，该方法包括：构建一Booter以及一第一操作系统，该第一操作系统包括第一内核、第一文件系统以及用户App程序；构建一第二操作系统，其包括第二内核、第二文件系统以及一Loader，该第二内核能够将该Loader作为一个App程序进行加载；在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。本发明可以省去在Loader中实现相关驱动的必要，从而提高嵌入式产品的软件系统的开发效率。

Description

控制Uboot进入下载操作模式的方法及系统

技术领域

本发明涉及BootLoader的实现，尤其涉及对Uboot进入下载操作模式的控制。

背景技术

BootLoader是在操作系统内核运行起来之前运行的一段小程序，通过这段小程序，可初始化硬件设备、建立内存空间映射图，为操作系统启动提供基本的运行环境。在嵌入式系统中，整个软件系统的加载启动任务都是由BootLoader来完成的。BootLoader有很多种的实现方式，其中Uboot(universal Boot Loader)是一种开源的且能支持多种目标平台的bootLoader，目前广泛应用在嵌入式系统开发中。

以机顶盒为例， BootLoader也称为机顶盒下载器，主要用于对软件进行下载升级更新，可分为Booter（启动加载）和Loader（下载）两个模块。一般地，可将只运行Booter的状态称为Uboot的启动加载模式，而将运行Loader的状态称为Uboot的下载操作模式，因此，Uboot进入下载操作模式也就是指启动Loader。在Uboot中，Booter一般存储在OTP（一次性编程）区，在机顶盒上电时最先载入，负责系统的启动，并对Loader和应用软件的代码进行相关校验；Loader存储在写保护Flash区域（RO区域，只读区域），负责应用软件的下载升级操作，用来升级机顶盒软件且独立与应用软件的代码。

现有的控制Uboot进入下载操作模式的系统架构，参见图1，机顶盒的软件系统是只有一个Kernel（内核）和Rootfs（文件系统）及App（应用程序）的单操作系统结构，Booter和Loader放置在一起，并且是在Booter中直接启动Loader，以完成数据的下载升级功能。参见图2所示，Booter启动Loader的过程中不涉及到操作系统的运行，该过程的具体的流程大致包括：通电开机，运行启动Uboot（也就是运行Booter）后，CPU首先运行Loader，如果Loader被破坏，系统将无法启动；如Loader没有被破坏，则在Loader中检测是否有升级需求；如有升级要求，则直接启动升级功能，进行下载更新；否则的话，启动操作系统，执行有关App。

可见，现有的这种系统架构，在从Booter中引导启动Loader进行数据下载接收功能的过程中，操作系统并未启动。因此，在进行数据接收下载时所需的相关驱动（demux/demod/tuner），都需在Loader模块中得到实现。这就引发了一个问题：如果这些驱动较为复杂，则重新在Loader中实现势必会带来较大的工作量，从而影响到诸如机顶盒之类的嵌入式系统的软件系统的开发效率。

发明内容

本发明要解决的技术问题在于克服上述现有技术存在的不足，而提出一种控制Uboot进入下载操作模式的方法及系统，能够省去在Loader中实现相关驱动的必要，从而提高嵌入式产品的软件系统的开发效率。

本发明针对上述技术问题而提出的技术方案包括，提出一种控制Uboot进入下载操作模式的方法，包括构建一Booter以及一第一操作系统，该第一操作系统包括第一内核、第一文件系统以及用户App程序；还包括：构建一第二操作系统，其包括第二内核、第二文件系统以及一Loader，该第二内核能够将该Loader作为一个App程序进行加载；在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。

在启动该第一操作系统时，如果第一内核启动成功，则正常加载相应的第一文件系统和用户App程序；如果第一内核启动失败，则转为启动该第二操作系统，通过加载该Loader进行升级操作。

在该启动加载模块的启动bootm参数中，携带有该第一内核和第二内核的地址。

该Booter直接访问存储地址以检测一升级标识符。

在该Booter中设有一内核启动单元，该内核启动单元根据该升级标识符来选择性地启动第一内核或第二内核。

在该第一内核的配置文件中指定该第一文件系统的根地址；在该第二内核的配置文件中指定该第二文件系统的根地址。

在该第一文件系统的配置文件中挂载该用户App程序；在该第二文件系统的配置文件中挂载该Loader。

将该Booter和第二操作系统存储在写保护存储区域中。

选用Flash存储器，将该Booter、第一操作系统和第二操作系统存储在该Flash存储器的三个区域中。

本发明针对上述技术问题而提出的技术方案还包括，提出一种控制Uboot进入下载操作模式的系统，包括：一Booter以及一第一操作系统，该第一操作系统包括第一内核部分、第一文件系统部分以及用户App程序部分；其还包括：

一第二操作系统，其包括第二内核部分、第二文件系统部分以及一Loader，该第二内核部分能够将该Loader作为一个App程序进行加载；在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。

与现有技术相比，本发明的控制Uboot进入下载操作模式的方法及系统，通过构建双操作系统，能够在启动Loader之前先启动第二操作系统，以省去在Loader中实现相关驱动的必要，从而提高嵌入式产品的软件系统的开发效率。

附图说明

图1是现有的控制Uboot进入下载操作模式的系统的架构示意。

图2是现有的控制Uboot进入下载操作模式的方法的流程示意。

图3是本发明的控制Uboot进入下载操作模式的系统的架构示意。

图4是本发明的控制Uboot进入下载操作模式的系统的架构构建过程示意。

图5是本发明的控制Uboot进入下载操作模式的方法的流程示意。

图6是本发明的控制Uboot进入下载操作模式的方法及系统在机顶盒中具体应用的流程示意。

具体实施方式

以下结合附图，以机顶盒为例，对本发明予以进一步地详尽阐述。

本发明的控制Uboot进入下载操作模式的方法，包括：构建一Booter以及一第一操作系统，该第一操作系统包括第一内核、第一文件系统以及用户App程序；构建一第二操作系统，其包括第二内核、第二文件系统以及一Loader，该第二内核能够将该Loader作为一个App程序进行加载；在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。

本发明中，采用双操作系统，一个为App系统，另一个为Loader系统，从而可以把Loader当作一个单独的App应用程序，不用在Booter中引导启动Loader，而是在Loader系统启动完成后，再挂载运行Loader。具体而言，Booter在检测到Flash中存储有升级需求时，直接启动Loader系统的内核及文件系统，同时加载底层驱动，再挂载Loader程序，以实现数据的接收下载功能。

请参见图3，本发明的控制Uboot进入下载操作模式的系统的架构大致包括以下特征：在Flash存储器中分别保存两个操作系统（以下简称系统一和系统二），其中，系统一用于启动用户App，系统二用于启动Loader。Loader及相关的、系统二的Kernel与rootfs都存储在Flash存储器的RO区域中，防止因不当的操作，导致系统二无法启动。

Flash存储器划分为三个大的区域：启动代码区（uboot、config1），系统一（App相关信息存储区）以及系统二（Loader相关信息存储区）。启动代码区和系统二（Loader系统存储区）均设置RO区域中以实现写保护。

本发明，为实现双操作系统启动，需在现有的单操作系统的基础上添加及修改部分代码；让机顶盒的软件系统能根据升级标识符情况，启动不同的操作系统。

请参见图4，本发明的控制Uboot进入下载操作模式的系统的架构构建过程大致包括以下步骤。

S101：按图3的架构对Flash存储器进行分区；其中，对应的主要mtdblock分区情况为：mtdblock2为系统一的rootfs分区；mtdblock5为系统二的rootfs分区；mtdblock3为App的存储分区；mtdblock6为Loader的存储分区；mtdblock4为Loader升级信息存储分区。

S102：对Booter进行修改，使其可根据升级标识符启动不同的kernel，具体包括：S1021：在Booter的bootm中携带两个内核的启动地址，kernel1_addr（系统一的内核地址）和kernel2_addr（系统二的内核地址）；S1022：添加检测升级标识符程序 kf_get_sw_dl_params()，主要是通过访问Flash中指定偏移地址(图3中的config2分区地址)中的内容，检测是否存在升级标识符；S1022：添加启动kernel程序：当要求升级时，则启动kernel2_addr，否则启动kernel1_addr；如在启动kernel1_addr失败时，也转到启动kernel2_addr。

S103：在Kernel的配置文件中进行修改，不同的内核对应不同的根文件系统，具体包括：S1031：第一内核，对应配置为第一文件系统：root=/dev/mtdblock2(第一rootfs分区)；S1032：第二内核，对应配置为第二文件系统：root=/dev/mtdblock5(第二rootfs分区)。

S104：在Rootfs（文件系统）的配置文件中进行修改，挂载不同的应用程序，具体包括：S1041：第一文件系统，挂载用户App：mount -t jffs2 /dev/mtdblock3 /Appfs；S1042：第二文件系统，挂载Loader：mount -t jffs2 /dev/mtdblock6 /Appfs。

请参见图5，本发明的控制Uboot进入下载操作模式的方法的流程大致包括如下步骤。

S201：上电开机后，Uboot启动（相当于Booter进入工作状态）；bootm携带kernel1_addr和kernel2_addr两个地址。

S202：Uboot启动后，通过kf_get_sw_dl_params()读取Flash存储器中config2的内容；检测是否有升级要求，是的话，转步骤S203，否则转步骤S204。

S203：在Booter中引导启动kernel2及rootfs2；再在rootfs2中挂载Loader程序，进行下载更新操作。

S204：在Booter中引导启动Kernel1及rootfs1；如Kernel1启动成功，则引导加载用户App，如果Kernel1启动失败，则跳转步骤S203，启动kernel2及rootfs2和Loader程序。

请参见图6，本发明的控制Uboot进入下载操作模式的方法及系统在机顶盒具体应用的流程大致包括以下步骤。

S301：按照图3系统架构的要求，在mtdparts中定义9个Flash分区，具体有：mtdblock0对应uboot； mtdblock1对应kernel1； mtdblock2对应rootfs1；mtdblock3对应App；mtdblock4对应userdata；mtdblock5对应config2；mtdblock6对应kernel2；mtdblock7对应rootfs2；mtdblock8对应Loader；mtdblock9对应userdata。

S302：在Booter中不传递cmdline（命令行），保证从kernel中读取。

S303：按照图4的构建过程要求，对uboot/kernel/rootfs进行修改。

S304：编译代码(uboot、App系统和Loader系统)。

S305：根据uboot/kernel/rootfs/App/Loader在Flash存储器的分区地址，进行烧录。

S306：机顶盒上电，Uboot启动。

S307：读取校验mtdblock5中的相关升级参数。

S308：判断是否需要升级，是的话，转步骤S309，否则的话，转步骤S313。

S309：启动Loader。

S310：进行下载更新操作。

S311：更新mtdblock5中的参数；需要说明功能的是，mtdblock5中的相关升级参数的设置可通过步骤S314：Booter检测到升级需要,来实现的。

S312：机顶盒自动reboot（重启），跳转步骤S305。

S313：启动App。

与现有技术相比，本发明的控制Uboot进入下载操作模式的方法及系统，通过在Flash存储器中的不同存储空间，存放两个不同的完整操作系统。在启动Loader进行数据接收下载更新时，也同时启动一个完整操作系统，进行加载相关的底层驱动，使得在实现Loader的功能时，能直接采用操作系统已有的相关驱动，无须再在Loader中重新实现，从而可减少不必要的开发工作，简化开发过程，提高开发效率。

上述内容，仅为本发明的较佳实施例，并非用于限制本发明的实施方案，本领域普通技术人员根据本发明的主要构思和精神，可以十分方便地进行相应的变通或修改，故本发明的保护范围应以权利要求书所要求的保护范围为准。

Claims (10)

1.一种控制Uboot进入下载操作模式的方法，包括构建一Booter以及一第一操作系统，该第一操作系统包括第一内核、第一文件系统以及用户App程序；其特征在于，还包括：

构建一第二操作系统，其包括第二内核、第二文件系统以及一Loader，该第二内核能够将该Loader作为一个App程序进行加载；

在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。

2.依据权利要求1所述的方法，其特征在于，在启动该第一操作系统时，如果第一内核启动成功，则正常加载相应的第一文件系统和用户App程序；如果第一内核启动失败，则转为启动该第二操作系统，通过加载该Loader进行升级操作。

3.依据权利要求1所述的方法，其特征在于，在该启动加载模块的启动bootm参数中，携带有该第一内核和第二内核的地址。

4.依据权利要求1所述的方法，其特征在于，该Booter直接访问存储地址以检测一升级标识符。

5.依据权利要求1所述的方法，其特征在于，在该Booter中设有一内核启动单元，该内核启动单元根据该升级标识符来选择性地启动第一内核或第二内核。

6.依据权利要求1所述的方法，其特征在于，在该第一内核的配置文件中指定该第一文件系统的根地址；在该第二内核的配置文件中指定该第二文件系统的根地址。

7.依据权利要求1所述的方法，其特征在于，在该第一文件系统的配置文件中挂载该用户App程序；在该第二文件系统的配置文件中挂载该Loader。

8.依据权利要求1所述的方法，其特征在于，将该Booter和第二操作系统存储在写保护存储区域中。

9.依据权利要求1所述的方法，其特征在于，选用Flash存储器，将该Booter、第一操作系统和第二操作系统存储在该Flash存储器的三个区域中。

10.一种控制Uboot进入下载操作模式的系统，包括：一Booter以及一第一操作系统，该第一操作系统包括第一内核部分、第一文件系统部分以及用户App程序部分；其特征在于，还包括：

一第二操作系统，其包括第二内核部分、第二文件系统部分以及一Loader，该第二内核部分能够将该Loader作为一个App程序进行加载；

在开机后，该Booter判断是否有升级要求，如果有，启动该第二操作系统，通过加载该Loader进行升级操作；如果没有，启动该第一操作系统。

Images