Timestamp synchronization method and apparatus across operating levels, chip, network interface card, device, medium and program product

Abstract

The application relates to a timestamp synchronization method and device across running levels, a chip, a network interface card, equipment, a medium and a program product. The method comprises the following steps: obtaining a first value of a clock cycle count recorded by a system counter since system startup, wherein the same system counter is used by firmware and an application program running at different running levels; in the case that a timestamp synchronization completion flag exists in shared memory, obtaining a second value and a first local timestamp saved by the application program from the shared memory; and obtaining a second local timestamp based on the first value, the second value and the first local timestamp. The method can realize accurate timestamp synchronization of different privilege levels.

Description

TECHNICAL FIELD

[0001] The present application relates to the chip technical field, in particular to a cross-operation-level timestamp synchronization method and device, chip, network interface card, equipment, medium and program product. BACKGROUND

[0002] Processor architectures, such as ARMv8 architecture, define 4 exception levels (EL0 ~ EL3), and different exception levels run different programs: BL31 is part of ARM Trusted Firmware (ATF), running in EL3, as a scheduling hub of the secure and non-secure world, providing basic runtime services such as PSCI, SCMI, etc.; BL32 runs in Secure EL1, providing trusted services, RAS reliability services, etc.; the Linux kernel runs at the Non-Secure EL1 (or EL2, if virtualization is enabled) level. User applications (APP) run at the Non-Secure EL0 (user mode) level.

[0003] In a complex chip software system based on the ARMv8 architecture, multiple runtime services (such as BL31, BL32, and Linux kernel) run at different privilege levels. Thus, when debugging, diagnosing faults, and performing performance profiling, the synchronization of timestamps at different privilege levels is required. SUMMARY

[0004] Therefore, it is necessary to provide a cross-operation-level timestamp synchronization method, device, chip, network interface card, equipment, medium, and program product capable of accurately synchronizing timestamps at different privilege levels.

[0005] In a first aspect, the present application provides a cross-operation-level timestamp synchronization method applied to firmware, the method comprising:

[0006] obtaining a first value of a clock cycle count recorded by a system counter since system startup, the firmware and application programs running at different operation levels using the same system counter;

[0007] in the case where a timestamp synchronization completion flag exists in the shared memory, obtaining the second value and the first local timestamp saved by the application program from the shared memory;

[0008] obtaining a second local timestamp based on the first value, the second value, and the first local timestamp.

[0009] In one embodiment, the obtaining of the second local timestamp based on the first value, the second value, and the first local timestamp comprises:

[0010] determining, based on the first value, the second value, and a frequency of the system counter, a number of seconds that the system has run since a time stamp synchronization;

[0011] converting the first local time stamp to a number of seconds of coordinated universal time;

[0012] obtaining, based on the number of seconds of coordinated universal time and the number of seconds that the system has run since the time stamp synchronization, a number of seconds of second coordinated universal time;

[0013] obtaining, based on the number of seconds of second coordinated universal time, a second local time stamp.

[0014] In one embodiment, the method further comprises:

[0015] storing the second local time stamp to an output log.

[0016] In one embodiment, the method further comprises:

[0017] converting the first value to seconds and nanoseconds in the case that a time stamp synchronization completion flag is not present in the shared memory;

[0018] storing the seconds and nanoseconds to an output log.

[0019] In one embodiment, the second value in the shared memory is a value of the system counter read by the application program, the first local time stamp in the shared memory is a time stamp converted by the application program based on a coordinated universal time of the system, and the time stamp synchronization completion flag in the shared memory is set in the shared memory after the second value and the first local time stamp are stored to the shared memory.

[0020] In a second aspect, the application further provides a time stamp synchronization method across running levels, applied to an application program, the method further comprising:

[0021] obtaining a second value of a clock cycle count recorded by a system counter since system startup and writing the second value to a shared memory, firmware and application programs running at different running levels using the same system counter;

