Multi-core debugging method, device, system and storage medium

Abstract

The application discloses a multi-core debugging method, device and system and a storage medium, relates to the technical field of testing, and discloses a multi-core debugging method, which comprises the following steps: a BSP determines a currently started AP in an AP in a multi-core CPU; the BSP determines a first target AP in the started AP and determines a first information buffer area corresponding to the first target AP; the BSP acquires a target write pointer and a target read pointer corresponding to the first information buffer area; if the target read pointer is smaller than the target write pointer, the BSP reads target data in a two-dimensional array of the first information buffer area based on the target read pointer; the BSP stores the target data into an information set buffer area based on the first target AP; and the BSP outputs data in the information set buffer area based on a preset rule. The application realizes that all cores can output debugging information in parallel, so that the debugging of multi-core business logic in a UEFI environment is facilitated.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing, in particular to a multi-core debugging method, device, system and storage medium. BACKGROUND

[0002] The most important firmware in a computer is called BIOS (Basic Input / Output System), which is used to initialize hardware, manage hardware resources, shield platform characteristics, boot the operating system, and is a bridge connecting the basic hardware and system software of the computer. The development of BIOS has experienced two eras, the first era of BIOS is called legacy BIOS, and the second era of BIOS is called UEFI (Unified Extensible Firmware Interface) BIOS. UEFI BIOS is a firmware developed based on UEFI specification, sometimes referred to as UEFI firmware.

[0003] The UEFI environment refers to the firmware environment running after the IOS and before the operating system when the computer starts. The main features of the UEFI environment include supporting graphical interface, supporting multiple operating systems, supporting plug and play and secure boot. The application scenarios of the UEFI environment include system startup, hardware detection and system recovery. The current way of debugging and locating software code exceptions in the UEFI environment is to print debugging information to the serial port.

[0004] In the case of debugging multi-core parallel execution business logic in the UEFI environment, due to the limitations of the UEFI framework, when using the debugging method of printing debugging information to the serial port, multi-process scheduling management cannot be realized in the UEFI environment, and when multiple cores are running, the problem of resource competition cannot be handled. For example, due to the limitations of the UEFI framework, when the BSP (Bootstrap processor) and the AP (non-startup CPU) call the same function to print information, the BSP can normally print information, while the AP occurs an exception, resulting in that the debugging information during the execution of the AP cannot be viewed.

[0005] Therefore, how to realize the debugging of multi-core business logic in the UEFI environment is a problem to be solved at present.

[0006] The above content is only used to assist in understanding the technical solutions of the present application, and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0007] The main purpose of the present application is to provide a multi-core debugging method, device, system and storage medium, which aims to solve the technical problem of how to realize the debugging of multi-core business logic in the UEFI environment.

[0008] To achieve the above object, the application provides a multi-core debugging method applied to a multi-core CPU system in a UEFI environment, wherein the multi-core CPU system comprises a BSP and APs; the multi-core debugging method comprises the following steps:

[0009] The BSP determines a currently started AP in the APs in the multi-core CPU;

[0010] The BSP determines a first target AP in the started APs and determines a first information buffer corresponding to the first target AP;

[0011] The BSP acquires a target write pointer and a target read pointer corresponding to the first information buffer;

[0012] If the target read pointer is smaller than the target write pointer, the BSP reads target data in a two-dimensional array of the first information buffer based on the target read pointer;

[0013] The BSP stores the target data into an information collection buffer based on the first target AP;

[0014] The BSP outputs data in the information collection buffer based on a preset rule.

[0015] In an embodiment, the step of determining a currently started AP in the APs in the multi-core CPU by the BSP comprises the following steps:

[0016] Acquiring information management data corresponding to the BSP;

[0017] Determining a currently started AP in the non-started APs in the multi-core CPU based on enabling data in a data structure of the information management data.

[0018] In an embodiment, before the step of determining a currently started AP in the APs in the multi-core CPU by the BSP, the multi-core debugging method further comprises the following steps:

[0019] The BSP starts running and creates an information collection buffer corresponding to the BSP;

[0020] Acquiring an AP number corresponding to the non-started APs in the multi-core CPU;

[0021] Creating corresponding information buffers based on the AP number and allocating information buffers to each AP so that the information buffers correspond to the APs one by one.

[0022] In an embodiment, the step of outputting data in the information collection buffer based on a preset rule by the BSP comprises the following steps:

