Linux系统启动的方法、装置、设备及存储介质

技术领域

本申请属于计算机技术领域，尤其涉及一种Linux系统启动的方法、装置、设备及计算机存储介质。

背景技术

通常，在嵌入式Linux系统中，多使用引导程序来引导Linux内核启动，并利用存储介质存放系统镜像。

但是，设备长时间运行过程中，会存在频繁读写以及一些其他异常操作，都可能对存储介质的分区造成损坏，进而影响Linux系统启动的稳定性。

发明内容

本申请实施例提供一种Linux系统启动的方法、装置、设备及计算机存储介质，能够根据启动标识信息，从设备的不同存储介质的不同分区启动Linux系统，提升了Linux系统启动的稳定性和可靠性。

第一方面，本申请实施例提供一种Linux系统启动方法，应用于设备，所述设备包括第一存储介质和第二存储介质，所述第一存储介质包括第一分区，方法包括：

获取第一存储介质的第一分区的引导程序；

根据所述引导程序确定启动标识信息；

根据所述启动标识信息确定启动Linux系统的目标分区，并在所述目标分区启动所述Linux系统，所述目标分区为所述第一存储介质的分区，或者所述第二存储介质的分区。

可选地，所述启动标识信息包括启动次数标识和存储介质分区标识，所述第二存储介质包括第一分区；所述根据所述启动标识信息确定启动Linux系统的目标分区，包括：

当所述启动次数标识和所述存储介质分区标识均为第一预设标识时，确定启动Linux系统的目标分区为第二存储介质的第一分区。

可选地，所述第二存储介质还包括第二分区；所述根据所述启动标识信息确定启动Linux系统的目标分区，还包括：

当所述启动次数标识是第一预设标识，并且所述存储介质分区标识是第二预设标识时，确定启动Linux系统的目标分区为第二存储介质的第二分区。

可选地，所述第一存储介质还包括第二分区；所述根据所述启动标识信息确定启动Linux系统的目标分区，包括：

当所述启动次数标识为第二预设标识，并且所述存储介质分区标识为第三预设标识时，确定启动Linux系统的目标分区为第一存储介质的第二分区。

可选地，所述方法，还包括：

当所述启动次数标识为第四预设标识时，并且所述系统的计时器超过预设时间阈值时，复位所述Linux系统。

可选地，所述在所述目标分区启动所述Linux系统，包括：

根据所述引导程序，读取目标分区中的第一启动程序；

根据所述第一启动程序，启动所述Linux系统。

可选地，所述第一启动程序包括：内核启动程序和应用软件启动程序；根据所述第一启动程序，启动所述Linux系统，包括：

根据所述内核启动程序，启动所述Linux系统的内核；

根据所述应用软件启动程序，启动所述Linux系统的应用软件。

可选地，所述根据所述第一启动程序，启动所述Linux系统，包括：

当启动所述Linux系统成功时，将启动成功信息发送至云服务器；

当启动所述Linux系统失败，并且所述系统的计时器超过预设时间阈值时，复位所述Linux系统。

可选地，在所述目标分区启动所述Linux系统之后，还包括：

接收云服务器发送的升级数据包；

根据所述升级数据包，替换第二存储介质中的第一启动程序，得到第二启动程序；

将启动次数标识设置为第一预设标识，以及将存储介质分区标识设置为所述第二预设标识，并复位所述Linux系统；

根据所述启动次数标识和存储介质分区标识，读取所述第二存储介质的第二分区中的第二启动程序；

根据所述第二存储介质的第二分区中的第二启动程序，启动所述Linux系统；

将所述启动次数标识和所述存储介质分区标识设置为第一预设标识，并复位所述Linux系统；

根据所述启动次数标识和存储介质分区标识，读取所述第二存储介质的第一分区中的第二启动程序；

根据所述第二存储介质的第一分区中第二启动程序，启动所述Linux系统，并确定升级标识；

发送所述升级标识至所述云服务器。

可选地，所述接收所述云服务器发送的升级数据包，包括：

保存所述升级数据包至所述Linux系统的所述第二存储介质的第二分区；

当所述升级数据包中的下载校验码满足预设值时，向所述云服务器发送下载成功信息，并检测所述升级数据包。

可选地，在所述目标分区启动所述Linux系统之后，还包括：

接收云服务器发送的版本回退信息；

根据所述版本回退信息，确定所述第二存储介质中与所述版本回退信息对应的第三启动程序

根据所述第三启动程序替换所述第二存储介质中的第一启动程序，并确定版本回退标识；

重启所述Linux系统；

发送所述版本回退标识至所述云服务器。

可选地，所述版本回退信息包括内核版本信息和/或应用软件版本信

第二方面，本申请实施例提供了一种Linux系统启动的装置，应用于设备，所述设备包括第一存储介质和第二存储介质，所述第一存储介质包括第一分区；装置包括：

