CN112612524A

CN112612524A - Method, device and equipment for starting Linux system and storage medium

Info

Publication number: CN112612524A
Application number: CN202011525537.1A
Authority: CN
Inventors: 聂泳忠; 黄承强; 李红星; 屈海雄; 陈浩
Original assignee: Fatri Xi'an Testing & Control Technologies Co ltd
Current assignee: Fatri Xi'an Testing & Control Technologies Co ltd
Priority date: 2020-12-22
Filing date: 2020-12-22
Publication date: 2021-04-06

Abstract

The application discloses a method, a device, equipment and a storage medium for starting a Linux system. Specifically, the device comprises a first storage medium and a second storage medium, wherein the first storage medium comprises a first partition; obtaining a boot program of a first partition of a first storage medium; determining starting identification information according to a bootstrap program; and determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition, wherein the target partition is a partition of the first storage medium or a partition of the second storage medium. According to the embodiment of the application, the Linux system can be started from different partitions of different storage media of the equipment, and the starting stability and reliability of the Linux system are improved.

Description

Method, device and equipment for starting Linux system and storage medium

Technical Field

The present application belongs to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer storage medium for starting a Linux system.

Background

Generally, in an embedded Linux system, a boot program is mostly used to boot a Linux kernel to start and store a system image by using a storage medium.

However, in the long-time running process of the device, frequent reading and writing and some other abnormal operations exist, which may damage the partition of the storage medium, thereby affecting the stability of the Linux system.

Disclosure of Invention

The embodiment of the application provides a method, a device and equipment for starting a Linux system and a computer storage medium, the Linux system can be started from different partitions of different storage media of the equipment according to the starting identification information, and the starting stability and reliability of the Linux system are improved.

In a first aspect, an embodiment of the present application provides a Linux system starting method, which is applied to a device, where the device includes a first storage medium and a second storage medium, the first storage medium includes a first partition, and the method includes:

obtaining a boot program of a first partition of a first storage medium;

determining starting identification information according to the bootstrap program;

and determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition, wherein the target partition is a partition of the first storage medium or a partition of the second storage medium.

Optionally, the startup identification information includes a startup time identification and a storage medium partition identification, and the second storage medium includes a first partition; the determining the target partition for starting the Linux system according to the starting identification information comprises:

and when the starting times identifier and the storage medium partition identifier are both first preset identifiers, determining that the target partition for starting the Linux system is the first partition of the second storage medium.

Optionally, the second storage medium further comprises a second partition; the determining the target partition for starting the Linux system according to the starting identification information further comprises:

and when the starting time identifier is a first preset identifier and the storage medium partition identifier is a second preset identifier, determining that the target partition for starting the Linux system is a second partition of a second storage medium.

Optionally, the first storage medium further comprises a second partition; the determining the target partition for starting the Linux system according to the starting identification information comprises:

and when the starting times identifier is a second preset identifier and the storage medium partition identifier is a third preset identifier, determining that the target partition for starting the Linux system is a second partition of the first storage medium.

Optionally, the method further comprises:

and when the starting time identifier is a fourth preset identifier and the timer of the system exceeds a preset time threshold, resetting the Linux system.

Optionally, the booting the Linux system in the target partition includes:

reading a first starting program in a target partition according to the bootstrap program;

and starting the Linux system according to the first starting program.

Optionally, the first boot program includes: a kernel starting program and an application software starting program; according to the first starting program, starting the Linux system, comprising:

starting the kernel of the Linux system according to the kernel starting program;

and starting the application software of the Linux system according to the application software starting program.

Optionally, the starting the Linux system according to the first starting program includes:

when the Linux system is started successfully, sending information of successful starting to a cloud server;

and when the Linux system is failed to be started and the timer of the system exceeds a preset time threshold, resetting the Linux system.

Optionally, after the target partition starts the Linux system, the method further includes:

receiving an upgrading data packet sent by a cloud server;

replacing the first starting program in the second storage medium according to the upgrading data packet to obtain a second starting program;

setting a starting time identifier as a first preset identifier, setting a storage medium partition identifier as a second preset identifier, and resetting the Linux system;

reading a second starting program in a second partition of the second storage medium according to the starting times identifier and the storage medium partition identifier;

starting the Linux system according to a second starting program in a second partition of the second storage medium;

setting the starting times identifier and the storage medium partition identifier as a first preset identifier, and resetting the Linux system;

reading a second starting program in the first partition of the second storage medium according to the starting times identifier and the storage medium partition identifier;

starting the Linux system according to a second starting program in the first partition of the second storage medium, and determining an upgrading identifier;

and sending the upgrade identification to the cloud server.

Optionally, the receiving the upgrade data packet sent by the cloud server includes:

saving the upgrade data packet to a second partition of the second storage medium of the Linux system;

and when the download check code in the upgrade data packet meets a preset value, sending download success information to the cloud server, and detecting the upgrade data packet.

receiving version rollback information sent by a cloud server;

determining a third boot program corresponding to the version rollback information in the second storage medium according to the version rollback information

Replacing the first boot program in the second storage medium according to the third boot program, and determining a version rollback identifier;

restarting the Linux system;

and sending the version rollback identification to the cloud server.

Optionally, the version rollback information includes kernel version information and/or application software version information

In a second aspect, an embodiment of the present application provides a Linux system boot apparatus, which is applied to a device, where the device includes a first storage medium and a second storage medium, and the first storage medium includes a first partition; the device comprises:

an acquisition module to acquire a boot program of a first partition of a first storage medium;

the determining module is used for determining starting identification information according to the bootstrap program;

the determining module is further used for determining a target partition for starting the Linux system according to the starting identification information;