[0023] The BSP outputs data in the information set buffer, or the BSP outputs data in the information set buffer when the amount of data in the information set buffer reaches a preset data amount.

[0024] In an embodiment, the multi-core debugging method further comprises:

[0025] The second target AP determines a corresponding second information buffer, wherein the second information buffer is a two-dimensional array.

[0026] The second target AP determines a target one-dimensional array in the two-dimensional array of the second information buffer based on a write pointer corresponding to the second information buffer.

[0027] The second target AP writes debugging information in the target one-dimensional array in the two-dimensional array of the second information buffer.

[0028] In an embodiment, the step of the second target AP writing debugging information in the target one-dimensional array in the two-dimensional array of the second information buffer comprises:

[0029] The second target AP writes the debugging information in the target one-dimensional array based on the maximum character length and updates the write pointer.

[0030] If there is unwritten data in the debugging information, the second target AP returns to the step of determining the target one-dimensional array in the two-dimensional array of the second information buffer based on the write pointer corresponding to the second information buffer until the debugging information is written completely.

[0031] In addition, to achieve the above object, the present application further provides a multi-core debugging device, which comprises:

[0032] A first determining module is configured to determine a currently started AP in an AP in a multi-core CPU.

[0033] A second determining module is configured to determine a first target AP in the started AP and determine a first information buffer corresponding to the first target AP.

[0034] An obtaining module is configured to obtain a target write pointer and a target read pointer corresponding to the first information buffer.

[0035] A reading module is configured to read target data in a two-dimensional array of the first information buffer based on the target read pointer if the target read pointer is smaller than the target write pointer.

[0036] A storage module is configured to store the target data to an information set buffer based on the first target AP.

[0037] An output module is configured to output data in the information set buffer based on a preset rule.

[0038] In addition, to achieve the above object, the application further provides a multi-core debugging system, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the multi-core debugging method.

[0039] In addition, to achieve the above object, the application further provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the multi-core debugging method.

[0040] The one or more technical solutions provided by the application have at least the following technical effects:

[0041] The debugging information of each AP is output to the corresponding information buffer for storage, the BSP copies the debugging information in each information buffer to the information centralized buffer, and then the BSP and / or the AP can perform normal debugging information printing when the BSP and the AP call the same function to print the debugging information or multiple APs call the same function to print the debugging information, so that each core in the multi-core CPU is not affected by other cores and does not affect other cores, and all cores can output debugging information in parallel, thereby realizing debugging of multi-core business logic in the UEFI environment. BRIEF DESCRIPTION OF DRAWINGS

[0042] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the application and, together with the specification, serve to explain the principles of the application.

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0044] Figure 1 The flowchart provided by the multi-core debugging method of the application is provided.

[0045] Figure 2 The module structure diagram of the multi-core debugging device of the embodiment of the application is provided.

[0046] Figure 3 The device structure diagram of the hardware running environment involved in the multi-core debugging method in the embodiment of the application is provided.

[0047] The object implementation, functional characteristics and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are merely exemplary of the application and do not limit the application.

[0049] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the accompanying drawings and specific embodiments.

[0050] The main solution of the embodiment of the present application is: the BSP determines the current started AP in the AP in the multi-core CPU; the BSP determines a first target AP in the started AP, and determines a first information buffer corresponding to the first target AP; the BSP acquires a target write pointer and a target read pointer corresponding to the first information buffer; if the target read pointer is less than the target write pointer, the BSP reads target data in a two-dimensional array of the first information buffer based on the target read pointer; the BSP stores the target data to an information collection buffer based on the first target AP; and the BSP outputs data in the information collection buffer based on a preset rule.

[0051] At present, the most important firmware in a computer is called BIOS (Basic Input / Output System, basic input / output system), which is used for initializing hardware, managing hardware resources, shielding platform characteristics, booting an operating system, and is a bridge connecting the basic hardware and system software of the computer. The development of BIOS has experienced two eras, the first era of BIOS is called legacy BIOS, and the second era of BIOS is called UEFI (Unified Extensible Firmware Interface, Unified Extensible Firmware Interface) BIOS. UEFI BIOS is a firmware developed based on UEFI specification, sometimes referred to as UEFI firmware.

[0052] The UEFI environment refers to a firmware environment running after IOS and before the operating system when the computer starts. The main features of the UEFI environment include supporting a graphical interface, supporting multiple operating systems, supporting plug and play, and supporting secure boot. The application scenarios of the UEFI environment include system startup, hardware detection, and system recovery. The current way of debugging and positioning software code exceptions in the UEFI environment is mainly to print debug information to the serial port.