获取模块，用于获取第一存储介质的第一分区的引导程序；

确定模块，用于根据所述引导程序确定启动标识信息；

确定模块，还用于根据所述启动标识信息确定启动Linux系统的目标分区，以及；

启动模块，用于在所述目标分区启动所述Linux系统，所述目标分区为所述第一存储介质的分区，或者所述第二存储介质的分区。

第三方面，本申请实施例提供了基于Linux系统的设备，设备包括：第一存储介质、第二存储介质、内存单元以及处理器，所述第一存储介质、所述第二存储介质、所述内存单元以及处理器之间通过总线连接；

所述第一存储介质用于保存引导程序和第一启动程序；

所述第二存储介质用于保存所述第一启动程序；

所述处理器用于根据所述引导程序，获取所述内存单元中的启动标识信息；根据所述启动标识信息确定启动Linux系统的目标分区，并在所述目标分区启动所述Linux系统。

可选地，所述第一存储介质包括第一分区和第二分区；

所述第一存储介质的第一分区用于保存所述引导程序；

所述第一存储介质的第二分区用于保存所述第一启动程序。

可选地，所述第二存储介质包括第一分区和第二分区；

所述第二存储介质的第一分区和第二分区用于分别保存所述第一启动程序。

可选地，所述第一存储介质包括NOR Flash存储器。

可选地，所述第一存储介质包括NAND Flash、eMMC和SD中的任一种存储器。

可选地，所述内存单元为DDR内存芯片。

第四方面，本申请实施例提供了一种电子设备，所述设备包括：处理器、以及存储有计算机程序指令的存储器，所述存储器包括第一存储介质和第二存储介质；

所述处理器执行所述计算机程序指令时实现如第一方面以及第一方面可选的所述的Linux系统启动的方法。

第五方面，本申请实施例提供了一种计算机存储介质，计算机存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如第一方面以及第一方面可选的所述的Linux系统启动的方法。

本申请实施例的Linux系统启动的方法、装置、设备及计算机存储介质，能够获取第一存储介质的第一分区的引导程序，通过引导程序确定启动标识信息。然后，根据启动标识信息确定启动Linux系统的目标分区，在目标分区启动Linux系统。设备中包括了两种存储介质，目标分区可以是两种存储介质中的分区。基于此，可以根据启动标识信息，从设备的不同存储介质的不同分区启动Linux系统，为系统启动提供多种途径。当一个途径启动失败时，还可以从其他途径实现系统启动，由此，提升了Linux系统启动的稳定性和可靠性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一些实施例提供的Linux系统启动的设备的示意图；

图2是本申请一些实施例提供的Linux系统启动的方法的流程示意图；

图3是本申请一些实施例提供的实际应用的Linux系统启动的方法的流程示意图；

图4是本申请一些实施例提供的Linux系统启动的方法的流程示意图；

图5是本申请另一些实施例提供的Linux系统启动的方法的流程示意图；

图6是本申请另一些实施例提供的Linux系统启动的方法的流程示意图；

图7是本申请另一些实施例提供的Linux系统启动方法的流程示意图；

图8是本申请另一些实施例提供的Linux系统升级的流程示意图；

图9是本申请另一些实施例提供的嵌入式Linux设备与云服务器交互的流程示意图；

图10是本申请另一些实施例提供的Linux系统版本回退的流程示意图；

图11是本申请一些实施例提供的Linux系统启动的装置的结构示意图；

图12是本申请一些实施例提供的一种电子设备的硬件结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Linux系统由于其开源、移植方便、驱动资源丰富等特点被广泛应用于嵌入式设备中。在嵌入式Linux系统中，多使用Uboot作为引导程序来引导Linux内核启动，采用存储介质存放系统镜像。嵌入式设备长时间运行过程中，若采用单一存储介质，多次启动和频繁读写以及一些其他异常操作，都可能对存储介质的分区造成损坏，从而造成Linux系统无法正常启动。

针对运行嵌入式Linux系统的设备，如何提升其启动过程的可靠性以是本领域技术人员亟待解决的问题。

为了解决现有技术问题，本申请实施例提供了一种Linux系统启动的方法、装置、设备及计算机存储介质，能够根据启动标识信息，从设备的不同存储介质的不同分区启动Linux系统，提升了Linux系统启动的稳定性和可靠性。

下面结合附图，描述根据本申请实施例提供的Linux系统启动的方法、装置、设备及计算机存储介质。应注意，这些实施例并不是用来限制本申请公开的范围。

下面首先对本申请实施例所提供的基于Linux系统的设备进行介绍。

图1是本申请一些实施例提供的基于Linux系统的设备的示意图。如图1所示，运行嵌入式Linux系统的设备可以包括第一存储介质和第二存储介质，第一存储介质可以包括第一分区和第二分区，并且第二存储介质可以包括第一分区和第二分区。