[0022] obtaining a time stamp of coordinated universal time of the system, converting the time stamp of coordinated universal time to a first local time stamp, and storing the first local time stamp to the shared memory;

[0023] set a timestamp synchronization completion flag to the shared memory, wherein the timestamp synchronization completion flag is used to indicate that the firmware obtains the second value saved by the application and the first local timestamp from the shared memory in a case that the shared memory exists the timestamp synchronization completion flag; obtain a second local timestamp based on the first value, the second value and the first local timestamp, the first value being a first value of clock cycle counts recorded by a system counter since system startup.

[0024] In a third aspect, the present application provides a timestamp synchronization device across running levels, the device comprising:

[0025] a first value obtaining module, configured to obtain a first value of clock cycle counts recorded by a system counter since system startup, the firmware and the application running in different running levels using the same system counter;

[0026] a reading module, configured to obtain a second value saved by the application and a first local timestamp from the shared memory in a case that the shared memory exists the timestamp synchronization completion flag;

[0027] a second local timestamp generating module, configured to obtain a second local timestamp based on the first value, the second value and the first local timestamp.

[0028] In a fourth aspect, the present application provides a timestamp synchronization device across running levels, applied to an application, the device further comprising:

[0029] a second value obtaining module, configured to obtain a second value of clock cycle counts recorded by a system counter since system startup, and write the second value into a shared memory, the firmware and the application running in different running levels using the same system counter;

[0030] a storage module, configured to obtain a timestamp of coordinated universal time of a system, convert the timestamp of coordinated universal time into a first local timestamp, and store the first local timestamp into the shared memory;

[0031] a synchronization module, configured to set a timestamp synchronization completion flag to the shared memory, wherein the timestamp synchronization completion flag is used to indicate that the firmware obtains the second value saved by the application and the first local timestamp from the shared memory in a case that the shared memory exists the timestamp synchronization completion flag; obtain a second local timestamp based on the first value, the second value and the first local timestamp, the first value being a first value of clock cycle counts recorded by a system counter since system startup.

[0032] In a fifth aspect, the present application also provides a chip comprising a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any one of the above embodiments.

[0033] In a sixth aspect, the present application also provides a network interface card comprising a chip in any one of the above embodiments and a plurality of interfaces,

[0034] The chip processes data or communicates with the outside through the interfaces.

[0035] In a seventh aspect, the present application also provides a computer device comprising a network interface card in any one of the above embodiments, wherein the network interface card is used to process data or communicate with the outside.

[0036] In an eighth aspect, the present application also provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the method in any one of the above embodiments.

[0037] In a ninth aspect, the present application also provides a computer program product comprising a computer program, and the computer program is executed by a processor to implement the steps of the method in any one of the above embodiments.

[0038] The above cross-running level timestamp synchronization method, device, chip, network interface card, equipment, medium and program product, obtain a first value of clock cycle count recorded by a system counter since system startup, and the same system counter is used by firmware and application programs running at different running levels; in the case that a timestamp synchronization completion flag exists in the shared memory, obtain a second value saved by the application program and a first local timestamp from the shared memory; and obtain a second local timestamp based on the first value, the second value and the first local timestamp. In this way, the same counter is used by multiple running levels, which ensures that event records between different running time services and programs can be marked based on a unified time reference, realizes accurate timestamp synchronization of different privilege levels, and constructs a global time sequence reference based on the system counter, without the need to additionally increase a hardware timer, thereby avoiding chip area and power consumption overheads. BRIEF DESCRIPTION OF DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the description of the embodiments of the present application or the related art will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0040] Figure 1a flowchart of a method for timestamp synchronization across runlevels in one embodiment;

[0041] Figure 2 a flowchart of a method for timestamp synchronization across runlevels in one embodiment;

[0042] Figure 3 a flowchart of a method for timestamp synchronization across runlevels in one embodiment;

[0043] Figure 4 a flowchart of a method for timestamp synchronization across runlevels in one embodiment;

[0044] Figure 5 a block diagram of a timestamp synchronization apparatus across runlevels in one embodiment;