and the starting module is used for starting the Linux system in the target partition, and the target partition is a partition of the first storage medium or a partition of the second storage medium.

In a third aspect, an embodiment of the present application provides a device based on a Linux system, where the device includes: the device comprises a first storage medium, a second storage medium, a memory unit and a processor, wherein the first storage medium, the second storage medium, the memory unit and the processor are connected through a bus;

the first storage medium is used for storing a boot program and a first starting program;

the second storage medium is used for storing the first starting program;

the processor is used for acquiring the starting identification information in the memory unit according to the bootstrap program; and determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition.

Optionally, the first storage medium comprises a first partition and a second partition;

the first partition of the first storage medium is used for saving the boot program;

the second partition of the first storage medium is used for saving the first starting program.

Optionally, the second storage medium comprises a first partition and a second partition;

the first partition and the second partition of the second storage medium are used for respectively storing the first boot program.

Optionally, the first storage medium comprises a NOR Flash memory.

Optionally, the first storage medium includes any one of a NAND Flash, an eMMC, and an SD memory.

Optionally, the memory unit is a DDR memory chip.

In a fourth aspect, an embodiment of the present application provides an electronic device, where the device includes: a processor, and a memory storing computer program instructions, the memory comprising a first storage medium and a second storage medium;

the processor, when executing the computer program instructions, implements the method for booting a Linux system as described in the first aspect and optional aspects of the first aspect.

In a fifth aspect, the present application provides a computer storage medium, on which computer program instructions are stored, and when executed by a processor, the computer program instructions implement the method for booting the Linux system according to the first aspect and the optional first aspect.

The method, the device, the equipment and the computer storage medium for starting the Linux system can acquire the bootstrap program of the first partition of the first storage medium, and determine the starting identification information through the bootstrap program. And then, determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition. The device includes two storage media, and the target partition may be a partition of the two storage media. Based on the starting identification information, the Linux system can be started from different partitions of different storage media of the equipment, and multiple ways are provided for starting the system. When one path fails to start, the system can be started from other paths, so that the stability and the reliability of the start of the Linux system are improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments of the present application will be briefly described below, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a schematic diagram of a Linux system enabled device provided in some embodiments of the present application;

FIG. 2 is a flow chart illustrating a method for booting a Linux system according to some embodiments of the present application;

FIG. 3 is a flow chart of a method for booting a Linux system of a practical application according to some embodiments of the present application;

FIG. 4 is a flowchart illustrating a method for booting a Linux system according to some embodiments of the present application;

FIG. 5 is a flowchart illustrating a method for booting a Linux system according to another embodiment of the present application;

FIG. 6 is a flowchart illustrating a method for booting a Linux system according to another embodiment of the present application;

FIG. 7 is a flowchart illustrating a Linux system booting method according to another embodiment of the present application;

FIG. 8 is a flowchart illustrating a Linux system upgrade provided in accordance with further embodiments of the present application;

fig. 9 is a schematic flowchart illustrating an interaction between an embedded Linux device and a cloud server according to another embodiment of the present application;

FIG. 10 is a flowchart illustrating a version rollback of a Linux system according to another embodiment of the present application;

FIG. 11 is a schematic diagram of a Linux system boot device according to some embodiments of the present application;

fig. 12 is a hardware structure diagram of an electronic device according to some embodiments of the present application.

Detailed Description

Features and exemplary embodiments of various aspects of the present application will be described in detail below, and in order to make objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. It will be apparent to one skilled in the art that the present application may be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the present application by illustrating examples thereof.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The Linux system is widely applied to embedded devices due to the characteristics of source opening, convenience in transplantation, abundant driving resources and the like. In an embedded Linux system, a Uboot is mostly used as a bootstrap program to boot a Linux kernel to start, and a storage medium is adopted to store system images. In the long-time running process of the embedded device, if a single storage medium is adopted, multiple times of starting, frequent reading and writing and other abnormal operations are likely to damage the partition of the storage medium, so that the Linux system cannot be started normally.

For a device running an embedded Linux system, how to improve the reliability of the starting process is a problem to be urgently solved by those skilled in the art.

In order to solve the prior art problem, embodiments of the present application provide a method, an apparatus, a device, and a computer storage medium for starting a Linux system, which can start the Linux system from different partitions of different storage media of the device according to the start identification information, thereby improving the stability and reliability of the start of the Linux system.

The following describes a method, an apparatus, a device, and a computer storage medium for booting a Linux system according to an embodiment of the present application with reference to the accompanying drawings. It should be noted that these examples are not intended to limit the scope of the present disclosure.

First, a device based on a Linux system provided in an embodiment of the present application is described below.

Fig. 1 is a schematic diagram of a Linux system-based device provided in some embodiments of the present application. As shown in fig. 1, a device running an embedded Linux system may include a first storage medium and a second storage medium, the first storage medium may include a first partition and a second partition, and the second storage medium may include a first partition and a second partition.

Fig. 2 is a flowchart illustrating a method for booting a Linux system according to some embodiments of the present application. The execution subject of the Linux system starting method shown in fig. 2 may be the apparatus shown in fig. 1, and the Linux system starting method may be implemented as the following steps:

s201: a boot program for a first partition of a first storage medium is acquired.

A device running an embedded Linux system may include a first storage medium and a second storage medium. The first storage medium includes a first partition. The first partition of the first storage medium may be used to store an image of a boot program used to boot the system. Illustratively, the boot may be a Uboot boot.

In some embodiments of the present application, the first storage medium may further include a second partition. The second partition of the first storage medium may be used to store a first boot program. The first boot program may be used to boot a boot program of the Linux system. The first boot program may include a kernel boot program and an application software boot program.