图2是本申请一些实施例提供的Linux系统启动的方法的流程示意图。如图2所示的Linux系统启动的方法的执行主体可以为图1所示的设备，该Linux系统启动的方法，可以实施为如下步骤：

S201：获取第一存储介质的第一分区的引导程序。

运行嵌入式Linux系统的设备可以包括第一存储介质和第二存储介质。第一存储介质包括第一分区。该第一存储介质的第一分区可以用于保存用于引导系统启动的引导程序的镜像。示例性的，该引导程序可以为Uboot引导程序。

在本申请一些实施例中，第一存储介质还可以包括第二分区。该第一存储介质的第二分区可以用于保存第一启动程序。第一启动程序可以用于启动Linux系统的启动程序。第一启动程序可以包括内核启动程序和应用软件启动程序。

在本申请一些实施例中，该第一存储介质的第二分区保存了FIT镜像，FIT镜像可以由内核、设备树和RamDisk虚拟文件系统制作而成。RamDisk虚拟文件系统中包括了系统的应用软件启动程序。

在本申请一些实施例中，第二存储介质也可以包括第一分区和第二分区。该第二存储介质的第一分区和第二分区均可以用于保存第一启动程序。这里，第二存储介质的第一分区可以为主分区，第二存储介质的第二分区可以为备份分区。两个分区保存有相同的启动程序。

在本申请一些实施例中，第二存储介质的第一分区可以用于保存根文件系统镜像，其中根文件系统中的/boot文件夹下存放了内核镜像和设备树文件，根文件系统中的/home/root文件夹下应用软件启动程序。第二存储介质的第二分区可以用于保存备份根文件系统镜像。

在本申请一些实施例中，第一存储介质可以是非易失闪存(NOR Flash)。

在本申请一些实施例中，第二存储介质可以是NAND Flash、eMMC或者SD存储器。

S202：根据引导程序确定启动标识信息。

在设备中固化有第一级引导程序，第一级引导程序可以选择从第一存储介质启动。具体地，第一级引导程序从第一存储介质拷贝引导程序镜像，例如Uboot引导程序镜像至DDR内存单元中执行，获取DDR内存单元中的启动标识信息。

S203：根据启动标识信息确定启动Linux系统的目标分区。

在本申请一些实施例中，启动标识信息可以包括启动次数标识和存储介质分区标识。

在本申请一些实施例中，目标分区可以为第一存储介质的分区，或者第二存储介质的分区中的一个。

在本申请一些实施例中，当启动次数标识和存储介质分区标识均为第一预设标识时，确定启动Linux系统的目标分区为第二存储介质的第一分区。

当启动次数标识是第一预设标识，并且存储介质分区标识是第二预设标识时，确定启动Linux系统的目标分区为第二存储介质的第二分区。

当启动次数标识为第二预设标识，并且存储介质分区标识为第三预设标识时，确定启动Linux系统的目标分区为第一存储介质的第二分区。

在本申请一些实施例中，第一预设标识可以为0，第二预设标识可以为1，第三预设标识可以非0。

此外，在本申请一些实施例中，当启动次数标识为第四预设标识时，并且所述系统的计时器超过预设时间阈值时，复位Linux系统，即重新执行启动Linux系统的操作。

示例性的，该第四预设标识可以为非0非1。

S204：在目标分区启动Linux系统。

在本申请一些实施例中，根据引导程序，可以读取目标分区中的第一启动程序；根据第一启动程序，启动Linux系统。

首先，根据所述内核启动程序，可以启动Linux系统的内核。然后，根据应用软件启动程序，启动Linux系统的应用软件。

当启动Linux系统成功时，将启动成功信息发送至云服务器；

当启动Linux系统失败，并且系统的计时器超过预设时间阈值时，复位Linux系统，即可以重新执行S201至S204的操作，直至成功启动Linux系统。

综上所述，在本申请实施例中，该Linux系统启动的方法，能够获取第一存储介质的第一分区的引导程序，通过引导程序确定启动标识信息。然后，根据启动标识信息确定启动Linux系统的目标分区，在目标分区启动Linux系统。设备中包括了两种存储介质，目标分区可以是两种存储介质中的分区。基于此，可以根据启动标识信息，从设备的不同存储介质的不同分区启动Linux系统，为系统启动提供多种途径。当一个途径启动失败时，还可以从其他途径实现系统启动，由此，提升了Linux系统启动的稳定性和可靠性。

为了更好地理解本申请的Linux系统启动的方法，现结合实际应用的实例对本申请的Linux系统启动的方法进行详细的说明。

图3是本申请一些实施例提供的实际应用场景中的Linux系统启动的方法的流程示意图。

S301：设备上电启动。

S302：一级引导程序从第一存储介质的第一分区启动，执行Uboot引导程序。