[0045] Figure 6 a block diagram of a timestamp synchronization apparatus across runlevels in one embodiment;

[0046] Figure 7 an internal block diagram of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely used to explain the present application and should not be used to limit the present application.

[0048] It should be noted that the terms "first", "second", and the like used herein are used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish a first element from a second element. The terms "include" and "have" and any variations thereof used herein are intended to cover non-exclusive inclusion. The term "multiple" used herein refers to two or more. The term "and / or" used herein refers to one of the options or any combination of multiple options.

[0049] The cross-runtime-level timestamp synchronization method provided by the embodiments of the present application can be applied to a processor architecture, such as an ARMv8 architecture. The ARMv8 architecture includes different runtime levels, wherein runtime level EL3, BL31 (Boot Loader Stage 3-1, runtime firmware) is part of the ARM Trusted Firmware (ATF, ARM security) and runs at this runtime level as a scheduling hub between the secure and non-secure worlds, providing basic runtime services such as PSCI (Power State Coordination Interface, power state coordination interface), SCMI (System Control and Management Interface, system control and management interface), and the like; runtime level Secure EL1, BL32 (Boot Loader Stage 3-2, executable environment) runs at this runtime level and provides trusted services, RAS reliability services, and the like; and the Linux kernel runs at runtime level Non-Secure EL1 (or EL2 if virtualization is enabled). Applications (APP) run at runtime level Non-Secure EL0 (user mode).

[0050] Therefore, there are multiple runtime services (such as BL31, BL32, the Linux kernel, and applications) running at different privilege levels, and in order to achieve timestamp synchronization of the different runtime levels described above, the present application provides a cross-runtime-level timestamp synchronization method. For ease of description, BL31 and BL32 are implemented consistently and collectively referred to as firmware.

[0051] In an exemplary embodiment, as shown in Figure 1 a cross-runtime-level timestamp synchronization method is provided, which is described below by taking the firmware as an example. The method includes the following steps S102 to S106. Wherein:

[0052] S102: obtaining a first value of a clock cycle count recorded by a system counter since system startup, and the firmware, the kernel, and the applications running at different runtime levels use the same system counter.

[0053] The system counter is a counter of a system corresponding to the ARMv8 architecture, and the firmware, the kernel, and the applications use the same system counter to record timestamps.

[0054] When the firmware needs to generate a log or perform other services that require timestamp recording, it can obtain the first value of the clock cycle count recorded by the system counter since system startup, for example, read cntpct_el0 to obtain the clock cycle count since system startup.

[0055] S104: In the case that the time stamp synchronization completion flag exists in the shared memory, the second value saved by the application program and the first local time stamp are obtained from the shared memory.

[0056] The time stamp synchronization completion flag, the second value, and the first local time stamp are stored in the shared memory. The time stamp synchronization completion flag, the second value, and the first local time stamp are generated when the application program performs clock synchronization and are stored in the shared memory.

[0057] In some optional embodiments, the second value in the shared memory is the value of the system counter read by the application program, the first local time stamp in the shared memory is the time stamp converted by the application program based on the time of the system's coordinated universal time, and the time stamp synchronization completion flag in the shared memory is set in the shared memory after the second value and the first local time stamp are stored in the shared memory.

[0058] Specifically, when the application program needs to store a log or other business that requires a time stamp, the second value of the system counter is read and stored in the shared memory, then the coordinated universal time is read and converted into the first local time stamp, the first local time stamp is stored in the shared memory, and the time stamp synchronization completion flag is set in the shared memory.

[0059] If the time stamp synchronization completion flag can be obtained, it indicates that the synchronization is completed, so the synchronization of the time stamp can be performed, that is, the firmware can obtain the second value and the first local time stamp.

[0060] S106: The second local time stamp is obtained based on the first value, the second value, and the first local time stamp.

[0061] In the case that the time stamp synchronization completion flag exists, the firmware can obtain the second local time stamp based on the first value, the second value, and the first local time stamp.