[0053] In the case of debugging multi-core parallel execution of business logic in a UEFI environment, due to the limitation of the UEFI framework, when a debugging method of printing debugging information to a serial port is adopted, multi-process scheduling management cannot be realized in the UEFI environment, and when multi-core is running, the problem of resource competition cannot be handled. For example, due to the limitation of the UEFI framework, when the BSP (Bootstrap processor, startup CPU) and the AP (non-startup CPU) call the same function to print information, the BSP can normally print information, while the AP abnormally, resulting in that the debugging information during the execution of the AP cannot be viewed.

[0054] Therefore, how to realize the debugging of multi-core business logic in the UEFI environment is a problem to be solved at present.

[0055] The present application provides a solution, which outputs the debugging information of each AP to the corresponding information buffer for storage, and the BSP copies the debugging information in each information buffer to the information centralized buffer, so that when the BSP and the AP call the same function to print the debugging information, or multiple APs call the same function to print the debugging information, the BSP and / or the AP can normally print the debugging information, so that each core in the multi-core CPU is not affected by other cores and does not affect other cores, and all cores can output debugging information in parallel, so as to realize the debugging of multi-core business logic in the UEFI environment.

[0056] It should be noted that the execution subject of the present embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a multi-core debugging system, etc. capable of realizing the above functions. The present embodiment and each of the following embodiments will be described below taking the multi-core debugging system as an example.

[0057] Based on this, the present embodiment provides a multi-core debugging method, which refers to Figure 1 , Figure 1 The flowchart of an embodiment of the multi-core debugging method of the present application is shown.

[0058] In the present embodiment, the multi-core debugging method comprises steps S110-S140:

[0059] Step S110, the BSP determines the currently started AP in the non-started core AP in the multi-core CPU;

[0060] Wherein, the BSP is the startup CPU in the multi-core CPU in the UEFI environment, and the AP (Application Processor, application CPU) is each NB CPU (Nonboot, non-startup CPU) in the multi-core CPU in the UEFI environment.

[0061] In the embodiment of the present application, when debugging the multi-core CPU in the UEFI environment, the running state of each AP in the multi-core CPU can be stored by using the information management data. For example, the running state of each AP is stored in the enable data Enable in the data structure of the information management data. For a certain AP, if the enable data corresponding to the AP in the data structure of the information management data is true, it is determined that the AP has been normally started and the AP has been currently associated with the corresponding information buffer. At this time, the BSP can read the data in the information buffer corresponding to the AP.

[0062] Further, in a possible implementation, the step S110 can include steps S111-S112.

[0063] In the step S111, the information management data corresponding to the BSP is acquired.

[0064] In the step S112, based on the enable data in the data structure of the information management data, the currently started AP in the non-started AP of the multi-core CPU is determined.

[0065] In the embodiment of the present application, the data structure of the information management data corresponding to the BSP can be created in advance. After each AP in the multi-core CPU is started, the BSP associates and binds the AP with the corresponding information buffer, so that the AP stores the corresponding data into the associated and bound information buffer. Specifically, the number of the AP can be associated and bound with the corresponding information buffer. At this time, the enable data Enable (Valid) in the data structure of the information management data is set to true. When reading the data, the BSP can determine the started AP according to the enable data in the data structure of the information management data.

[0066] Specifically, the BSP acquires the information management data corresponding to the BSP, and acquires the enable data of each AP in the multi-core CPU based on the data structure of the information management data. Based on each enable data, the currently started AP in the AP of the multi-core CPU is determined, that is, the target enable data with the true enable data is acquired. The AP corresponding to the target enable data is the currently started AP, that is, the started AP is the currently started and running AP and the AP has been associated and bound with the corresponding information buffer.

[0067] In the embodiment of the present application, in a possible implementation, before the step S110, the multi-core debugging method can further include steps S210-S230.

[0068] In the step S210, when the BSP is started and runs, the information set buffer corresponding to the BSP is created.

[0069] In step S220, the number of APs corresponding to the non-starting core AP in the multi-core CPU is obtained.

[0070] In step S230, the information buffer corresponding to the number of APs is created, and the information buffer is allocated to each AP, so that the information buffer corresponds to the AP one by one.

[0071] In the embodiment of the present application, in the UEFI environment, when the BSP in the multi-core CPU starts running, the BSP creates a corresponding information collection buffer Gather Buffer, and at the same time, the BSP obtains the number of APs corresponding to the non-starting core AP in the CPU. For example, the number of APs is N, and the APs include Core0, Core1, …, CoreN.