示例性的，第一存储介质可以为NOR Flash存储器。引导程序为可以为Uboot引导程序。

S303：Uboot引导程序获取DDR内存中的启动标识信息。

设备上电后，首先，可以利用运行设备厂商固化在ROM中的一级引导程序选择从NOR Flash启动。一级引导程序从NOR Flash拷贝Uboot引导程序镜像至DDR内存中执行。

Uboot引导程序可以用于引导启动Linux系统内核等。Uboot启动时会调用bootcmd命令，然后根据环境变量的配置来选择从哪个存储介质的分区加载启动Linux内核和挂载文件系统。

在DDR的高端内存地址中保存了启动标识信息。启动标识信息包括启动次数标识和存储介质分区标识。Uboot中有读写内存的操作命令md和mw，但在环境变量中无法获取这两个命令的返回值，进而无法完成高端内存中启动标识信息判断。这里，可以在Uboot中添加自定义命令用于高端内存读操作并判断数值返回。由此，Uboot可以读取DDR高端内存地址中的判断启动标识信息。

在本申请一些实施例中，Linux系统设备的处理器中还可以包括计时器。示例性的，该计时器可以是看门狗。Uboot启动过程中，还可以使能看门狗功能。看门狗是一个可以在一定时间内被复位的计数器。当看门狗启动后，计数器开始自动计数，当达到预定时间时，处理器可以将这个计数器复位。计数器复位的操作称为“喂狗”。如果计数器没有被复位，计数器溢出就会对处理器产生一个复位信号使系统重启。在Uboot成功引导Linux内核启动后会关闭看门狗。

S304：根据启动标识信息确定启动Linux系统的目标分区，并在目标分区启动Linux系统。

在本申请一些实施例中，启动标识信息的启动次数标识和存储介质分区标识可以用于判断从哪个存储介质的分区加载启动Linux内核。通过对启动标识信息的判断，可以通过不同的目标分区启动Linux系统。

在本申请一些实施例中，启动次数标识可以对应于第一预设标识，第二预设标识，第三预设标识以及第四预设标识中的任一种。存储介质分区标识可以对应于第一预设标识，第二预设标识，第三预设标识以及第四预设标识中的任一种。

在本申请一些实施例中，第一预设标识可以为0，第二预设标识可以为1，第三预设标识可以为非0，第四预设标识可以为非0非1。

目标分区包括第一存储介质的第二分区以及第二存储介质的第一分区和第二分区。示例性的，第一存储介质可以是NOR Flash，第二存储介质的第一分区可以是eMMC的主分区，第二存储介质的第二分区可以是eMMC的备份分区。

在本申请一些实施例中，图3中的S304可以通过图4中的S401至S407来实现，如图4所示：

S401：判断启动次数标识是否为0。

S402：判断存储介质分区标识是否为0。

首先，可以先判断启动次数标识是否为0。

当启动次数标识是0，再判断存储介质分区标识是否为0。

为了便于执行启动程序，在确定启动次数标识是0后，可以将该启动次数标识设置为1。

S403：从第二存储介质的第一分区启动Linux内核。

当启动次数标识和存储介质分区标识均为0时，从第二存储介质的第一分区启动Linux内核。

S404：判断启动内核是否成功。

S405：挂载第二存储介质的第一分区文件系统，启动应用软件。

当从第二存储介质的第一分区启动Linux内核成功时，挂载第二存储介质的第一分区文件系统，启动应用软件。

在本申请一些实施例中，因为，在内核启动成功后看门狗会被关闭，在启动应用软件时，还可以包括再次使能看门狗。

此外，为了实现软件复位重启后Linux系统也可以从第二存储介质的第一分区启动，还可以将该启动次数标识设置为0。

在本申请一些实施例中，当从第二存储介质的第一分区启动Linux内核失败时，还可以继续判断看门狗是否超时。当从第二存储介质的第一分区启动Linux内核失败，并且看门狗超时时，复位系统，返回执行S302。

S406：判断启动应用软件是否成功。

S407：向云服务器上报工作状态。

当从第二存储介质的第一分区启动应用软件成功时，向云服务器上报工作状态。

在本申请一些实施例中，通过应用软件可以与云服务器进行交互，上报工作状态。工作状态可以包括系统在哪个存储介质的哪个分区启动成功等系信息。这里，可以向云服务器发送系统在第二存储介质的第一分区启动成功。

在本申请一些实施例中，当从第二存储介质的第一分区启动应用软件失败时，还可以继续判断看门狗是否超时。当从第二存储介质的第一分区启动应用软件失败，并且看门狗超时时，复位系统，返回执行S302。