In some embodiments of the present application, the second partition of the first storage medium stores an FIT image, which may be made of a kernel, a device tree, and a RamDisk virtual file system. The RamDisk virtual file system comprises an application software starting program of the system.

In some embodiments of the present application, the second storage medium may also include a first partition and a second partition. Both the first partition and the second partition of the second storage medium may be used to hold a first boot program. Here, the first partition of the second storage medium may be a primary partition, and the second partition of the second storage medium may be a backup partition. Both partitions hold the same boot program.

In some embodiments of the present application, the first partition of the second storage medium may be configured to store a root file system image, where a kernel image and a device tree file are stored in a root folder in the root file system, and an application software boot program is stored in the root file system in a home/root folder. The second partition of the second storage medium may be used to save a backup root file system image.

In some embodiments of the present application, the first storage medium may be a non-volatile Flash memory (NOR Flash).

In some embodiments of the present application, the second storage medium may be a NAND Flash, eMMC, or SD memory.

S202: and determining starting identification information according to the bootstrap program.

A first level boot program is solidified in the device and may be selected to boot from the first storage medium. Specifically, the first-level boot program copies a boot program image from the first storage medium, for example, the Uboot boot program image is executed in the DDR memory unit, and obtains the boot identification information in the DDR memory unit.

S203: and determining a target partition for starting the Linux system according to the starting identification information.

In some embodiments of the present application, the boot identification information may include a boot number identification and a storage medium partition identification.

In some embodiments of the present application, the target partition may be one of a partition of the first storage medium or a partition of the second storage medium.

In some embodiments of the present application, when the start time identifier and the storage medium partition identifier are both first preset identifiers, it is determined that the target partition for starting the Linux system is the first partition of the second storage medium.

And when the starting time identifier is a first preset identifier and the storage medium partition identifier is a second preset identifier, determining that the target partition for starting the Linux system is a second partition of the second storage medium.

And when the starting time identifier is a second preset identifier and the storage medium partition identifier is a third preset identifier, determining that the target partition for starting the Linux system is a second partition of the first storage medium.

In some embodiments of the present application, the first preset flag may be 0, the second preset flag may be 1, and the third preset flag may be not 0.

In addition, in some embodiments of the present application, when the startup time identifier is a fourth preset identifier and the timer of the system exceeds a preset time threshold, the Linux system is reset, that is, the operation of starting the Linux system is re-executed.

For example, the fourth preset flag may be not 0 but not 1.

S204: and starting the Linux system in the target partition.

In some embodiments of the present application, a first boot program in a target partition may be read according to a boot program; and starting the Linux system according to the first starting program.

Firstly, according to the kernel starting program, the kernel of the Linux system can be started. And then, starting the application software of the Linux system according to the application software starting program.

When the Linux system is started successfully, sending the information of successful start to the cloud server;

when the Linux system is not started and the timer of the system exceeds the preset time threshold, the Linux system is reset, i.e., the operations from S201 to S204 can be executed again until the Linux system is started successfully.

In summary, in the embodiment of the present application, the method for booting the Linux system can obtain the boot program of the first partition of the first storage medium, and determine the boot identification information through the boot program. And then, determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition. The device includes two storage media, and the target partition may be a partition of the two storage media. Based on the starting identification information, the Linux system can be started from different partitions of different storage media of the equipment, and multiple ways are provided for starting the system. When one path fails to start, the system can be started from other paths, so that the stability and the reliability of the start of the Linux system are improved.

In order to better understand the method for starting the Linux system of the present application, the method for starting the Linux system of the present application will now be described in detail with reference to an example of an actual application.

Fig. 3 is a flowchart illustrating a method for booting a Linux system in a practical application scenario according to some embodiments of the present application.

S301: and powering on and starting the equipment.

S302: the primary boot program is launched from the first partition of the first storage medium and executes the Uboot boot program.

Illustratively, the first storage medium may be a NOR Flash memory. The boot program may be a Uboot boot program.

S303: and the Uboot bootstrap program acquires the starting identification information in the DDR memory.

After the device is powered on, first, a first level bootstrap program solidified in the ROM by the manufacturer of the running device can be used to select to start from the NOR Flash. And the primary bootstrap program is copied from the NOR Flash to the Uboot bootstrap program mirror image and executed in the DDR memory.

The Uboot bootstrap program may be used to boot up a Linux system kernel, etc. When the Uboot is started, a boot cmd command is called, and then a Linux kernel and a mounted file system are loaded and started from a partition of which storage medium according to the configuration of the environment variable.

The DDR high-end memory address stores the startup identification information. The startup identification information includes a startup time identification and a storage medium partition identification. There are operation commands md and mw for reading and writing the memory in the Uboot, but return values of these two commands cannot be obtained in the environment variable, and further the judgment of the start identification information in the high-end memory cannot be completed. Here, a custom command may be added to the Uboot for a high-side memory read operation and to determine a value to return. Therefore, the Uboot can read the judgment starting identification information in the DDR high-end memory address.

In some embodiments of the present application, a timer may also be included in the processor of the Linux system apparatus. Illustratively, the timer may be a watchdog. During the Uboot startup process, a watchdog function may also be enabled. A watchdog is a counter that can be reset within a certain time. The counter starts counting automatically when the watchdog is started, and the processor may reset the counter when a predetermined time is reached. The operation of resetting the counter is called "feeding the dog". If the counter is not reset, the counter overflow will generate a reset signal to the processor to restart the system. The watchdog is closed after the Uboot successfully boots the Linux kernel to start.

S304: and determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition.