[0062] The above cross-running-level time stamp synchronization method obtains the first value of the clock cycle count recorded by the system counter since the system starts, and the firmware and the application program running at different running levels use the same system counter. In the case that the time stamp synchronization completion flag exists in the shared memory, the second value saved by the application program and the first local time stamp are obtained from the shared memory. The second local time stamp is obtained based on the first value, the second value, and the first local time stamp. In this way, multiple running levels use the same counter, ensuring that the event records between different running services and programs can be marked based on a unified time reference, realizing accurate synchronization of time stamps of different privilege levels, and constructing a global time sequence reference based on the system counter, without the need to additionally increase a hardware timer, avoiding chip area and power consumption overheads.

[0063] In some optional embodiments, the above cross-running-level time stamp synchronization method is combined withFigure 2 The timestamp synchronization step, i.e. obtaining the second local timestamp based on the first value, the second value and the first local timestamp, comprises:

[0064] S202: determining the number of seconds that the system has run since the timestamp synchronization based on the first value, the second value and the frequency of the system counter.

[0065] Wherein the obtained first value of the system counter is denoted as current_timer, the second value of the system counter reserved in the shared memory is denoted as base_timer, the number of clock cycles that the system has run since the timestamp synchronization is denoted as delta_timer, and the number of seconds that the system has run since the timestamp synchronization is denoted as delta_sec, which is obtained by dividing the delta_timer by the frequency of the counter, denoted as freq, and the formula is as follows:

[0066] delta_sec=(current_timer-base_timer) / freq

[0067] S204: converting the first local timestamp into the number of seconds of the first coordinated universal time.

[0068] S206: obtaining the number of seconds of the second coordinated universal time based on the number of seconds of the first coordinated universal time and the number of seconds that the system has run since the timestamp synchronization.

[0069] In the embodiment, the mktime is called to convert the first local timestamp in the shared memory into the number of UTC seconds, i.e. the number of seconds of the first coordinated universal time, and then the number of seconds of the second coordinated universal time is obtained by adding the delta_sec.

[0070] S208: obtaining the second local timestamp based on the number of seconds of the second coordinated universal time.

[0071] In the embodiment, the current UTC seconds are converted into the second local timestamp by calling the time_to_tm.

[0072] In some optional embodiments, the method further comprises: storing the second local timestamp to an output log, i.e. the second local timestamp can be converted into a string in the present application, which is output together with the log.

[0073] In the above embodiments, the ARMv8 multi-level security system implements log timestamp synchronization between firmware and various runtime programs and services such as Linux, significantly improving system debugging efficiency and online fault diagnosis capabilities. This solution ensures that event records between different runtime services and programs are annotated based on a unified time benchmark by using the same counter across multiple runtime levels. This timestamp synchronization mechanism not only accurately locates timing issues in interactions between different services and programs but also tracks the causal relationships between events, thereby significantly shortening the system fault diagnosis cycle and improving system reliability. Furthermore, this solution supports dynamically adjusting the timestamp synchronization strategy to adapt to performance requirements in different application scenarios, providing strong technical support for the development and maintenance of complex multi-level security systems.

[0074] In some alternative embodiments, the method further includes: converting the first value into seconds and nanoseconds if a timestamp synchronization completion flag is not present in the shared memory; and storing the seconds and nanoseconds in the output log.

[0075] If the timestamp is not synchronized, the local timestamp cannot be output. Therefore, the system counter value is converted to seconds and nanoseconds and output along with the log.

[0076] Specifically, the total time (seconds) = counter difference / counter frequency (Hz). To obtain higher precision, nanoseconds are usually calculated first: total time (nanoseconds) = (counter difference * 10^9) / counter frequency (Hz). Then, seconds and nanoseconds can be separated from nanoseconds: number of seconds = total time (nanoseconds) / 1000000000, and the remaining number of nanoseconds = total time (nanoseconds) % 1000000000.

[0077] Finally, the obtained seconds and nanoseconds are stored in the output log.