[0072] After obtaining the number of APs, the information buffer CoreBuf is created based on the number of APs. For example, the number of APs is N, and the BSP creates N information buffers. Then, the BSP allocates the information buffer to each AP, so that the information buffer corresponds to the AP one by one, that is, each AP is bound to a unique information buffer CoreBuf, for example, Core0Buf, Core1Buf, …, CoreNBuf are the information buffers corresponding to Core0, Core1, …, CoreN respectively.

[0073] It should be noted that after allocating the corresponding information buffer to each AP, the storage rule of the debugging information corresponding to the AP is configured, so that the AP stores the debugging information into the corresponding information buffer.

[0074] Additionally, it is to be noted that the information gather buffer is a two-dimensional array, and the information buffer CoreBuf is also a two-dimensional array, the two-dimensional array is composed of a plurality of one-dimensional arrays, each one-dimensional array can be used to store one piece of debugging information, the size of the one-dimensional array is the maximum capacity of one piece of input information, and the number of one-dimensional arrays is the total number of maximum input information. The capacity of the one-dimensional array is Length, and the capacity of the two-dimensional array of all information buffers is also Length to ensure information alignment. For example, for the information buffer Core0Buf of Core0, Core0Buf[0][0] represents the starting address of the first piece of information of the information buffer of Core0, and Core0Buf[i][0] represents the starting address of the ith piece of information of the information buffer of Core0. When the BSP reads the data in Core0Buf, the BSP will copy the information in Core0Buf[0][0] to the gather buffer with a length of Length, regardless of whether the length of the information in Core0Buf[0][0] is Length.

[0075] In this embodiment, the BSP allocates an independent information buffer for each Core (AP), each AP outputs its debugging information to the corresponding information buffer for storage, and then the BSP and / or the AP can perform normal debugging information printing when the BSP and the AP call the same function to print the debugging information or multiple APs call the same function to print the debugging information, so that each core in the multi-core CPU is not affected by other cores and does not affect other cores, and all cores can output debugging information in parallel, thereby facilitating the debugging of multi-core business logic in the UEFI environment.

[0076] In a feasible implementation, the multi-core debugging method can further include steps S310-S330.

[0077] In step S310, the second target AP determines the corresponding second information buffer, wherein the second information buffer is a two-dimensional array,

[0078] In step S320, the second target AP determines a target one-dimensional array in the two-dimensional array of the second information buffer based on a write pointer corresponding to the second information buffer,

[0079] In step S330, the second target AP writes the debugging information in the two-dimensional array of the second information buffer based on the target one-dimensional array.

[0080] In the present application, after the second target AP starts running, when the second target AP needs to store the debugging information, the second target AP first acquires the second information buffer corresponding to the second target AP, for example, the second information buffer corresponding to the second target AP can be acquired according to the number of the second target AP in each information buffer.

[0081] After the second information buffer is acquired, the second target AP determines a target one-dimensional array in the two-dimensional array of the second information buffer based on the write pointer corresponding to the second information buffer, and the target one-dimensional array is a one-dimensional array pointed to by the write pointer in the two-dimensional array of the second information buffer.

[0082] After the target one-dimensional array is determined, the second target AP writes the debugging information in the two-dimensional array corresponding to the second information buffer based on the target one-dimensional array, that is, the second target AP writes a piece of debugging information in the target one-dimensional array, and after the writing is completed, the write pointer is incremented by 1, so as to facilitate the writing of the subsequent debugging information. Further, in a feasible implementation manner, the step S330 can further include steps S331-S332.

[0083] In step S331, the second target AP writes the debugging information in the target one-dimensional array based on the maximum character length, and updates the write pointer.

[0084] In step S332, if there is unwritten data in the debugging information, the second target AP returns to execute the step of determining the target one-dimensional array in the two-dimensional array of the second information buffer based on the write pointer corresponding to the second information buffer, until the writing of the debugging information is completed.

[0085] In the embodiment of the present application, after the target one-dimensional array is determined, the second target AP writes the debugging information in the target one-dimensional array based on the maximum character length, specifically, the second target AP writes a piece of data in the debugging information in the target one-dimensional array, and the length of the written data is less than the maximum character length, after the writing is completed, the write pointer corresponding to the second information buffer is updated, that is, the write pointer is incremented by 1.