In some embodiments of the present application, the start time identifier of the start identification information and the storage medium partition identifier may be used to determine from which storage medium partition the Linux kernel is loaded and started. By judging the starting identification information, the Linux system can be started through different target partitions.

In some embodiments of the present application, the start number identifier may correspond to any one of a first preset identifier, a second preset identifier, a third preset identifier, and a fourth preset identifier. The storage medium partition identifier may correspond to any one of a first preset identifier, a second preset identifier, a third preset identifier, and a fourth preset identifier.

In some embodiments of the present application, the first preset flag may be 0, the second preset flag may be 1, the third preset flag may be non-0, and the fourth preset flag may be non-0 and non-1.

The target partition includes a second partition of the first storage medium and first and second partitions of the second storage medium. Illustratively, the first storage medium may be NOR Flash, the first partition of the second storage medium may be a primary partition of the eMMC, and the second partition of the second storage medium may be a backup partition of the eMMC.

In some embodiments of the present application, S304 in fig. 3 may be implemented by S401 to S407 in fig. 4, as shown in fig. 4:

s401: and judging whether the starting time identifier is 0.

S402: and judging whether the storage medium partition identification is 0 or not.

First, it may be determined whether the start count flag is 0.

When the starting time identifier is 0, judging whether the storage medium partition identifier is 0.

To facilitate execution of the startup procedure, the startup number flag may be set to 1 after determining that the startup number flag is 0.

S403: the Linux kernel is started from the first partition of the second storage medium.

And when the starting times identifier and the storage medium partition identifier are both 0, starting the Linux kernel from the first partition of the second storage medium.

S404: and judging whether the kernel is started successfully.

S405: and mounting the first partition file system of the second storage medium, and starting the application software.

And when the Linux kernel is successfully started from the first partition of the second storage medium, mounting the first partition file system of the second storage medium, and starting the application software.

In some embodiments of the present application, since the watchdog may be turned off after the kernel is successfully started, the watchdog may be enabled again when the application software is started.

In addition, in order to realize that the Linux system can be started from the first partition of the second storage medium after the software reset restart, the start time identifier can be set to be 0.

In some embodiments of the present application, when the Linux kernel is not started from the first partition of the second storage medium, it may be further determined whether the watchdog times out. When the Linux kernel is not started from the first partition of the second storage medium, and the watchdog is timed out, the system is reset, and the execution returns to S302.

S406: and judging whether the application software is started successfully or not.

S407: and reporting the working state to a cloud server.

And reporting the working state to the cloud server when the application software is successfully started from the first partition of the second storage medium.

In some embodiments of the present application, the application software may interact with the cloud server to report the working state. The operating state may include information such as which partition of which storage medium the system successfully booted. Here, a successful start of the system in the first partition of the second storage medium may be transmitted to the cloud server.

In some embodiments of the present application, when the application software is failed to be launched from the first partition of the second storage medium, it may be further determined whether the watchdog times out. When the application software started from the first partition of the second storage medium fails and the watchdog times out, the system is reset and the process returns to the step S302.

In some embodiments of the application, since the software is reset without power failure, the startup identification information stored in the DDR is not lost, and after the system is restarted, the Uboot boot program may determine according to the startup identification information, and may switch to the second partition of the second storage medium to start the Linux system, or switch to the second partition of the first storage medium to start the Linux system. It is understood that the Uboot bootstrap program may make a judgment according to the boot identification information, and may attempt to boot the target partition of the Linux system.

In some embodiments of the present application, as shown in fig. 5, fig. 5 is a flowchart illustrating a method for booting a Linux system according to another embodiment of the present application. In executing S402, when the storage medium partition identification is not 0, the method further includes the steps of:

s501: and starting the Linux kernel from the second partition of the second storage medium.

And when the starting time identification is 0 and the storage medium partition identification is 1, starting the Linux kernel from the second partition of the second storage medium.

In some embodiments of the present application, for example, when the start time identifier is 0, determining whether the storage medium partition identifier is 0; when the storage medium partition identification is not 0, it may also be determined whether the storage medium partition identification is 1. When the storage medium partition is identified as 1, the Linux kernel can be started from the second partition of the second storage medium.

S502: and judging whether the kernel is started successfully.

S503: and mounting a second partition file system of the second storage medium, and starting the application software.

And when the Linux kernel is successfully started from the second partition of the second storage medium, mounting a second partition file system of the second storage medium, and starting the application software.

When the Linux kernel is not started from the second partition of the second storage medium, and the watchdog is timed out, the system is reset, and the execution returns to S302.

S504: and judging whether the application software is started successfully or not.

S505: and reporting the working state to a cloud server.

And reporting the working state to the cloud server when the application software is successfully started from the second partition of the second storage medium.

In some embodiments of the present application, the application software may interact with the cloud server to report the working state. Here, a successful boot of the system in the second partition of the second storage medium may be transmitted to the cloud server. When the application software is not launched from the second partition of the second storage medium and the watchdog times out, the system is reset and the process returns to the step S302.

In some embodiments of the present application, after failing to boot the Linux system from the second partition of the second storage medium, the Uboot boot program may determine according to the boot identification information, and then boot the Linux system from the second partition of the first storage medium.

In some embodiments of the present application, as shown in fig. 6, fig. 6 is a flowchart illustrating a method for booting a Linux system according to another embodiment of the present application. When the start-up number flag is not 0 in executing S401 shown in fig. 4, the method further includes the steps of:

s601: and judging whether the starting time identifier is 1 or not.

S602: and judging whether the storage medium partition identification is 0 or not.

