The present disclosure relates to the field of embedded devices, and more particularly, to a method and apparatus for monitoring a BootLoader startup procedure, an embedded device, and a storage medium.
BootLoader is a bootstrap program executed before running an operating system of an embedded device. A hardware device can be initialized by executing the BootLoader, to establish a mapping table of a memory space, so that an appropriate system software and hardware environment can be established, thereby preparing a processor of the embedded device to finally invoke a kernel of the operating system.
In general, a startup process of the BootLoader consists of two major stages, each of which in turn includes a plurality of sub-stages. However, there is no effective way in the related art to implement statistics of consumption time of execution of various stages (or sub-stages) of the statistical BootLoader, nor is there an effective way to implement fault location for multiple stages (or sub-stages) involved in the startup process of the BootLoader under the condition of startup failure of a BootLoader.
In order to solve the above technical problems or at least partially solve the above technical problems, the present disclosure provides a method and apparatus for monitoring a BootLoader startup procedure, an embedded device, and a storage medium.
In a first aspect, the present disclosure provides a method for monitoring a BootLoader startup procedure, including:
Optionally, the execution process information includes a start execution time and an end execution time; and
Optionally, the execution process information includes execution consumption time; and
Optionally, the trigger signal is configured to indicate end of successful startup of the BootLoader, and the determining the execution state of the target function module according to the obtained execution process information includes:
Optionally, the trigger signal is configured to indicate startup failure of the BootLoader, and the determining of the execution state of the target function module according to the obtained execution process information of the target function module includes:
In a second aspect, the present disclosure provides an apparatus for monitoring a BootLoader startup procedure, including:
Optionally, the execution process information includes a start execution time and an end execution time; and
Optionally, the execution process information includes execution consumption time; and the information obtaining module includes:
In a third aspect, there is provided an embedded device, including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory perform communication with each other through the communication bus;
In a fourth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements steps of the method for monitoring the BootLoader startup procedure described in any one of the embodiments of the first aspect.
The above technical solutions provided by the embodiments of the present disclosure have the following advantages compared with the related art.
According to the methods provided in the embodiments of the present disclosure, the execution process information of the target function module included in the BootLoader is obtained in the startup process of the BootLoader, and when the trigger signal of the BootLoader is detected, the execution state of the target function module is determined according to the obtained execution process information of the target function module, so as to obtain the execution process information of each target function module (i.e., each stage) included in the BootLoader in the startup process of the BootLoader, which can optimize the BootLoader startup procedure with the granularity of each stage included in the BootLoader startup procedure, thereby providing effective information for improving a startup speed of the embedded device. Further, even if the startup of the BootLoader fails, a stage in which an abnormality occurs in the startup process of the BootLoader can be determined according to the obtained execution process information, thereby providing effective information for fault location.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.
In order to more clearly illustrate the technical solutions in embodiments of the present disclosure or related art, the accompanying drawings depicted in the description of the embodiments or the related art will be briefly described below. It will be apparent that other drawings may be obtained from these drawings without creative effort by those skilled in the art.
In order to make objects, technical solutions, and advantages of embodiments of the present disclosure clearer, technical solutions in embodiments of the present disclosure will be clearly and completely described below in conjunction with drawings in the embodiments of the present disclosure. Obviously, the described embodiments are a part of embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present disclosure.
At step 101, execution process information of a target function module included in a BootLoader may be obtained in a startup process of the BootLoader.
Generally, the startup process of the BootLoader includes two stages, i.e., a first stage and a second stage. The first stage generally includes following sub-stages: initialization of a hardware device, preparation of a RAM space for loading a second stage of the BootLoader, copying of the second stage of the BootLoader to the RAM space, setting of a stack, and jumping to an entry point of the second stage. The second stage generally includes following sub-stages: initialization of a hardware device to be used in the second stage, detection of a system memory map, reading of a kernel image and a root file system image from an Flash to the RAM space, setting of a startup parameter for the kernel, and calling of the kernel. Further, each of the sub-stages may be divided into a plurality of sub-unit stages. For example, the initialization of the hardware device includes initialization of a controller, initialization of a register, and the like. Thus, the startup process of the BootLoader includes a plurality of stages, each of which may include a plurality of sub-stages, and each of the sub-stages may in turn include a plurality of sub-unit stages.
In an application of the startup process of the BootLoader, each of the sub-unit stages in the startup process of the BootLoader can be encapsulated as a function module. As such, the BootLoader includes a plurality of function modules, and the startup procedure of the BootLoader refers to a process in which each of the function modules starts up in sequence.
Further, in the embodiment of the present disclosure, one or more target function modules may be determined from a plurality of function modules included in the BootLoader, and the execution process information of each of the one or more target function modules may be obtained in the startup process of the BootLoader. Alternatively, each of the function modules or a portion of the function modules included in the BootLoader may be set as the target function module in advance by the user. In addition, the user can dynamically set the target function module according to actual service requirements, which means that the target function module is variable and can be set according to user requirements. In the same BootLoader, the target function module may be different during different times of startup of the BootLoader, which is not limited in the embodiment of the present disclosure.
As an alternative embodiment, the execution process information of the target function module may include a start execution time and an end execution time of the target function module. How to implement the obtaining of the start execution time and the end execution time of the target function module included in the BootLoader in the startup process of the BootLoader is described below in embodiments shown in
As another alternative embodiment, the execution process information of the target function module may include execution consumption time of the target function module. How to implement the obtaining of the execution consumption time of the target function module included in the BootLoader in the startup process of the BootLoader is described below in embodiments shown in
In embodiments of the present disclosure, after the execution process information of the target function module included in the BootLoader is obtained, the obtained execution process information may be written into a designated storage medium. Alternatively, the designated storage medium may be a partition in an EMMC of an embedded device. For example, as shown in
At step 102, an execution state of the target function module may be determined according to the obtained execution process information of the target function module when a trigger signal of the BootLoader is detected.
As an alternative embodiment, the trigger signal may be used to indicate successful startup of the BootLoader. When the BootLoader is successfully started up, the system can be normally started up. Based on this, in the step 102, when it is detected that the BootLoader is successfully started up, the execution process information of each of the target function modules stored in the designated storage medium can be obtained, and further, the execution state of each of the target function modules can be determined according to the execution process information of the target function module. Specifically, the execution process information can be obtained by an application program installed in an embedded device.
Specifically, if the execution process information includes the start execution time and the end execution time of the target function module, the execution time of the target function module is determined by the following equation (1) for each of the target function modules.
Where T represents execution consumption time, t1 represents an end execution time, and t2 represents a start execution time.
Then, for each of the target function modules, the execution consumption time of the target function module is compared with a timeout threshold corresponding to the target function module. When it is determined that a magnitude relationship between the execution consumption time and the timeout threshold meets a first preset condition, for example, when the execution consumption time is less than or equal to the timeout threshold, it means that the execution consumption time of the target function module is within an expected range, so that it can be determined that the execution state of the target function module is normal execution. On the contrary, when it is determined that the magnitude relationship between the execution consumption time and the timeout threshold satisfies a second preset condition, for example, when the execution consumption time is greater than the timeout threshold, it means that the execution consumption time of the target function module exceeds the expected range, and therefore it can be determined that the execution state of the function module is timeout execution. It should be noted that in an application, different timeout thresholds may be set for different target function modules according to actual conditions.
For each of the target function modules, if the execution process information includes execution consumption time of the target function module, then the execution state of the target function module may be determined by comparing the execution consumption time of the target function module with a timeout threshold corresponding to the target function module.
In addition, in an application, the embedded device may further transmit the obtained execution process information of each of the target function modules included in the BootLoader to an external device, such as a cloud platform corresponding to an application program, through the application program, and the external device determines the execution state of each of the target function modules according to the received execution process information of the target function module included in the BootLoader.
As another alternative embodiment, the trigger signal is used to indicate startup failure of the BootLoader. Under the conditions of startup failure of the BootLoader, the system cannot be started up normally. In this case, the execution state information of each of the target function modules stored in the designated storage medium cannot be obtained by the application program installed in the embedded device according to the description in the above embodiments. In this case, the execution process information stored in the designated storage medium can be obtained by means of an external diagnostic tool. It should be noted that, since startup of the BootLoader fails, the execution process information of a portion of the target function modules possibly contained in the BootLoader is stored in the designated storage medium.
Specifically, in step 102, when the startup failure of the BootLoader is detected, an indication message indicating the startup failure of the BootLoader is generated and transmitted to the external device.
As an alternative implementation, after receiving the indication message, the external device may automatically call the diagnostic tool to transmit a data reading request to the embedded device. As another alternative implementation, after receiving the indication message, the external device may transmit a reminder message to the user to notify the user of the startup failure of the BootLoader, and then the user manually controls the external device to call the diagnostic tool to transmit the data reading request to the embedded device. Alternatively, the form of the reminder message includes, but is not limited to, an audio signal, an optical signal, a short message of a mobile phone, an email, and the like.
After receiving the data reading request, the embedded device transmits the execution process information stored in the designated storage medium to the external device, so that the external device determines the execution state of each of the target function modules included in the BootLoader according to the received execution process information.
As an alternative implementation, the external device may first determine whether the execution state of each of the target function modules is an execution success or an execution error according to the received execution process information, where if the external device receives the execution process information of a certain target function module, it may be determined that the execution state of the target function module is the execution success. On the contrary, if the external device does not receive the execution process information of a certain target function module, it may be determined that the execution state of the target function module is the execution error.
Further, for a target function module of which the execution state is the execution success, the external device may determine, according to the received execution process information of the target function module, whether the execution state of the target function module is timeout execution. Specifically, how to determine, according to the received execution process information of the target function module, whether the execution state of the target function module is timeout execution can refer to the above related description, which is not repeatedly described herein.
According to the technical solutions provided in the embodiments of the present disclosure, the execution process information of the target function module included in the BootLoader is obtained in the startup process of the BootLoader, and when the trigger signal of the BootLoader is detected, the execution state of the target function module is determined according to the obtained execution process information of the target function module, so as to obtain the execution process information of each target function module (i.e., each stage) included in the BootLoader in the startup process of the BootLoader, which can optimize the BootLoader startup procedure with the granularity of each stage included in the BootLoader startup procedure, thereby providing effective information for improving a startup speed of the embedded device. Further, even if the startup of the BootLoader fails, a stage in which an abnormality occurs in the startup process of the BootLoader can be determined according to the obtained execution process information, thereby providing effective information for fault location.
As can be seen from the above description, as one embodiment, the execution process information may include a start execution time and an end execution time. A specific implementation of the present embodiment is described below.
In the present embodiment, a first customization code may be inserted in advance at a start position of a code line of each of the target function modules and used to indicate obtaining of a system current time and writing the obtained system current time into the designated storage medium as the start execution time of the target function module, and a second customization code may be inserted in advance at a end position of the code line of each of the target function modules and used to indicate obtaining of the system current time and writing the obtained system current time into the designated storage medium as the end execution time of the target function module.
Based on this, as shown in
It should be understood that, after completing the execution of the first customization code normally, an original function code in the target function module will continue to be executed until the original function code is executed, and the second customization code inserted at the end position of the code line in the target function module is executed, to obtain the system current time and write the obtained system current time into the designated storage media as the end execution time of the target function module.
Further, as shown in
In the embodiment of the present disclosure, if the end execution time of the target function module cannot be written into the designated storage medium, it means that the execution process information of the target function module cannot be obtained.
Obtaining of the start execution time and the end execution time of each stage in the startup process of the BootLoader can be implemented in the embodiments shown in
As can be seen from the above description, as another embodiment, the execution process information may include execution consumption time. A specific implementation of the present embodiment is described below.
In the present embodiment, a third customization code may be inserted in advance at a start position of a code line of each of the target function modules and used to indicate that the timer is reset to zero and started, and a fourth customization code may be inserted in advance at an end position of the code line of each of the target function modules and used to indicate that the current timing of the timer is obtained and the obtained current timing is written into the designated storage medium as execution consumption time of the target function module.
Based on this, in step 101, as shown in
It should be understood that, after completing the execution of the third customization code normally, an original function code in the target function module will continue to be executed until the original function code is executed, and the fourth customization code inserted into the end position of the code line in the target function module is executed, to obtain a current timing of the timer and write the obtained current timing into the designated storage media as the end execution time of the target function module.
Further, as shown in
obtaining of the execution consumption time of each stage in the startup process of the BootLoader can be implemented through the procedure shown in
The information obtaining module 51 is configured for obtaining execution process information of a target function module included in a BootLoader in the BootLoader startup procedure.
The state determining module 52 is configured for determining an execution state of the target function module according to the obtained execution process information of the target function module when a trigger signal of the BootLoader is detected.
Optionally, the execution process information includes a start execution time and an end execution time; and the information obtaining module 51 includes (not shown):
Optionally, the execution process information includes execution consumption time; and the information obtaining module 51 includes (not shown):
Optionally, the state determining module 52 includes (not shown):
Optionally, the state determining module 52 includes (not shown):
As shown in
The memory 613 is used to store a computer program.
In an embodiment of the present disclosure, the processor 611 is configured to implement, when a program stored on the memory 613 is executed by the processor 611, the method for monitoring the BootLoader startup procedure described in any one of the above embodiments, where the method includes:
Yet another embodiment of the present disclosure further provides a computer readable storage medium having stored a computer program thereon which, when executed by a processor, implements the method for monitoring the BootLoader startup procedure described in any one of the above embodiments.
It should be noted that the terms “first” or “second” and the like, as used herein, are used herein only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between such entities or operations. 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 includes not only those elements but also other elements not expressly listed, or also includes elements inherent to such process, method, article, or apparatus. Without more limitations, an element defined by a statement “include at least one of” does not rule out additional identical elements included in a process, method, article, or apparatus that includes the element.
The foregoing description is merely illustrative of specific embodiments of the present disclosure, enabling those skilled in the art to understand or practice the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the generic principles defined herein may be practiced in other embodiments without departing from the spirit or scope of the present disclosure. Accordingly, the present disclosure is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Number | Date | Country | Kind |
---|---|---|---|
202110767666.X | Jul 2021 | CN | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/CN2022/094675 | 5/24/2022 | WO |