[0086] Then, it is determined whether there is unwritten data in the debugging information, if there is unwritten data in the debugging information, that is, the current debugging information is not completely written into the second information buffer, the second target AP determines the target one-dimensional array in the two-dimensional array of the second information buffer based on the write pointer corresponding to the second information buffer, that is, the second target AP determines a new target one-dimensional array based on the updated write pointer, so as to continue to write the unwritten debugging information in the target one-dimensional array.

[0087] It should be noted that the second target AP performs a zero operation on the target one-dimensional array once when writing data in the second information buffer corresponding to the target one-dimensional array, and writes the debugging information after the zero operation. For example, for the second information buffer Core0Buf of Core0, assuming that the memory size allocated to Core0Buf is 1MB, which is represented by a two-dimensional array as Core0Buf

[4096]

[256] , 4096 represents the maximum count value of one cycle of the write pointer, and 256 represents the maximum number of characters of one input string. Core0 writes the debugging information from the first position Core0Buf[0][0] of the buffer of Core0Buf the first time, performs a zero operation on Core0Buf[0][0] once, writes the debugging information after the zero operation, and then the write pointer of the buffer of Core0Buf is incremented by 1. The second time of writing the debugging information is at Core0Buf[1][0], the third time of writing the debugging information is at Core0Buf[2][0], and so on, until the write pointer is increased by 4096, and the write pointer becomes 0 to start writing from the first address of the information buffer.

[0088] In step S120, the BSP determines a target AP in the started APs, and determines a first information buffer corresponding to the target AP.

[0089] In this embodiment, after the started APs are acquired, the BSP determines a target AP in the started APs. The BSP can determine the target AP in the started APs according to the AP number, for example, the BSP can read the data in the information buffer corresponding to each AP at a time, and determine the target AP in the started APs according to the AP number at a time. In other implementation manners, the priority of each AP can be set, the BSP reads the data in the information buffer corresponding to each AP at a time, and determines the target AP in the started APs according to the priority at a time, for example, the AP with the highest priority in the started APs is taken as the target AP each time, and the target AP is excluded from the started APs until the data in the information buffer corresponding to all the started APs is read.

[0090] After the target AP is determined, the BSP determines the first information buffer corresponding to the target AP. Specifically, the BSP can determine the first information buffer in the information buffer according to the number of the target AP.

[0091] The BSP copies the data in the first information buffer to the information set buffer corresponding to the BSP.

[0092] In this embodiment, after the first information buffer is acquired, the BSP copies the data in the first information buffer to the information set buffer corresponding to the BSP.

[0093] In step S130, the BSP acquires the target write pointer and the target read pointer corresponding to the first information buffer.

[0094] In step S130, the BSP acquires the target write pointer and the target read pointer corresponding to the first information buffer.

[0095] In the embodiment, since each information buffer is a two-dimensional array, a write pointer and a read pointer can be set for the information buffer. The write pointer corresponds to a one-dimensional array in the two-dimensional array that currently needs to be written, and the read pointer corresponds to a one-dimensional array in the two-dimensional array that currently needs to be read. When the AP writes data in the information buffer, the write pointer is incremented by 1 after the data input of one one-dimensional array is completed. When the BSP reads data in the information buffer, the read pointer is incremented by 1 after the data read of one one-dimensional array is completed. Therefore, when the BSP reads data in the first information buffer, the BSP acquires the target write pointer and the target read pointer corresponding to the first information buffer.

[0096] After the target write pointer and the target read pointer are acquired, the BSP copies the data in the first information buffer to the information set buffer based on the target write pointer and the target read pointer. Specifically, the BSP determines whether there is unread data in the first information buffer based on the target write pointer and the target read pointer. When there is unread data in the first information buffer, the BSP copies the data in the first information buffer to the information set buffer based on the target read pointer. The BSP copies the data of the one-dimensional array in the first information buffer corresponding to the target read pointer to the information set buffer. Then, the target read pointer is incremented by 1, and the data of the one-dimensional array corresponding to the current target read pointer is again copied to the information set buffer, until the data in the first information buffer is read completely or a preset number of data is read (the number of times that the target read pointer is incremented by 1 is the preset number).

[0097] In step S140, if the target read pointer is less than the target write pointer, the BSP reads target data in the two-dimensional array of the first information buffer based on the target read pointer.

[0098] In step S150, the BSP stores the target data to the information set buffer based on the target AP.