When the number of times of activation is 1, it is determined whether the storage medium partition identifier is 0, which may be to determine whether the storage medium partition identifier is not 0. In this way, when the boot count is identified as 1 and the storage medium partition is identified as not 0, it is determined that the Linux system is booted from the second partition of the first storage medium. In some embodiments of the present application, in order to facilitate execution of the boot program and to distinguish partitions of the storage medium, after determining that the boot count flag is 0 and the storage medium partition flag is not 0, the storage medium partition flag may be set to 2 by the Uboot bootstrap program.

Further, in some embodiments herein, when the storage medium partition identification is 0, the storage medium partition identification may be set to 1 by the Uboot bootstrap program. Meanwhile, the start-up number flag may be set to 1 by the Uboot bootstrap program, the target partition may be switched to the second partition of the second storage medium, and the Linux system may be started in the second partition of the second storage medium.

S603: and starting the Linux kernel from the second partition of the first storage medium.

S604: and mounting the ramdisk file system from the second partition of the first storage medium, and starting the application software.

S605: and reporting the working state to a cloud server.

And reporting the working state to the cloud server when the Linux kernel and the application software are successfully started in the second partition of the first storage medium.

In some embodiments of the present application, the application software may interact with the cloud server to report the working state. Here, a successful boot of the system in the second partition of the first storage medium may be transmitted to the cloud server.

In some embodiments of the present application, the second partition boot on the first storage medium is an abnormal partition boot. After receiving the working state, the cloud server can send alarm information to the operation and maintenance system, so that operation and maintenance personnel can maintain the problem equipment in time.

In some embodiments of the present application, when it is determined to boot a target partition of a Linux system according to the boot identifier information, there may also be a situation as shown in fig. 7, and fig. 7 is a flowchart illustrating a method for booting a Linux system according to another embodiment of the present application. When the start-up number flag is not 1 when S601 shown in fig. 6 is executed, the method further includes the steps of:

s701: and the Uboot guiding system fails to start and judges whether the watchdog is overtime or not.

Through the judgment of S401 and S601, when the start time identifier is not 0 but not 1, that is, the start time identifier is the fourth preset identifier, the Uboot guidance system fails to start, and whether the watchdog is overtime is judged.

S702: and when the watchdog is overtime or not, resetting the Linux system and returning to the step S302.

In summary, in the embodiment of the present application, based on the method for starting a Linux system, in a process of powering on and starting a device, by using a Uboot boot program in combination with the start identifier information judgment and the watchdog function, if a start failure occurs in any one of the storage medium partitions, automatic switching of the storage medium partitions may be implemented, so as to ensure that the Linux system can be successfully started finally. Therefore, the starting stability of the Linux system can be improved.

In order to optimize the Linux system upgrade of the embedded Linux device in the above embodiment, in the embodiment of the present application, after the Linux system is started, an upgrade operation on the Linux system is further included. As shown in fig. 8, fig. 8 is a schematic flowchart of an upgrade of a Linux system according to another embodiment of the present application.

S801: and receiving an upgrading data packet sent by the cloud server.

In some embodiments of the present application, a specific process may be referred to in fig. 9, and fig. 9 is a flowchart illustrating interaction between an embedded Linux device and a cloud server according to another embodiment of the present application. In fig. 9, the embedded Linux device is used as a lower computer and can perform upgrade interaction with the cloud server. The number of the embedded Linux devices may be multiple, and only one Linux device is schematically illustrated in fig. 9.

When the Linux firmware or the application program needs to be replaced and upgraded, the cloud server issues an upgrade instruction to the lower computer device, and the lower computer responds to the upgrade instruction and acquires an upgrade package download address from the cloud server. And the cloud server issues an upgrade package download address, and the lower computer uploads a download result to the cloud server after downloading the upgrade package. And if the downloading is successful, upgrading, and reporting the downloading result to the cloud server.

In some embodiments of the present application, the embedded Linux device receives the upgrade data packet, and may first store the upgrade data packet to a second partition of a second storage medium of the Linux system. Illustratively, the upgrade data package may be saved under the home/root/origin path.

It will be appreciated that because the first partition and the second partition of the second storage medium may be holding the same data. Therefore, the package may also be upgraded to the first partition of the second storage medium. Illustratively, the backup area of the first partition of the package second storage medium may be upgraded.

Then, whether the upgrade data package is downloaded successfully is judged. And when the download check code in the upgrade data packet meets a preset value, sending download success information to the cloud server, and detecting the upgrade data packet. Illustratively, the download verification code may be verified by MD 5.

And when the download check code in the upgrade data packet does not meet the preset value, sending download failure information to the cloud server, and exiting the upgrade process.

In some embodiments of the present application, detecting the upgrade data package specifically includes checking whether the upgrade data package has an upgrade program package therein.

When there is an upgrade package in the upgrade package, S802 is continuously performed.

When the upgrade data packet does not contain the upgrade program packet, an upgrade identifier is generated, and the upgrade identifier may be an upgrade failure identifier. And sending upgrade failure information to the cloud server, clearing the upgrade failure identifier and the upgrade data packet, and exiting the upgrade process.

S802: and replacing the first starting program in the second storage medium according to the upgrading data packet to obtain a second starting program.

In some embodiments of the present application, first, the upgrade data package may be decompressed. If the upgrading data package contains the application software upgrading package, respectively replacing the home/root/app in the first partition and the second partition of the second storage medium according to the application software upgrading package; and if the Linux kernel upgrading package exists, replacing/boot in the first partition and the second partition of the second storage medium respectively according to the Linux kernel upgrading package.

Specifically, the application software is stored in the/home/root folder under the root file systems of the first partition and the second partition of the second storage medium, and the version upgrade of the application software can be realized by replacing the files in the directory. The kernel mirror image and the device tree file are stored under the boot folder under the root file system of the first partition and the second partition of the second storage medium, and the kernel drive version upgrading can be realized by replacing the files under the directory.