[0078] For ease of understanding, combined with Figure 3 As shown, Figure 3 This is a flowchart of the firmware timestamp synchronization steps in one embodiment. In this embodiment, after entering the firmware log printing entry point, the following steps are included:

[0079] Get the first value of the system counter: Read cntpct_el0 to get the clock cycle count since system startup (corresponding flowchart).

[0080] Get the timestamp synchronization completion flag from shared memory.

[0081] If the timestamp is not synchronized, the system counter value will be converted to seconds and nanoseconds and output along with the log.

[0082] If the time stamp is synchronized, a second value of the system counter saved by the application and a first local time stamp are obtained from the shared memory.

[0083] The first value of the system counter is converted into local time, which is printed together with the log, including:

[0084] The first value of the obtained counter (denoted as current_timer) is subtracted from the value of the system counter (denoted as base_timer) reserved in the shared memory to obtain the number of clock cycles that the system has run since the time stamp is synchronized, denoted as delta_timer, and the number of seconds that the system has run since the time stamp is synchronized (denoted as delta_sec) can be obtained by dividing delta_timer by the frequency of the counter (denoted as freq). The formula is as follows:

[0085] The first value of the obtained system counter (denoted as current_timer) is subtracted from the second value of the system counter (denoted as base_timer) reserved in the shared memory to obtain the number of clock cycles that the system has run since the time stamp is synchronized, denoted as delta_timer, and the number of seconds that the system has run since the time stamp is synchronized (denoted as delta_sec) can be obtained by dividing delta_timer by the frequency of the counter (denoted as freq). The formula is as follows:

[0086] delta_sec=(current_timer-base_timer) / freq

[0087] The first local time stamp in the shared memory is converted into UTC seconds (i.e. seconds of the first coordinated universal time) by calling mktime, and then the second coordinated universal time seconds can be obtained by adding delta_sec.

[0088] The current UTC seconds are converted into the second local time stamp by calling time_to_tm.

[0089] The second local time stamp is converted into a string, which is output together with the log.

[0090] In an exemplary embodiment, as shown in Figure 4 , a cross-running-level time stamp synchronization method is provided, which is applied to the application in the above example, including the following steps S402 to S406. Among them:

[0091] S402: Obtain a second value of the clock cycle count recorded by the system counter since the system starts, and write the second value into the shared memory, and the same system counter is used by the firmware and the application running in different running levels.

[0092] Wherein the application program acquires the second value of the coefficient counter when it needs to print the log, reads cntvct_el0, acquires the clock cycle count since system startup, and writes the second value of the system counter to the shared memory.

[0093] S404: Acquire the coordinated universal time timestamp of the system, convert the coordinated universal time timestamp into a first local time timestamp, and store the first local time timestamp to the shared memory.

[0094] Acquire the coordinated universal time timestamp of the system, for example, call clock_gettime to acquire the high-precision system UTC timestamp.

[0095] Convert the coordinated universal time timestamp into a first local time timestamp struct tm by localtime_r, and write the converted struct tm time structure to the shared memory area.

[0096] Specifically, first convert the coordinated universal time timestamp, i.e., the UTC second, into a determined UTC time (including year, month, day, hour, minute, and second). Then, according to the offset of the local time zone, add or subtract the UTC time to obtain the final first local time timestamp.

[0097] S406: Set the timestamp synchronization completion flag to the shared memory, wherein the timestamp synchronization completion flag is used to indicate that the firmware acquires the second value and the first local time timestamp saved by the application program from the shared memory in the case that the shared memory exists the timestamp synchronization completion flag; based on the first value, the second value, and the first local time timestamp, obtain the second local time timestamp, and the first value is the first value of the clock cycle count since system startup recorded by the system counter.

[0098] After storing the second value and the first local time timestamp to the shared memory, also set the timestamp synchronization completion flag to the shared memory, so as to facilitate the firmware to realize timestamp synchronization.

[0099] For the convenience of understanding, give an example of the log with and without timestamp synchronization:

[0100] Timestamp not synchronized:

[0101] The firmware log sample is as follows, only showing the absolute time since system startup.

[0102]

[0103] After timestamp synchronization:

[0104] The firmware log is as follows, showing the local time.

[0105]

[0106] The Linux kernel log is as follows, showing the local time:

[0107]

[0108] Generally, the firmware detects events that need to be reported to the Linux kernel. After implementing, for example, the cross-running-level timestamp synchronization of the firmware and the Linux kernel using the cross-running-level timestamp synchronization method provided in the present application, it can be ensured that the events recorded by the firmware and the kernel are synchronized, facilitating problem positioning.

[0109] In the above embodiment, the global timing reference is constructed based on the system counter cntpct_el0 of the armv8 architecture, without the need to additionally increase the hardware timer, thereby avoiding the chip area and power consumption overhead. The log timestamp synchronization between multiple different running levels and multiple different running time services and programs can also be achieved.

[0110] It should be understood that, although each step in the flowchart involved in each of the above embodiments is shown in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, at least part of the steps in the flowchart involved in each of the above embodiments can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these steps or stages is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or steps or stages in other steps. It can be understood that the steps in different embodiments can be freely combined as needed, and various non-contradictory schemes formed by the combination are within the scope of protection of the present application.

[0111] Based on the same inventive concept, the present application also provides a cross-running-level timestamp synchronization device for implementing the above-mentioned cross-running-level timestamp synchronization method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more cross-running-level timestamp synchronization device embodiments provided below can refer to the limitations of the cross-running-level timestamp synchronization method in the above text, which will not be repeated here.

[0112] In an exemplary embodiment, as shown in Figure 5 a cross-running-level timestamp synchronization device is provided, comprising: a first value acquisition module 501, a reading module 502, and a second local timestamp generation module 503, wherein:

[0113] The first value obtaining module 501 is configured to obtain a first value of a clock cycle count recorded by a system counter since system startup, and the firmware and the application program running at different running levels use the same system counter.

[0114] The reading module 502 is configured to obtain the second value and the first local timestamp saved by the application program from the shared memory in a case where the time stamp synchronization completion flag exists in the shared memory.

[0115] The second local timestamp generating module 503 is configured to obtain a second local timestamp based on the first value, the second value and the first local timestamp.

[0116] In some optional embodiments, the second local timestamp generating module 503 is specifically configured to determine a number of seconds during which the system runs since the time stamp synchronization based on the first value, the second value and a frequency of the system counter; convert the first local timestamp into a number of seconds of the first coordinated universal time; obtain a number of seconds of the second coordinated universal time based on the number of seconds of the first coordinated universal time and the number of seconds during which the system runs since the time stamp synchronization; and obtain the second local timestamp based on the number of seconds of the second coordinated universal time.

[0117] In some optional embodiments, the device further includes a log generating module configured to store the second local timestamp into an output log.

[0118] In some optional embodiments, the log generating module is further configured to convert the first value into seconds and nanoseconds in a case where the time stamp synchronization completion flag does not exist in the shared memory; and store the seconds and the nanoseconds into the output log.

[0119] In some optional embodiments, the second value in the shared memory is a value of the system counter read by the application program, the first local timestamp in the shared memory is obtained by converting a time stamp of the coordinated universal time of the system by the application program, and the time stamp synchronization completion flag in the shared memory is set in the shared memory after the second value and the first local timestamp are stored into the shared memory.

[0120] In an exemplary embodiment, as shown in FIG. 6, Figure 6 a cross-running-level time stamp synchronization device is provided, which includes a second value obtaining module 601, a storage module 602 and a synchronization module 603, wherein:

[0121] The second value obtaining module 601 is configured to obtain a second value of a clock cycle count recorded by a system counter since system startup, and write the second value into a shared memory, and the firmware and the application program running at different running levels use the same system counter.