在本申请一些实施例中，由于是软件复位没有掉电，保存在DDR中启动标识信息并没有丢失，系统再次启动后，Uboot引导程序可以根据启动标识信息进行判断，可以切换至第二存储介质的第二分区启动Linux系统，或者切换至第一存储介质的第二分区启动Linux系统。可以理解的是，Uboot引导程序可以根据启动标识信息进行判断，尝试可以启动该Linux系统的目标分区。

在本申请一些实施例中，如图5所示，图5是本申请另一些实施例提供的Linux系统启动的方法的流程示意图。在执行S402时，当存储介质分区标识不是0时，该方法还包括如下步骤：

S501：从第二存储介质的第二分区启动Linux内核。

当启动次数标识是0，并且存储介质分区标识为1时，从第二存储介质的第二分区启动Linux内核。

在本申请一些实施例中，示例性的，当启动次数标识是0，判断存储介质分区标识是否为0；当存储介质分区标识不是0时，还可以判断存储介质分区标识是否为1。存储介质分区标识为1时，可以从第二存储介质的第二分区启动Linux内核。

S502：判断启动内核是否成功。

S503：挂载第二存储介质的第二分区文件系统，启动应用软件。

当从第二存储介质的第二分区启动Linux内核成功时，挂载第二存储介质的第二分区文件系统，启动应用软件。

当从第二存储介质的第二分区启动Linux内核失败，并且看门狗超时时，复位系统，返回执行S302。

S504：判断启动应用软件是否成功。

S505：向云服务器上报工作状态。

当从第二存储介质的第二分区启动应用软件成功时，向云服务器上报工作状态。

在本申请一些实施例中，通过应用软件可以与云服务器进行交互，上报工作状态。这里，可以向云服务器发送系统在第二存储介质的第二分区启动成功。当从第二存储介质的第二分区启动应用软件失败，并且看门狗超时时，复位系统，返回执行S302。

在本申请一些实施例中，从第二存储介质的第二分区启动Linux系统失败后，Uboot引导程序可以根据启动标识信息进行判断，接着从第一存储介质的第二分区启动Linux系统。

在本申请一些实施例中，如图6所示，图6是本申请另一些实施例提供的Linux系统启动的方法的流程示意图。在执行如图4所示的S401时，当启动次数标识不是0时，该方法还包括如下步骤：

S601：判断启动次数标识是否为1。

S602：判断存储介质分区标识是否为0。

当启动次数标识为1时，判断存储介质分区标识是否为0，可以是确定存储介质分区标识是否为非0。这样，当启动次数标识为1，并且存储介质分区标识为非0时，确定从第一存储介质的第二分区启动Linux系统。在本申请一些实施例中，为了便于执行启动程序以及区分存储介质的分区，在确定启动次数标识为0，并且存储介质分区标识为非0后，可以通过Uboot引导程序将存储介质分区标识设置为2。

此外，在在本申请一些实施例中，当存储介质分区标识是0时，可以通过Uboot引导程序将存储介质分区标识设置为1。同时，可以通过Uboot引导程序将启动次数标识设置为1，可以将目标分区切换为第二存储介质的第二分区，并在启动第二存储介质的第二分区该Linux系统。

S603：从第一存储介质的第二分区启动Linux内核。

S604：从第一存储介质的第二分区挂载ramdisk文件系统，启动应用软件。

S605：向云服务器上报工作状态。

当在第一存储介质的第二分区启动Linux内核和应用软件都成功时，向云服务器上报工作状态。

在本申请一些实施例中，通过应用软件可以与云服务器进行交互，上报工作状态。这里，可以向云服务器发送系统在第一存储介质的第二分区启动成功。

在本申请一些实施例中，在第一存储介质的第二分区启动为非正常分区启动。云服务器接收到该工作状态后，可以向运维系统发送告警信息，以便于运维人员及时维护的问题设备。

在本申请一些实施例中，在根据启动标识信息确定启动Linux系统的目标分区时，还可能存在如图7所示的情况，图7是本申请另一些实施例提供的Linux系统启动方法的流程示意图。在执行如图6所示S601时，当启动次数标识不是1时，该方法还包括如下步骤：

S701：Uboot引导系统启动失败，判断看门狗是否超时。

经过S401和S601的判断，当启动次数标识为非0非1，即启动次数标识为第四预设标识时，Uboot引导系统启动失败，判断看门狗是否超时。

S702：当看门狗是否超时，复位Linux系统，返回执行S302。

综上，在本申请实施例中，基于上述Linux系统启动的方法，在设备上电启动过程中，通过Uboot引导程序结合启动标识信息判断和看门狗功能，若出现任意一个存储介质分区启动失败，便可实现存储介质分区的自动切换，从而保证Linux系统最终能够成功启动。由此，可以提升Linux系统启动稳定性。

为了优化上述实施例中的嵌入式Linux设备的Linux系统升级，在本申请实施例中，在启动Linux系统之后，还包括对该系统的升级操作。如图8所示，图8是本申请另一些实施例提供的Linux系统升级的流程示意图。