Here, the second boot program may be a boot program in the upgrade data package.

S803: and setting the starting time identifier as a first preset identifier, setting the storage medium partition identifier as a second preset identifier, and resetting the Linux system.

S804: and reading a second boot program in a second partition of the second storage medium according to the boot frequency identification and the storage medium partition identification.

In some embodiments of the present application, when the second partition of the second storage medium reboots the system, an in-progress upgrade identifier may be generated and saved to identify that the system is now upgrading. And setting the storage medium partition identification as a second preset identification, namely 1, so that the device starts the Linux system from a second partition of the second storage medium.

Here, resetting the Linux system may be an active reset of the system.

S805: and starting the Linux system according to the second starting program in the second partition of the second storage medium.

Here, the second partition of the second storage medium is a backup partition, i.e., the Linux system is started in the backup partition of the second storage medium.

S806: and setting the starting times identifier and the storage medium partition identifier as a first preset identifier, and resetting the Linux system.

Here, the start-up number flag and the storage medium partition flag are set to a first preset flag, that is, to 0.

S807: and reading a second boot program in the first partition of the second storage medium according to the boot frequency identification and the storage medium partition identification.

S808: and starting the Linux system according to the second starting program in the first partition of the second storage medium, and determining the upgrading identifier.

Here, the first partition of the second storage medium is a primary partition, i.e., the Linux system is started on the primary partition of the second storage medium. Before booting, it may be detected whether the Linux system booting in the second partition of the second storage medium, i.e. in the backup partition, is running normally. When the Linux system runs normally, the Linux system is restarted in the first partition of the second storage medium, i.e. in the main partition.

When the Linux system is started successfully, the upgrading identifier is an upgrading success identifier; and when the Linux system is failed to be started, the upgrading identifier is an upgrading failure identifier.

S809: and sending the upgrading identification to the cloud server.

In some embodiments of the present application, the upgrade flag may be an upgrade success flag or an upgrade failure flag. After the upgrade identifier is sent to the cloud server, the upgrade identifier and the upgrade data packet can be cleaned.

In summary, the Linux system starting method provided in the embodiment of the present application further includes, after starting, interaction between the device applying the method and the cloud server, so as to implement upgrading of the Linux system. The cloud server can realize remote batch upgrading of the online embedded Linux equipment and check the upgrading state of the equipment. Compared with the method for realizing version updating by burning new software for each device in the related art, the method provided by the embodiment of the application is more efficient and easy to execute.

In some embodiments of the present application, after the Linux system is started by the target partition, the method further includes executing a version rollback operation according to a version rollback instruction of the cloud server. As shown in fig. 10, fig. 10 is a flowchart illustrating a version rollback of a Linux system according to another embodiment of the present application. The method can be embodied as the following steps:

s1001: and receiving version rollback information sent by the cloud server.

When version rollback information sent by the cloud server is received, the currently running application software may be stopped first.

In some embodiments of the present application, the version rollback information includes kernel version information and/or application software version information.

According to the received version rollback information, whether the version of the Linux kernel is rolled back, or the version of the application software is rolled back, or the version of the Linux kernel and the version of the application software are rolled back can be judged firstly.

S1002: and determining a third starting program corresponding to the version rollback information in the second storage medium according to the version rollback information.

The third boot program is an old version of the boot program backed up in the second storage medium. According to the version number and other information in the version rollback information, the starting program of the corresponding version can be found.

S1003: and replacing the first boot program in the second storage medium according to the third boot program, and determining the version rollback identifier.

The first boot program may refer to a version of the boot program that is currently in use.

During execution of the program replacement, a version rollback identification may be generated. The version rollback identification is used to identify a state of the version rollback. The version rollback identification may include a version rollback in-execution identification, a version rollback success identification, and a version rollback failure identification.

S1004: and restarting the Linux system.

S1005: and sending the version rollback identification to the cloud server.

And restarting the Linux system and judging whether the version rollback is successful. Specifically, whether the version rollback is successful may be determined according to a software version number of the system. And then, sending the version rollback success identifier or the version rollback failure identifier to the cloud server.

After the version rollback identifier is sent to the cloud server, the third boot program which is used as the backup program before can be deleted.

In summary, according to the method for starting the Linux system provided by the embodiment of the present application, after the Linux device serving as the lower computer receives the software version rollback instruction issued by the cloud platform, the Linux device may stop running the application software. And acquiring a backup program corresponding to the version type (Linux kernel version or application software version) to be backed according to the back-off instruction, and decompressing the backup program to cover the current program. And then saving the version rollback flag, and resetting and restarting the Linux kernel and/or the application software. And judging whether the rollback is successful according to the software version number, and finally reporting the cloud platform version rollback result. Therefore, the version rollback of the Linux starting system is convenient to realize, and the management of the starting system of the embedded Linux equipment can be optimized.

Based on the method for starting the Linux system provided by the embodiment, correspondingly, the application further provides a specific implementation mode of the device for starting the Linux system. Please see the examples below.

Fig. 11 is a schematic structural diagram of a Linux system boot apparatus according to some embodiments of the present application. The Linux system starting device is applied to equipment, the equipment comprises a first storage medium and a second storage medium, and the first storage medium comprises a first partition; the device comprises:

an obtaining module 1101 configured to obtain a boot program of a first partition of a first storage medium;

a determining module 1102, configured to determine the start identification information according to the bootstrap.

The determining module 1102 is further configured to determine, according to the startup identification information, a target partition for starting the Linux system.