[0099] In the embodiment, after the target write pointer and the target read pointer are acquired, the BSP determines the size relationship between the target read pointer and the target write pointer. If the target read pointer is equal to the target write pointer, it indicates that there is no unread data in the first information buffer at present. In this case, the BSP re-determines the target AP in the started AP.

[0100] In the embodiment of the present application, if the target read pointer is less than the target write pointer, the BSP reads target data in the two-dimensional array of the first information buffer based on the target read pointer, and stores the target data to the information collection buffer based on the first target AP. Specifically, the BSP can read one piece of data in each AP each time. At this time, the BSP reads data in the one-dimensional array corresponding to the target read pointer in the two-dimensional array of the first information buffer, obtains the target data, and stores the target data to the one-dimensional array of the two-dimensional array corresponding to the information collection buffer. Before writing to the information collection buffer, the BSP performs a zero operation on the one-dimensional array corresponding to the information collection buffer, and then stores the target data to the one-dimensional array of the two-dimensional array corresponding to the information collection buffer.

[0101] Then, the step of determining the first target AP in the started AP is returned to execute, that is, the first target AP is determined again in the started AP which has not read data, and the reading of the debugging information corresponding to the first target AP is continued. For example, the BSP reads the first piece of information from the information buffer Core0Buf of Core0, reads the first position Core1Buf[0][0] of the information buffer Core1Buf of Core1, then reads the first position Core2Buf[0][0] of the information buffer Core2Buf of Core2, and so on, until all the first positions Core*Buf[0][0] of the information buffers of all Cores are copied to the Gather Buffer. Each time the reading is completed, the read pointer of the information buffer Core2Buf of each Core2 is incremented by 1.

[0102] It can be understood that the BSP can also read multiple pieces of data or all the unread data in each AP each time. The BSP reads data in the one-dimensional array corresponding to the target read pointer in the two-dimensional array of the first information buffer, then the target read pointer is incremented by 1, and the data in the one-dimensional array corresponding to the target read pointer in the two-dimensional array is read again, until a preset number of pieces of data or all the unread data are read, the target data is obtained, and the BSP stores the target data to multiple one-dimensional arrays of the two-dimensional array corresponding to the information collection buffer in sequence, that is, one one-dimensional array stores one piece of debugging information.

[0103] In step S160, the BSP outputs the data in the information collection buffer based on a preset rule.

[0104] In another possible implementation, step S160 can include step S161:

[0105] In step S161, the BSP outputs the data in the information collection buffer at a timing, or outputs the data in the information collection buffer when the amount of data in the information collection buffer reaches a preset data amount.

[0106] In the embodiment, the BSP can output data in the information collection buffer in a timing manner. For example, a timing trigger event and a timing notification function can be set in advance. When the timing trigger event reaches the timing time, the timing notification function triggers a call to a file operation service protocol of UEFI to create or open a file to output data in the Gather Buffer to the file. The file can be saved in a U disk or a virtual U disk, or other storage media.

[0107] Alternatively, the BSP accumulates the amount of data in the information collection buffer. When the amount of data in the information collection buffer reaches a preset data amount, the BSP outputs data in the information collection buffer. For example, the BSP calls a file operation service protocol of UEFI to create or open a file to output data in the Gather Buffer to the file. Alternatively, the BSP calls a serial port to print data in the Gather Buffer to the serial port, and the information can be viewed on a host computer of a serial port tool. Alternatively, the BSP calls a display printing interface to output the information to a display to view the information.

[0108] In the embodiment, the BSP determines a currently started AP in the APs in the multi-core CPU. The BSP determines a first target AP in the started APs and determines a first information buffer corresponding to the first target AP. The BSP acquires a target write pointer and a target read pointer corresponding to the first information buffer. If the target read pointer is smaller than the target write pointer, the BSP reads target data in a two-dimensional array of the first information buffer based on the target read pointer. The BSP stores the target data to an information collection buffer based on the first target AP. The BSP outputs data in the information collection buffer based on a preset rule. The debugging information of each AP is output to the corresponding information buffer for storage. The BSP copies the debugging information in each information buffer to the information collection buffer. Thus, when the BSP and the AP call the same function to print the debugging information, or when multiple APs call the same function to print the debugging information, the BSP and / or the AP can normally print the debugging information. Thus, each core in the multi-core CPU is not affected by other cores and does not affect other cores. All cores can output the debugging information in parallel, so that the debugging of the multi-core business logic in the UEFI environment is realized.

[0109] The application further provides a multi-core debugging device. Please refer to Figure 2 The multi-core debugging device comprises:

[0110] A first determination module 10 is configured to determine a currently started AP in the APs in the multi-core CPU.

[0111] A second determination module 20 is configured to determine a first target AP in the started APs and determine a first information buffer corresponding to the first target AP.

[0112] The acquisition module 30 is configured to acquire a target write pointer and a target read pointer corresponding to the first information buffer.

[0113] The reading module 40 is configured to read target data in the two-dimensional array of the first information buffer based on the target read pointer if the target read pointer is less than the target write pointer.

[0114] The storage module 50 is configured to store the target data into the information set buffer based on the first target AP.

[0115] The output module 60 is configured to output data in the information set buffer based on a preset rule.

[0116] The multi-core debugging device provided in the present application adopts the multi-core debugging method in the above embodiments, and can solve the technical problem of how to realize debugging of multi-core service logic in a UEFI environment. Compared with the prior art, the multi-core debugging device provided in the present application has the same beneficial effects as the multi-core debugging method provided in the above embodiments, and other technical features in the multi-core debugging device are the same as the features disclosed in the above embodiments, which will not be repeated here.

[0117] The present application provides a multi-core debugging system, which comprises at least one processor and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-core debugging method in the above embodiment one.

[0118] Reference will be made to the following description Figure 3 which shows a structural schematic diagram of a multi-core debugging system suitable for implementing the embodiments of the present application. The multi-core debugging system in the embodiments of the present application can include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Description), PMPs (Portable Media Player), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 3 The multi-core debugging system shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0119] As Figure 3As shown, the multi-core debugging system can include a processing device 1001 (e.g., a central processor, a graphics processor, etc.) that can perform various appropriate actions and processes according to programs stored in a read only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. In the RAM 1004, various programs and data required for operation of the multi-core debugging system are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the multi-core debugging system to communicate with other devices wirelessly or by wire to exchange data. Although the multi-core debugging system having various systems is shown in the figure, it should be understood that all of the shown systems are not required to be implemented or possessed. More or less systems can be alternatively implemented or possessed.

[0120] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by a communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of embodiments of the present disclosure are performed.

[0121] The multi-core debugging system provided by the present disclosure adopts the multi-core debugging method in the above embodiments, and can solve the technical problem of how to implement debugging of multi-core business logic in a UEFI environment. Compared with the prior art, the multi-core debugging system provided by the present disclosure has the same beneficial effects as the multi-core debugging method provided by the above embodiments, and other technical features in the multi-core debugging system are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0122] It should be understood that various aspects of the disclosure can be implemented in hardware, software, firmware, or combinations thereof, to achieve the various aspects of the disclosure. In the description above, specific features, structures, materials or characteristics can be combined in any suitable manner without necessarily being limited to one or more embodiments or examples.

[0123] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any modifications or equivalents of the application should be construed as falling within the scope of the application. The scope of the application should be determined by the appended claims.

[0124] The application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., computer programs) for performing the multi-core debugging method in the above embodiments.

[0125] The computer readable storage medium provided by the application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection having one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present embodiment, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), etc., or any suitable combination thereof.

[0126] The above computer readable storage medium can be included in a multi-core debugging system; or can exist separately and not be assembled into a multi-core debugging system.

[0127] The computer readable storage medium carries one or more programs, when the one or more programs are executed by the multi-core debugging system, the multi-core debugging system is caused to: the BSP determines a currently started AP in the AP in the multi-core CPU; the BSP determines a first target AP in the started AP, and determines a first information buffer corresponding to the first target AP; the BSP acquires a target write pointer and a target read pointer corresponding to the first information buffer; if the target read pointer is less than the target write pointer, the BSP reads target data in a two-dimensional array of the first information buffer based on the target read pointer; the BSP stores the target data into an information collection buffer based on the first target AP; and the BSP outputs data in the information collection buffer based on a preset rule.

[0128] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0129] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may

[0130] The modules described in the embodiments of the present application can be implemented in the form of software or in the form of hardware. In some cases, the names of the modules do not constitute a limitation on the modules themselves.

[0131] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e., a computer program) for executing the multi-core debugging method described above, and can solve the technical problem of how to implement debugging of multi-core business logic in a UEFI environment. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the multi-core debugging method provided by the above embodiments, and will not be described here.

[0132] The present application also provides a computer program product comprising a computer program, which, when executed by a processor, implements the steps of the multi-core debugging method as described above.