S801：接收云服务器发送的升级数据包。

在本申请一些实施例中，具体过程可参见图9，图9是本申请另一些实施例提供的嵌入式Linux设备与云服务器交互的流程示意图。在图9中，嵌入式Linux设备作为下位机，与云服务器的可以进行升级交互。其中，嵌入式Linux设备的数量可以是多个，图9中仅示意性的画出一个Linux设备。

当有Linux固件或应用程序需要替换和升级时，云服务器向下位机设备下发升级指令，下位机响应升级指令并向云服务器获取升级包下载地址。云服务器下发升级包下载地址，下位机下载升级包后向云服务器上报下载结果。若下载成功则进行升级，并向云服务器上报下载结果。

在本申请一些实施例中，嵌入式Linux设备接收到升级数据包，首先，可以保存升级数据包至Linux系统的第二存储介质的第二分区。示例性的，可以将升级数据包保存至home/root/OrigBack路径下。

可以理解的是，因为第二存储介质的第一分区和第二分区可以是保存相同的数据。所以，也可以将升级数据包第二存储介质的第一分区。示例性的，可以将升级数据包第二存储介质的第一分区的备份区域。

然后，判断该升级数据包是否下载成功。当升级数据包中的下载校验码满足预设值时，向云服务器发送下载成功信息，并检测升级数据包。示例性的，下载校验码可以为MD5校验。

当升级数据包中的下载校验码不满足预设值时，向云服务器发送下载失败信息，并退出升级进程。

在本申请一些实施例中，检测升级数据包具体包括检验升级数据包中是否具有升级程序包。

当升级数据包中有升级程序包时，继续执行S802。

当升级数据包中没有升级程序包时，生成升级标识，该升级标识可以为升级失败标识。发送升级失败信息至云服务器，并清理升级失败标识以及升级数据包，退出升级进程。

S802：根据升级数据包，替换第二存储介质中的第一启动程序，得到第二启动程序。

在本申请一些实施例中，首先，可以解压升级数据包。若升级数据包中有应用软件升级包，则根据该应用软件升级包分别替换第二存储介质的第一分区和第二分区的中的/home/root/app；若有Linux内核升级包，则根据该Linux内核升级包分别替换第二存储介质的第一分区和第二分区中的/boot。

具体地，第二存储介质的第一分区和第二分区的根文件系统下的/home/root文件夹下存放了应用软件，替换该目录下的文件可以实现应用软件版本升级。第二存储介质的第一分区和第二分区的根文件系统下的/boot文件夹下存放了内核镜像和设备树文件，替换该目录下的文件可以实现内核驱动版本升级。

这里，第二启动程序可以是升级数据包中的启动程序。

S803：将启动次数标识设置为第一预设标识，以及将存储介质分区标识设置为第二预设标识，并复位Linux系统。

S804：根据启动次数标识和存储介质分区标识，读取第二存储介质的第二分区中的第二启动程序。

在本申请一些实施例中，在第二存储介质的第二分区重启系统时，可以生成并保存升级进行中标识，用于标识现在系统正在升级。将存储介质分区标识设置为第二预设标识，即1，以使设备从第二存储介质的第二分区启动Linux系统。

这里，复位Linux系统可以为系统主动复位。

S805：根据第二存储介质的第二分区中的第二启动程序，启动Linux系统。

这里，第二存储介质的第二分区为备份分区，即在第二存储介质的备份分区启动Linux系统。

S806：将启动次数标识和存储介质分区标识设置为第一预设标识，并复位Linux系统。

这里，将启动次数标识和存储介质分区标识设置为第一预设标识，即设置为0。

S807：根据启动次数标识和存储介质分区标识，读取第二存储介质的第一分区中的第二启动程序。

S808：根据第二存储介质的第一分区中的第二启动程序，启动Linux系统，并确定升级标识。

这里，第二存储介质的第一分区为主分区，即在第二存储介质的主分区启动Linux系统。在启动之前，可以检测在第二存储介质的第二分区，即在备份分区启动的该Linux系统运行是否正常。当Linux系统运行正常时，在第二存储介质的第一分区，即在主分区再次启动该Linux系统。

当启动Linux系统成功时，升级标识为升级成功标识；当启动Linux系统失败时，升级标识为升级失败标识。

S809：发送升级标识至云服务器。

在本申请一些实施例中，升级标识可以为升级成功标识或者升级失败标识。发送升级标识至云服务器后，可以清理升级标识以及升级数据包。

综上，在本申请实施例提供的Linux系统启动方法，在启动之后，还包括了基于应用该方法的设备和云服务器的交互，实现对Linux系统的升级。云服务器可实现对在线的嵌入式Linux设备进行远程批量升级，并查看设备升级状态。与相关技术中，通过对每台设备烧写新的软件以实现版本更新的方法相比，本申请实施例的方法更加高效，以及易于执行。