A starting module 1104, configured to start the Linux system in the target partition, where the target partition is a partition of the first storage medium or a partition of the second storage medium.

In summary, the Linux system boot apparatus in this embodiment of the present application may be configured to execute the Linux system boot method in the foregoing embodiment, where the method is capable of obtaining a boot program of the first partition of the first storage medium, and determining the boot identification information through the boot program. And then, determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition. The device includes two storage media, and the target partition may be a partition of the two storage media. Based on the starting identification information, the Linux system can be started from different partitions of different storage media of the equipment, and multiple ways are provided for starting the system. When one path fails to start, the system can be started from other paths, so that the stability and the reliability of the start of the Linux system are improved.

Each module/unit in the apparatus shown in fig. 11 has a function of implementing each step in fig. 2 to 8, and 10, and can achieve the corresponding technical effect, and for brevity, the description is not repeated herein.

Fig. 12 shows a hardware structure schematic diagram of a Linux-based system device according to an embodiment of the present application.

In some embodiments of the present application, the method for booting the Linux system in the above embodiments may be applied to a device based on the Linux system, and as shown in fig. 12, the Linux system device 100 may include a first storage medium 110 and a second storage medium 120, a processor 130, and a memory unit 140. The first storage medium 110, the second storage medium 120, the processor 130, and the memory unit 140 may be connected by a bus.

In some embodiments, the first storage medium 110 may include a first partition 111 and a second partition 112, and the second storage medium 120 may include a first partition 121 and a second partition 122.

In some embodiments of the present application, the first storage medium 110 is used to store a boot program and a first boot program; the second storage medium 120 is used for storing the first starting program; the processor 130 is configured to obtain start identification information in the memory unit according to the bootstrap program; and determining a target partition for starting the Linux system according to the starting identification information, and starting the Linux system in the target partition.

In some embodiments of the present application, the first partition 111 of the first storage medium 110 may be used to store an image of a boot program for booting a system boot. Illustratively, the boot may be a Uboot boot.

In some embodiments of the present application, the second partition 112 of the first storage medium 110 may be used to store a first boot program. The first boot program may be used to boot a boot program of the Linux system. The first boot program may include a kernel boot program and an application software boot program.

In some embodiments of the present application, the second partition 112 of the first storage medium 110 stores an FIT image, which may be made by a kernel, a device tree, and a RamDisk virtual file system. The RamDisk virtual file system comprises an application software starting program of the system.

In some embodiments of the present application, the first partition and the second partition of the second storage medium are used to separately store the first boot program. The first partition of the second storage medium may be a primary partition and the second partition of the second storage medium may be a backup partition. Both partitions hold the same boot program.

In some embodiments of the present application, the second storage medium may include any one of NAND Flash, eMMC, or SD memory.

In some embodiments of the present application, the memory unit may be a DDR memory chip. The DDR memory chip can be used for storing the startup identification information. The startup identification information includes a startup time identification and a storage medium partition identification.

Illustratively, the processor chip may also be used to save a timer. The timer may be a watchdog. During the Uboot startup process, a watchdog function may also be enabled. A watchdog is a counter that can be reset within a certain time. The counter starts counting automatically when the watchdog is started, and the processor may reset the counter when a predetermined time is reached. The operation of resetting the counter is called "feeding the dog". If the counter is not reset, the counter overflow will generate a reset signal to the processor to restart the system. The watchdog is closed after the Uboot successfully boots the Linux kernel to start.

In some embodiments of the present application, as shown in fig. 9, a device based on a Linux system is used as a lower computer, and can perform upgrade interaction with a cloud server. Here, the number of devices based on the Linux system may be plural.

In some embodiments of the present application, the processor in the Linux system-based device is further configured to receive an upgrade data packet sent by the cloud server; replacing the first starting program in the second storage medium according to the upgrading data packet to obtain a second starting program; according to the obtained starting identification information, starting the Linux system from a second partition of a second storage medium and a first partition of the second storage medium in sequence; and sending the upgrading identification to the cloud server.

In some embodiments of the present application, the processor in the Linux system-based device is further configured to save the upgrade data package to a second partition of a second storage medium of the Linux system; and when the download check code in the upgrade data packet meets a preset value, sending download success information to the cloud server, and detecting the upgrade data packet.

In some embodiments of the present application, the processor in the Linux system-based device is further configured to receive version rollback information sent by the cloud server; according to the version rollback information, determining that a third starting program corresponding to the version rollback information in the second storage medium replaces a first starting program in the second storage medium according to the third starting program, and determining a version rollback identifier; restarting the Linux system; and sending the version rollback identification to the cloud server.

The Linux-based system device may include a memory (not shown) that may also store computer program instructions.

Specifically, the processor 130 may include a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or may be configured to implement one or more Integrated circuits of the embodiments of the present Application.

The memory may include mass storage for data or instructions. By way of example, and not limitation, memory may include a Hard Disk Drive (HDD), floppy Disk Drive, flash memory, optical Disk, magneto-optical Disk, magnetic tape, or Universal Serial Bus (USB) Drive or a combination of two or more of these. The memory may include removable or non-removable (or fixed) media, where appropriate. The memory may be internal or external to the integrated gateway disaster recovery device, where appropriate. In a particular embodiment, the memory is non-volatile solid-state memory. In a particular embodiment, the memory includes Read Only Memory (ROM). Where appropriate, the ROM may be mask-programmed ROM, Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), electrically rewritable ROM (EAROM), or flash memory or a combination of two or more of these.

The processor 130 reads and executes the computer program instructions stored in the memory to implement any one of the methods for booting the Linux system in the above embodiments.

In one example, the device may also include a communication interface (not shown in the figure) and a bus 150. The processor 130, the memory, and the communication interface are connected via a bus 150 to complete communication.