[0133] The computer program product provided by the present application can solve the technical problem of how to implement debugging of multi-core business logic in a UEFI environment. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the multi-core debugging method provided by the above embodiments, and will not be described here.

[0134] The above only describes some embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields based on the technical concept of the present application, and the contents of the present application specification and drawings are included in the patent protection scope of the present application.

Claims

1. A multi-core debugging method, characterized by, The application is applied to a multi-core CPU system in a UEFI environment, and the multi-core CPU system comprises a BSP and APs, the BSP is a starting CPU in the multi-core CPU in the UEFI environment, and the APs are various non-starting CPUs in the multi-core CPU in the UEFI environment. The multi-core debugging method comprises the following steps: The BSP creates an information set buffer corresponding to the BSP when starting to run; The number of APs corresponding to the non-starting cores in the multi-core CPU is obtained; The information buffer corresponding to the number of APs is created, and the information buffer is allocated to each AP, so that the information buffer corresponds to the AP one by one; The BSP determines the currently started AP in the AP in the multi-core CPU; The BSP determines a first target AP in the started AP and a first information buffer corresponding to the first target AP; The BSP obtains a target write pointer and a target read pointer corresponding to the first information buffer; If the target read pointer is smaller than the target write pointer, the BSP reads target data in the two-dimensional array of the first information buffer based on the target read pointer; The BSP stores the target data into the information set buffer based on the first target AP; The BSP outputs the data in the information set buffer based on a preset rule.

2. The multi-core debugging method of claim 1, wherein, The step that the BSP determines the currently started AP in the AP in the multi-core CPU comprises the following steps: The information management data corresponding to the BSP is obtained; The currently started AP in the non-starting core AP of the multi-core CPU is determined based on the enabling data in the data structure of the information management data.

3. The multi-core debugging method of claim 1, wherein, The step that the BSP outputs the data in the information set buffer based on a preset rule comprises the following steps: The BSP outputs the data in the information set buffer at a time, or the BSP outputs the data in the information set buffer when the data amount in the information set buffer reaches a preset data amount.

4. The multi-core debugging method according to any one of claims 1 to 3, wherein, The multi-core debugging method further comprises the following steps: The second target AP determines a corresponding second information buffer, wherein the second information buffer is a two-dimensional array; The second target AP determines a target one-dimensional array in the two-dimensional array of the second information buffer based on a write pointer corresponding to the second information buffer; The second target AP writes debugging information in the two-dimensional array of the second information buffer based on the target one-dimensional array.

5. The multi-core debugging method of claim 4, wherein, The step that the second target AP writes the debugging information in the two-dimensional array of the second information buffer based on the target one-dimensional array comprises the following steps: The second target AP writes the debugging information in the target one-dimensional array based on the maximum character length, and updates the write pointer; If there is unwritten data in the debugging information, the second target AP returns to execute the step that the second target AP determines the target one-dimensional array in the two-dimensional array of the second information buffer based on the write pointer corresponding to the second information buffer, until the debugging information is written completely.

6. A multi-core debugging apparatus characterized by comprising: The application is applied to a multi-core CPU system in a UEFI environment, and the multi-core CPU system comprises a BSP and APs, the BSP is a starting CPU in the multi-core CPU in the UEFI environment, and the APs are various non-starting CPUs in the multi-core CPU in the UEFI environment, and the multi-core debugging device comprises: The first determining module is configured to determine a currently started AP in the APs in the multi-core CPU. The second determining module is configured to determine a first target AP in the started APs and determine a first information buffer corresponding to the first target AP. The obtaining module is configured to obtain a target write pointer and a target read pointer corresponding to the first information buffer. The reading module is configured to read target data in a two-dimensional array of the first information buffer based on the target read pointer if the target read pointer is less than the target write pointer. The storage module is configured to store the target data into an information collection buffer based on the first target AP. The output module is configured to output data in the information collection buffer based on a preset rule. The multi-core debugging device is further configured to: create an information collection buffer corresponding to the BSP when the BSP is started and runs; obtain an AP number corresponding to a non-started core AP in the multi-core CPU; create a corresponding information buffer based on the AP number and allocate information buffers to each AP, so that the information buffers correspond to the APs one by one.

7. A multi-core debugging system, characterized by comprising: The multi-core debugging system includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the multi-core debugging method according to any one of claims 1 to 5.

8. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program. When the computer program is executed by the processor, the steps of the multi-core debugging method according to any one of claims 1 to 5 are implemented.

Images