在本申请一些实施例中，在目标分区启动Linux系统之后，该方法还包括根据云服务器的版本回退指令，执行版本回退操作。如图10所示，图10是本申请另一些实施例提供的Linux系统版本回退的流程示意图。该方法可以具体实施为如下步骤：

S1001：接收云服务器发送的版本回退信息。

接收到云服务器发送的版本回退信息时，可以先将当前运行的应用软件停止。

在本申请一些实施例中，版本回退信息包括内核版本信息和/或应用软件版本信息。

根据接收的版本回退信息，可以先判断是回退Linux内核版本，或者是回退应用软件版本，或者是回退Linux内核版本和应用软件版本。

S1002：根据版本回退信息，确定第二存储介质中与版本回退信息对应的第三启动程序。

第三启动程序是第二存储介质中备份的旧版本的启动程序。根据版本回退信息中的版本号等信息，可以找到对应版本的启动程序。

S1003：根据第三启动程序替换第二存储介质中的第一启动程序，并确定版本回退标识。

第一启动程序可以是指当前正在使用的版本的启动程序。

在执行程序替换的过程中，可以生成一个版本回退标识。版本回退标识用于标识版本回退的状态。版本回退标识可以包括版本回退执行中标识，版本回退成功标识，以及版本回退失败标识。

S1004：重启Linux系统。

S1005：发送版本回退标识至云服务器。

重启Linux系统，并判断版本回退是否成功。具体地，可以根据系统的软件版本号来判断版本回退是否成功。然后，将版本回退成功标识或者版本回退失败标识发送至云服务器。

发送版本回退标识至云服务器之后，还可以删除之前作为备份程序的第三启动程序。

综上，本申请实施例提供的Linux系统启动的方法，在作为下位机的Linux设备接收到云平台下发的软件版本回退指令后，会先停止运行应用软件。根据回退指令获取要回退的版本类型(Linux内核版本或应用软件版本)对应的备份程序，解压备份程序覆盖当前程序。然后保存版本回退标志，复位并重新启动Linux内核和/或应用软件。根据软件版本号判断回退是否成功，最后上报云平台版本回退结果。由此，便于实现Linux启动系统的版本回退，可以优化对嵌入式Linux设备的启动系统的管理。

基于上述实施例提供的Linux系统启动的方法，相应地，本申请还提供了Linux系统启动的装置的具体实现方式。请参见以下实施例。

图11是本申请一些实施例提供的Linux系统启动的装置的结构示意图。该Linux系统启动的装置，应用于设备，设备包括第一存储介质和第二存储介质，第一存储介质包括第一分区；装置包括：

获取模块1101，用于获取第一存储介质的第一分区的引导程序；

确定模块1102，用于根据所述引导程序确定启动标识信息。

确定模块1102，还用于根据所述启动标识信息确定启动Linux系统的目标分区。

启动模块1104，用于在所述目标分区启动所述Linux系统，所述目标分区为所述第一存储介质的分区，或者所述第二存储介质的分区。

综上，本申请实施例中的Linux系统启动的装置可以用于执行上述实施例中的Linux系统启动的方法，该方法能够获取第一存储介质的第一分区的引导程序，通过引导程序确定启动标识信息。然后，根据启动标识信息确定启动Linux系统的目标分区，在目标分区启动Linux系统。设备中包括了两种存储介质，目标分区可以是两种存储介质中的分区。基于此，可以根据启动标识信息，从设备的不同存储介质的不同分区启动Linux系统，为系统启动提供多种途径。当一个途径启动失败时，还可以从其他途径实现系统启动，由此，提升了Linux系统启动的稳定性和可靠性。

图11所示装置中的各个模块/单元具有实现图2至8、10中各个步骤的功能，并能达到其相应的技术效果，为简洁描述，在此不再赘述。

图12示出了本申请实施例提供的一种基于Linux系统设备的硬件结构示意图。

在本申请一些实施例中，上述实施例中的Linux系统启动的方法可以应用于基于Linux系统的设备，如图12所示，该Linux系统设备100可以包括第一存储介质110和第二存储介质120，处理器130以及内存单元140。第一存储介质110、所述第二存储介质120、处理器130以及内存单元140之间可以通过总线连接。

在申请一些实施例中，第一存储介质110可以包括第一分区111和第二分区112，并且第二存储介质120可以包括第一分区121和第二分区122。

在本申请一些实施例中，第一存储介质110用于保存引导程序和第一启动程序；第二存储介质120用于保存所述第一启动程序；处理器130用于根据所述引导程序，获取所述内存单元中的启动标识信息；根据所述启动标识信息确定启动Linux系统的目标分区，并在所述目标分区启动Linux系统。