The communication interface is mainly used for realizing communication among modules, devices, units and/or equipment in the embodiment of the application.

The bus 150 includes hardware, software, or both to couple the components of the electronic device to one another. By way of example, and not limitation, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hypertransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an infiniband interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a video electronics standards association local (VLB) bus, or other suitable bus or a combination of two or more of these. Bus 150 may include one or more buses, where appropriate. Although specific buses are described and shown in the embodiments of the application, any suitable buses or interconnects are contemplated by the application.

The device may execute the method for booting the Linux system in the embodiment of the present application, so as to implement the method for booting the Linux system described in conjunction with fig. 2 to 8 and 10.

In addition, in combination with the method for starting the Linux system in the above embodiments, the embodiments of the present application may provide a computer storage medium to implement. The computer storage medium having computer program instructions stored thereon; the computer program instructions, when executed by a processor, implement any of the above-described embodiments of the method for booting a Linux system.

It is to be understood that the present application is not limited to the particular arrangements and instrumentality described above and shown in the attached drawings. A detailed description of known methods is omitted herein for the sake of brevity. In the above embodiments, several specific steps are described and shown as examples. However, the method processes of the present application are not limited to the specific steps described and illustrated, and those skilled in the art can make various changes, modifications, and additions or change the order between the steps after comprehending the spirit of the present application.

The functional blocks shown in the above-described structural block diagrams may be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it may be, for example, an electronic circuit, an Application Specific Integrated Circuit (ASIC), suitable firmware, plug-in, function card, or the like. When implemented in software, the elements of the present application are the programs or code segments used to perform the required tasks. The program or code segments may be stored in a machine-readable medium or transmitted by a data signal carried in a carrier wave over a transmission medium or a communication link. A "machine-readable medium" may include any medium that can store or transfer information. Examples of a machine-readable medium include electronic circuits, semiconductor memory devices, ROM, flash memory, Erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, Radio Frequency (RF) links, and so forth. The code segments may be downloaded via computer networks such as the internet, intranet, etc.

It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, the present application is not limited to the order of the above-described steps, that is, the steps may be performed in the order mentioned in the embodiments, may be performed in an order different from the order in the embodiments, or may be performed simultaneously.

Aspects of the present disclosure are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions/acts specified in the flowchart and/or block diagram block or blocks. Such a processor may be, but is not limited to, a general purpose processor, a special purpose processor, an application specific processor, or a field programmable logic circuit. It will also be understood that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware for performing the specified functions or acts, or combinations of special purpose hardware and computer instructions.

As described above, only the specific embodiments of the present application are provided, and it can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the system, the module and the unit described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again. It should be understood that the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the present application, and these modifications or substitutions should be covered within the scope of the present application.

Claims

1. The method for starting the Linux system is applied to a device, wherein the device comprises a first storage medium and a second storage medium, and the first storage medium comprises a first partition; the method comprises the following steps:

obtaining a boot program of a first partition of a first storage medium;

2. The method of claim 1, wherein the boot identification information includes a boot number identification and a storage medium partition identification, and the second storage medium includes the first partition; the determining the target partition for starting the Linux system according to the starting identification information comprises:

3. The method of claim 2, wherein the second storage medium further comprises a second partition; the determining the target partition for starting the Linux system according to the starting identification information further comprises:

4. The method of claim 2, wherein the first storage medium further comprises a second partition; the determining the target partition for starting the Linux system according to the starting identification information comprises:

5. The method of claim 2, further comprising:

6. The method according to any of claims 1 to 4, wherein said booting said Linux system in said target partition comprises:

and starting the Linux system according to the first starting program.

7. The method of claim 6, wherein the first boot procedure comprises: a kernel starting program and an application software starting program; according to the first starting program, starting the Linux system, comprising:

8. The method according to claim 6, wherein said booting said Linux system according to said first boot program comprises:

9. The method according to any one of claims 1 to 4, further comprising, after the target partition boots the Linux system:

receiving an upgrading data packet sent by a cloud server;

and sending the upgrade identification to the cloud server.

10. The method of claim 9, wherein the receiving the upgrade data packet sent by the cloud server comprises:

11. The method according to any one of claims 1 to 4, further comprising, after the target partition boots the Linux system:

receiving version rollback information sent by a cloud server;

restarting the Linux system;

and sending the version rollback identification to the cloud server.

12. The method of claim 11, wherein the version rollback information comprises kernel version information and/or application version information.

13. The Linux system starting device is applied to a device, the device comprises a first storage medium and a second storage medium, and the first storage medium comprises a first partition; the device comprises:

14. The device based on the Linux system is characterized by comprising a first storage medium, a second storage medium, a memory unit and a processor, wherein the first storage medium, the second storage medium, the memory unit and the processor are connected through a bus;

the second storage medium is used for storing the first starting program;

15. The apparatus of claim 14,

the first storage medium includes a first partition and a second partition;

16. The apparatus of claim 14,

the second storage medium includes a first partition and a second partition;

17. The device of claim 14, wherein the first storage medium comprises NOR Flash memory.

18. The device of claim 14, wherein the first storage medium comprises any one of NAND Flash, eMMC, and SD memory.

19. The apparatus of claim 14, wherein the memory unit is a DDR memory chip.

20. An electronic device, characterized in that the device comprises: a processor, a first storage medium, a second storage medium, and a memory storing computer program instructions;

the processor, when executing the computer program instructions, implements the method of Linux system boot of any of claims 1-12.

21. A computer storage medium having stored thereon computer program instructions which, when executed by a processor, implement the method of Linux system boot of any one of claims 1-12.