[0122] The storage module 602 is configured to acquire a time stamp of coordinated universal time of the system, convert the time stamp of coordinated universal time into a first local time stamp, and store the first local time stamp into the shared memory.

[0123] The synchronization module 603 is configured to set a time stamp synchronization completion flag into the shared memory, where the time stamp synchronization completion flag is used to indicate that the firmware acquires the second value saved by the application program and the first local time stamp from the shared memory in a case where the firmware determines that the shared memory contains the time stamp synchronization completion flag; and obtain a second local time stamp based on the first value, the second value, and the first local time stamp, where the first value is a first value of a clock cycle count recorded by the system counter since the system is started.

[0124] The above various modules in the cross-operation-level time stamp synchronization apparatus can be implemented by software, hardware, or a combination thereof, in whole or in part. The above various modules can be embedded in or independent of a processor in a computer device in a hardware form, or can be stored in a memory in the computer device in a software form, so as to be called and executed by the processor to perform the operations corresponding to the above various modules.

[0125] In an exemplary embodiment, a computer device, which can be a terminal, has an internal structure as shown in Figure 7 The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, the memory, and the input / output interface are connected through a system bus, and the communication interface, the display unit, and the input device are connected to the system bus through the input / output interface. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is configured to exchange information between the processor and external devices. The communication interface of the computer device, such as a network interface card, is configured to perform wired or wireless communication with external terminals, and the wireless communication can be implemented through WIFI, mobile cellular network, near field communication (NFC), or other technologies. The computer program is executed by the processor to implement a cross-operation-level time stamp synchronization method. The display unit of the computer device is configured to form a visually visible picture, which can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or can be a key, a trackball, or a touchpad arranged on the shell of the computer device, or can be an external keyboard, a touchpad, a mouse, or the like.

[0126] Those skilled in the art can understand that Figure 7 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0127] In an exemplary embodiment, a chip is provided, including a memory and a processor, the memory storing a computer program, and the processor implementing the steps of the method in any one of the above embodiments when executing the computer program.

[0128] In an exemplary embodiment, a network interface card is provided, including a chip and a plurality of interfaces as in any one of the above embodiments, and the chip processes data or communicates externally through the interfaces.

[0129] In an embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor implementing the steps of the above method embodiments when executing the computer program.

[0130] In an embodiment, a computer readable storage medium is provided, storing a computer program, and the computer program implements the steps of the above method embodiments when executed by a processor.

[0131] In an embodiment, a computer program product is provided, including a computer program, and the computer program implements the steps of the above method embodiments when executed by a processor.

[0132] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., without being limited thereto.

[0133] The technical features of the above embodiments can be combined in any manner. To make the description concise, all possible combinations of the technical features in the above embodiments are not described, but as long as the combinations of the technical features do not exist contradictions, they should be considered as the scope of the present application.

[0134] The above-described embodiments are merely illustrative of several embodiments of the present application, and the description is relatively specific and detailed, but should not be understood as a limitation on the scope of the patent. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are all within the scope of the present application. Therefore, the scope of protection of the present application should be subject to the appended claims.

Claims

1. A method of timestamp synchronization across runlevels, comprising: The method applied to firmware comprises: obtaining a first value of a clock cycle count recorded by a system counter since system startup, the firmware and the application program running at different running levels using the same system counter; in the case that a time stamp synchronization completion flag exists in the shared memory, obtaining a second value saved by the application program and a first local time stamp from the shared memory; determining the number of seconds that the system has run since time stamp synchronization based on the first value, the second value and the frequency of the system counter; converting the first local time stamp into a first coordinated universal time (UTC) value; obtaining a second UTC value based on the first UTC value and the number of seconds that the system has run since time stamp synchronization; obtaining a second local time stamp based on the second UTC value; wherein the second value is the value of the system counter read by the application program, the first local time stamp is obtained by converting the time stamp of the coordinated universal time of the system, and the time stamp synchronization completion flag is set in the shared memory after the second value and the first local time stamp are stored in the shared memory.