在本申请一些实施例中，该第一存储介质110的第一分区111可以用于保存用于引导系统启动的引导程序的镜像。示例性的，该引导程序可以为Uboot引导程序。

在本申请一些实施例中，该第一存储介质110的第二分区112可以用于保存第一启动程序。第一启动程序可以用于启动Linux系统的启动程序。第一启动程序可以包括内核启动程序和应用软件启动程序。

在本申请一些实施例中，该第一存储介质110的第二分区112保存了FIT镜像，FIT镜像可以由内核、设备树和RamDisk虚拟文件系统制作而成。RamDisk虚拟文件系统中包括了系统的应用软件启动程序。

在本申请一些实施例中，该第一存储介质的第二分区保存了FIT镜像，FIT镜像可以由内核、设备树和RamDisk虚拟文件系统制作而成。RamDisk虚拟文件系统中包括了系统的应用软件启动程序。

在本申请一些实施例中，该第二存储介质的第一分区和第二分区用于分别保存第一启动程序。第二存储介质的第一分区可以为主分区，第二存储介质的第二分区可以为备份分区。两个分区保存有相同的启动程序。

在本申请一些实施例中，第二存储介质的第一分区可以用于保存根文件系统镜像，其中根文件系统中的/boot文件夹下存放了内核镜像和设备树文件，根文件系统中的/home/root文件夹下应用软件启动程序。第二存储介质的第二分区可以用于保存备份根文件系统镜像。

在本申请一些实施例中，第一存储介质可以是非易失闪存(NOR Flash)。

在本申请一些实施例中，第二存储介质可以包括NAND Flash、eMMC或者SD中的任一种存储器。

在本申请一些实施例中，内存单元可以为DDR内存芯片。DDR内存芯片可以用于保存启动标识信息。启动标识信息包括启动次数标识和存储介质分区标识。

示例性的，处理器芯片还可以用于保存计时器。该计时器可以是看门狗。Uboot启动过程中，还可以使能看门狗功能。看门狗是一个可以在一定时间内被复位的计数器。当看门狗启动后，计数器开始自动计数，当达到预定时间时，处理器可以将这个计数器复位。计数器复位的操作称为“喂狗”。如果计数器没有被复位，计数器溢出就会对处理器产生一个复位信号使系统重启。在Uboot成功引导Linux内核启动后会关闭看门狗。

在本申请一些实施例中，如图9所示，基于Linux系统的设备作为下位机，与云服务器的可以进行升级交互。这里，基于Linux系统的设备的数量可以是多个。

当有Linux固件或应用程序需要替换和升级时，云服务器向下位机设备下发升级指令，下位机响应升级指令并向云服务器获取升级包下载地址。云服务器下发升级包下载地址，下位机下载升级包后向云服务器上报下载结果。若下载成功则进行升级，并向云服务器上报下载结果。

在本申请一些实施例中，嵌入式Linux设备接收到升级数据包，首先，可以保存升级数据包至Linux系统的第二存储介质的第二分区。示例性的，可以将升级数据包保存至home/root/OrigBack路径下。

在本申请一些实施例中，基于Linux系统的设备中的处理器还用于接收云服务器发送的升级数据包；根据升级数据包，替换第二存储介质中的第一启动程序，得到第二启动程序；根据获取的启动标识信息，依次从第二存储介质的第二分区和第二存储介质的第一分区启动Linux系统；发送升级标识至云服务器。

在本申请一些实施例中，基于Linux系统的设备中的处理器还用于保存升级数据包至Linux系统的第二存储介质的第二分区；当升级数据包中的下载校验码满足预设值时，向云服务器发送下载成功信息，并检测升级数据包。

在本申请一些实施例中，基于Linux系统的设备中的处理器还用于接收云服务器发送的版本回退信息；根据版本回退信息，确定第二存储介质中与版本回退信息对应的第三启动程序根据第三启动程序替换第二存储介质中的第一启动程序，并确定版本回退标识；重启Linux系统；发送版本回退标识至云服务器。

该基于Linux系统设备可以包括还可以存储有计算机程序指令的存储器(图中未示出)。

具体地，上述处理器130可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器可在综合网关容灾设备的内部或外部。在特定实施例中，存储器是非易失性固态存储器。在特定实施例中，存储器包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。

处理器130通过读取并执行存储器中存储的计算机程序指令，以实现上述实施例中的任意一种Linux系统启动的方法。

在一个示例中，该设备还可包括通信接口(图中未示出)和总线150。其中，处理器130、存储器、通信接口通过总线150连接并完成相互间的通信。

通信接口，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线150包括硬件、软件或两者，将该电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线150可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

该设备可以执行本申请实施例中的Linux系统启动的方法，从而实现结合图2至图8和图10描述的Linux系统启动的方法。

另外，结合上述实施例中的Linux系统启动的方法，本申请实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种Linux系统启动的方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。