2. The method of claim 1, wherein, The method further comprises: storing the second local time stamp into an output log.

3. The method of claim 1, wherein, The method further comprises: in the case that a time stamp synchronization completion flag does not exist in the shared memory, converting the first value into seconds and nanoseconds; storing the seconds and nanoseconds into an output log.

4. A method of timestamp synchronization across runlevels, comprising: The method applied to the application program further comprises: obtaining a second value of a clock cycle count recorded by a system counter since system startup, and writing the second value into a shared memory, the firmware and the application program running at different running levels using the same system counter; obtaining a time stamp of the coordinated universal time of the system, converting the time stamp of the coordinated universal time into a first local time stamp, and storing the first local time stamp into the shared memory; setting a time stamp synchronization completion flag into the shared memory, wherein the time stamp synchronization completion flag is used to indicate that the firmware obtains a second value saved by the application program and a first local time stamp from the shared memory in the case that the shared memory exists the time stamp synchronization completion flag; determining the number of seconds that the system has run since time stamp synchronization based on the first value, the second value and the frequency of the system counter; converting the first local time stamp into a first coordinated universal time (UTC) value; obtaining a second UTC value based on the first UTC value and the number of seconds that the system has run since time stamp synchronization; obtaining a second local time stamp based on the second UTC value; wherein the first value is the first value of the clock cycle count recorded by the system counter since system startup.

5. A time stamp synchronization apparatus across run levels, characterized by, The device comprises: a first value obtaining module, configured to obtain a first value of a clock cycle count recorded by a system counter since system startup, the firmware and the application program running at different running levels using the same system counter; a reading module, configured to obtain a second value saved by the application program and a first local time stamp from the shared memory in the case that a time stamp synchronization completion flag exists in the shared memory; The second local timestamp generation module is configured to determine the number of seconds that the system has run since the timestamp synchronization based on the first value, the second value, and the frequency of the system counter; convert the first local timestamp into the number of seconds of the first coordinated universal time; obtain the number of seconds of the second coordinated universal time based on the number of seconds of the first coordinated universal time and the number of seconds that the system has run since the timestamp synchronization; and obtain the second local timestamp based on the number of seconds of the second coordinated universal time. The second value is the value of the system counter read by the application program, and the first local timestamp is obtained by converting the timestamp of the coordinated universal time of the system based on the application program; and the timestamp synchronization completion flag is set in the shared memory after the second value and the first local timestamp are stored in the shared memory.

6. A time stamp synchronization apparatus across run levels, characterized by, The application is applied to an application program, and the apparatus further comprises: The second value acquisition module is configured to acquire a second value of a clock cycle count recorded by a system counter since system startup, and write the second value into a shared memory; and the firmware and the application program running at different running levels use the same system counter. The storage module is configured to acquire a timestamp of the coordinated universal time of the system, convert the timestamp of the coordinated universal time into a first local timestamp, and store the first local timestamp into the shared memory. The synchronization module is configured to set a timestamp synchronization completion flag into the shared memory, where the timestamp synchronization completion flag is used to indicate that the firmware acquires the second value and the first local timestamp saved by the application program from the shared memory in a case where it is determined that the shared memory has the timestamp synchronization completion flag. The second local timestamp generation module is configured to determine the number of seconds that the system has run since the timestamp synchronization based on the first value, the second value, and the frequency of the system counter; convert the first local timestamp into the number of seconds of the first coordinated universal time; obtain the number of seconds of the second coordinated universal time based on the number of seconds of the first coordinated universal time and the number of seconds that the system has run since the timestamp synchronization; and obtain the second local timestamp based on the number of seconds of the second coordinated universal time. The first value is a first value of a clock cycle count recorded by a system counter since system startup.

7. A chip comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 4.

8. A network interface card, comprising: The chip and a plurality of interfaces as claimed in claim 7, The chip processes data or communicates externally through the interfaces.

9. A computer device, comprising: The network interface card as claimed in claim 8 is used to process data or communicate externally.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 4.

11. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 4.

Images