Method and apparatus for storing firmware functions

Abstract

The application provides a storage method and device of firmware functions, and relates to the field of chip testing. The method comprises the following steps: obtaining initial firmware data, and transmitting the initial firmware data to a target chip for storage; sending a target test instruction to the target chip, and obtaining test data returned by the target chip; determining whether the initial storage area of the firmware functions needs to be adjusted according to the test data; in the case that it is determined that the initial storage area of the firmware functions needs to be adjusted, adjusting the initial storage area of the firmware functions according to the calling association of each firmware function in the target scene test indicated by the test data, and obtaining target firmware data. The application solves the problem that in the related art, the frequent reading of the firmware program of the NAND Code Block and the refreshing of the firmware program to the RAM will affect the overall efficiency of program execution, and will affect the performance of the eMMC storage chip.

Description

Technical Field

[0001] This application relates to the field of chip testing, and more specifically, to a method and apparatus for storing firmware functions. Background Technology

[0002] With the widespread use of eMMC (embedded Multi Media Card) memory chips in terminal products such as TVs, set-top boxes, tablets, and mobile phones, the requirements for the performance and reliability of eMMC memory chips are becoming increasingly stringent. Among these requirements, the most important is to ensure the stability and reliability of the data stored in the eMMC memory chip.

[0003] eMMC memory chips consist of an ARM (Advanced RISC Machine) CPU (Central Processing Unit) as the controller, plus NAND Flash (Not AND Flash Memory). The ARM CPU runs the controller software, usually called firmware.

[0004] The main function of firmware is to manage bad blocks in NAND Flash, perform garbage collection (GC), provide early warnings, improve performance and lifespan, and ensure the reliable use of NAND Flash. The firmware running on the main controller inside the eMMC storage chip is crucial, and its speed and performance directly affect the product's competitiveness. In addition to being affected by hardware resource configuration and firmware algorithms, the performance of eMMC storage chips is also influenced by the execution efficiency of the firmware program and the scheduling strategy of the firmware algorithm at a deeper level.

[0005] In other words, frequently reading NAND code blocks and refreshing firmware programs into RAM (Random Access Memory) can affect the overall efficiency of program execution and impact the performance of eMMC memory chips. Summary of the Invention

[0006] This application provides a method, apparatus, electronic device, and storage medium for storing firmware functions, which can solve the problem in related technologies that frequent reading of NAND Code Blocks and flashing of firmware programs into RAM can affect the overall efficiency of program execution and the performance of eMMC storage chips. The technical solutions are as follows:

[0007] According to one aspect of this application, a method for storing firmware functions is applied to a test device used to test a target chip. The method includes: acquiring initial firmware data and transferring the initial firmware data to the target chip for storage; the initial firmware data includes multiple firmware functions and corresponding initial storage areas; sending a target test instruction to the target chip and acquiring test data returned by the target chip; the target test instruction instructs the target chip to call the corresponding firmware function to perform at least one target scenario test; determining whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data; if it is determined that the initial storage area of ​​the firmware function needs to be adjusted, adjusting the initial storage area of ​​the firmware function according to the call association of each firmware function in the target scenario test indicated by the test data, to obtain target firmware data; the target firmware data includes each firmware function and its adjusted target storage area.

[0008] According to one aspect of this application, a firmware function storage device is deployed in a test device for testing a target chip; the device includes: a data acquisition module for acquiring initial firmware data and transmitting the initial firmware data to the target chip for storage; the initial firmware data includes multiple firmware functions and corresponding initial storage areas; an instruction transmission module for sending a target test instruction to the target chip and acquiring test data returned by the target chip; the target test instruction instructs the target chip to call the corresponding firmware function to perform at least one target scenario test; a region determination module for determining whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data; and a region adjustment module for adjusting the initial storage area of ​​the firmware function according to the call association of each firmware function in the target scenario test indicated by the test data, if it is determined that the initial storage area of ​​the firmware function needs to be adjusted, to obtain target firmware data; the target firmware data includes each firmware function and its adjusted target storage area.

[0009] In the above technical solution, the testing equipment can send the initial firmware data to the target chip for storage and control the target chip to perform target scenario tests to obtain test data. Based on the test data, it determines whether the initial storage location of each firmware function needs to be adjusted. If the initial storage location needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test indicated by the test data, thereby improving the calling efficiency of the firmware function. This effectively solves the problem in related technologies where frequent reading of NAND CodeBlock firmware programs and refreshing them into RAM affects the overall efficiency of program execution and the performance of eMMC storage chips. Attached Figure Description

[0010] Figure 1 This is a schematic diagram based on the implementation environment involved in this application;

[0011] Figure 2 This is a hardware structure diagram of an electronic device according to an exemplary embodiment;

[0012] Figure 3 This is a flowchart illustrating a method for storing firmware functions according to an exemplary embodiment;

[0013] Figure 4 yes Figure 3 A schematic diagram illustrating the specific implementation of each firmware function involved in the corresponding embodiment in the target chip storage;

[0014] Figure 5 yes Figure 3 A flowchart of step 350 in one embodiment corresponds to the following example;

[0015] Figure 6 This is a schematic diagram illustrating the specific implementation of the optimized storage area distribution of firmware functions in an eMMC memory chip within an application scenario.

[0016] Figure 7 This is a structural block diagram of a firmware function storage device according to an exemplary embodiment. Detailed Implementation

[0017] The present invention will now be described in further detail with reference to specific embodiments and accompanying drawings. Similar elements in different embodiments are referred to by associated similar element reference numerals. In the following embodiments, many details are described to facilitate a better understanding of this application. However, those skilled in the art will readily recognize that some features may be omitted in different situations, or may be replaced by other elements, materials, or methods. In some cases, certain operations related to this application are not shown or described in the specification. This is to avoid obscuring the core parts of this application with excessive description. For those skilled in the art, detailed description of these related operations is not necessary; they can fully understand the related operations based on the description in the specification and general technical knowledge in the art.

[0018] Furthermore, the features, operations, or characteristics described in the specification can be combined in any suitable manner to form various embodiments. At the same time, the steps or actions in the method description can be rearranged or adjusted in a manner obvious to those skilled in the art. Therefore, the various orders in the specification and drawings are only for the clear description of a particular embodiment and do not imply a necessary order, unless otherwise stated that a particular order must be followed.

[0019] The serial numbers assigned to components in this document, such as "first" and "second," are used only to distinguish the described objects and have no sequential or technical meaning. The terms "connection" and "linkage" used in this application, unless otherwise specified, include both direct and indirect connections (linkages).

[0020] As mentioned earlier, the performance of eMMC storage chips is affected not only by hardware resource configuration and firmware algorithms, but also, more fundamentally, by the execution efficiency of the firmware program and the scheduling strategy of the firmware algorithm.

[0021] Currently, the RAM space for the firmware program running on the main controller of eMMC memory chips is limited, such as 200KB, which is much smaller than the actual size of the firmware program, which is tens of MB. Therefore, the entire program cannot be placed in RAM at once. Instead, the firmware program needs to be divided into multiple units of RAM capacity, and the firmware program is read from NAND into RAM in a time-sharing manner according to the firmware program's execution call.

[0022] However, rereading the firmware unit containing firmware functions from the underlying NAND Flash and loading it into RAM is time-sharing because the read latency of NAND is much higher than the direct access speed of RAM. This results in a significant consumption of computing power waiting for code loading, as the firmware program's execution calls are time-sharing from NAND to RAM.

[0023] As can be seen from the above, the relevant technologies still have the drawback that frequently reading NAND Code Block firmware programs and refreshing them into RAM can affect the overall efficiency of program execution and the performance of eMMC memory chips.

[0024] Therefore, the firmware function storage method provided in this application can effectively improve the calling efficiency of firmware functions. Accordingly, the firmware function storage method is applicable to the firmware function storage device, which can be deployed in an electronic device. The electronic device can be a computer device configured with a von Neumann architecture, such as a desktop computer, a laptop computer, a server, etc.

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0026] Figure 1 This is a schematic diagram illustrating an implementation environment related to a method for storing firmware functions. It should be noted that this implementation environment is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of the invention.

[0027] The implementation environment includes the target chip 110 and the test equipment 130.

[0028] Specifically, the target chip 110 can also be considered as the chip to be tested. The target chip can be a storage chip such as eMMC or UFS (Universal Flash Storage), without any specific limitations here.

[0029] The testing device 130 can be an electronic device such as a desktop computer, laptop computer, or server, or it can be a computer cluster consisting of multiple servers, or even a cloud computing center consisting of multiple servers. The testing device 130 is used to provide background services, such as, but not limited to, firmware function storage services.

[0030] The test device 130 and the target chip 110 establish a network communication connection in advance via wired or wireless means, and data transmission between the test device 130 and the target chip 110 is realized through this network communication connection. The transmitted data includes, but is not limited to, test data, etc.

[0031] In one application scenario, the test device 130 acquires initial firmware data, and through the interaction between the target chip 110 and the test device 130, the test device 130 transmits the initial firmware data to the target chip for storage, sends target test commands to the target chip, and obtains the test data returned by the target chip in order to provide firmware function storage services to the target chip.

[0032] For the test device 130, after receiving the test data returned by the target chip 110, it calls the storage service of the firmware function to determine whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data. If it is determined that the initial storage area of ​​the firmware function needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test indicated by the test data to obtain the target firmware data. The target firmware data includes each firmware function and its adjusted target storage area.

[0033] Then, the target firmware function can be transferred to the target chip for storage, so as to adjust the storage area of ​​each firmware function in the target chip, optimize the distribution of firmware functions in each storage area, effectively avoid the execution stutter caused by frequently reloading the firmware program in NAND CodeBlock to RAM, thereby improving the overall efficiency of program execution and improving the read and write performance of eMMC storage chip from the bottom layer.

[0034] Please see Figure 2 , Figure 2 This is a hardware structure diagram of an electronic device according to an exemplary embodiment. This electronic device is suitable for... Figure 1 The test equipment 130 in the implementation environment is shown.

[0035] It should be noted that this electronic device is merely an example adapted to this application and should not be construed as providing any limitation on the scope of use of this application. Furthermore, this electronic device should not be interpreted as requiring or depending on any specific feature. Figure 2 One or more components of the exemplary electronic device 200 shown.

[0036] The hardware structure of electronic device 200 can vary significantly due to differences in configuration or performance, such as... Figure 2 As shown, the electronic device 200 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0037] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 200.

[0038] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. For example, to perform... Figure 1 The diagram illustrates the interaction between the target chip 110 and the test equipment 130 in the implementation environment.

[0039] Of course, in other examples adapted in this application, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 2 As shown, this does not constitute a specific limitation.

[0040] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0041] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 200, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0042] Application 253 is a computer program formed by computer-readable instructions based on operating system 251 to perform at least one specific task, and may include at least one module ( Figure 2 (Not shown), each module can contain corresponding computer-readable instructions. For example, the storage device for firmware functions can be considered as application program 253 deployed on electronic device 200.

[0043] Data 255 can be photos, pictures, etc. stored on a disk, or test data, etc., stored in memory 250.

[0044] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer programs stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, firmware functions can be stored by the central processing unit 270 reading the application program 253 stored in the memory 250.

[0045] Furthermore, this application can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of this application is not limited to any specific hardware circuit, software, or combination thereof.

[0046] Please see Figure 3 This application provides a method for storing firmware functions. This method is applicable to test devices, for example, the test device may be... Figure 1 The test equipment 130 in the implementation environment is shown. The hardware structure of the test equipment can be as follows: Figure 2As shown, the testing equipment can be used to test the target chip, which can be a storage chip such as eMMC or UFS.

[0047] In the following method embodiments, for ease of description, the execution subject of each step of the method is the test device as an example, but this does not constitute a specific limitation.

[0048] like Figure 3 As shown, the method may include the following steps:

[0049] Step 310: Obtain the initial firmware data and transfer it to the target chip for storage.

[0050] The initial firmware data includes multiple firmware functions and corresponding initial storage areas. It should be understood that the firmware program may include multiple firmware functions that perform different tasks. Each firmware function is allocated and written to a corresponding initial storage area. This initial storage area may refer to the area where each firmware function is stored before the storage area distribution optimization.

[0051] In one embodiment, obtaining initial firmware data may include the following steps: obtaining the target firmware program for the target chip; compiling and generating multiple firmware functions based on the target firmware program; determining the initial storage area of ​​each firmware function based on the compilation order of each firmware function; and generating initial firmware data based on the initial storage area of ​​each firmware function.

[0052] The target firmware program can refer to the firmware program of the target chip. The test equipment can compile the target firmware program to obtain multiple firmware functions. Then, according to the compilation order of each firmware function, a corresponding storage area is allocated to each firmware function to obtain the corresponding initial storage area.

[0053] In one implementation, each firmware function is numbered from Function1 to FunctionN according to its compilation order. Function1 to FunctionN represent the first compiled firmware function to the Nth compiled firmware function. Then, the corresponding storage area can be allocated according to the Function number.

[0054] Based on this, the initial firmware data can be transferred to the target chip. In one embodiment, the above-mentioned transfer of the initial firmware data to the target chip for storage may include the following steps: controlling the target chip to divide its internal storage space into multiple storage areas according to the memory size; controlling the target chip to store each firmware function in each storage area according to each firmware function and its corresponding initial storage area.

[0055] Figure 4This diagram illustrates a specific implementation of each firmware function stored in the target chip, such as... Figure 4 As shown, the internal storage space of the target chip is divided into multiple storage regions, including storage region 1 to storage region N. Function1 to FunctionN represent the first compiled firmware function to the Nth compiled firmware function. Each storage region stores 4 firmware functions.

[0056] Step 330: Send the target test command to the target chip and obtain the test data returned by the target chip.

[0057] The target test instruction is used to instruct the target chip to call the corresponding firmware function to execute the target scenario test at least once; the test data is the data generated by the target chip in the target scenario test. The test data may include the program running time in the target scenario test, the number of times the firmware function is called, the number of times the region is switched when different firmware functions are called across memory regions, etc., which are not specifically limited here.

[0058] The target scenario test may include at least one of the following test items: Reboot test, Power On test, Sudden Power Off Recovery (SPOR) test, Sequence Read test, Sequence Write test, Random Read test, Random Write test, Built-in Test (BIT), High Temperature Operating Life (HTOL) test, Sleep test, Awake test, and Reliability test, without being specifically limited here.

[0059] Users can select any one or more of the above test items as the target scenario test as needed, and set the number of tests for the target scenario test.

[0060] It should be noted that during their research on the target chip, the inventors discovered that the target chip typically does not have an external large-capacity DRAM (Dynamic Random Access Memory), and its main controller only has a very small amount of RAM space. Therefore, the large firmware program cannot be loaded into DRAM all at once for execution; instead, the various firmware functions must be distributed and stored in different underlying memory areas, and executed in a time-sharing manner on demand.

[0061] However, the inventors further discovered that if the distribution of firmware functions across different storage areas lacks optimization, it will trigger frequent cross-storage area calls during task execution. This frequent page swapping operation generates huge low-level addressing and data transport overhead, causing computing power to be severely consumed while waiting for code to load. Ultimately, this manifests as a sharp increase in the latency of the target chip in responding to external host instructions, and a significant decrease in overall read / write throughput.

[0062] To address the aforementioned technical bottlenecks, the inventors conducted an in-depth analysis of the target chip's execution under different application scenarios, discovering a significant correlation between the call sequences of specific firmware functions (i.e., certain firmware functions are often triggered consecutively). Based on this key finding, the inventors proposed allocating highly correlated and consecutively called firmware functions to the same storage region, thereby significantly reducing the probability of cross-storage region calls. This significantly reduces the latency overhead of moving code from the underlying storage to RAM, improves the effective utilization of the main control computing power, and ultimately achieves a substantial leap in the chip's overall instruction execution efficiency and read / write performance.

[0063] It is understandable that by introducing target scenario testing, all firmware functions stored in the target chip can be fully invoked. By capturing and statistically analyzing the firmware function call sequences of different target scenario tests, the correlation between firmware functions can be accurately extracted. This provides objective and comprehensive data support for adjusting the storage area of ​​frequently called firmware functions in the future, and avoids the impact of frequent page switching on the performance of the target chip.

[0064] In one embodiment, obtaining the test data returned by the target chip may include the following steps: during the target scenario test, controlling the target chip to record the call association of each firmware function; and obtaining test data based on the call association of each firmware function.

[0065] Among them, the call association can reflect the call status of each firmware function in the target scenario test and the association between different firmware functions.

[0066] In one embodiment, the above method may include the following steps: controlling the target chip to record the number of times each firmware function is called; and / or controlling the target chip to record the number of times the region is switched when different firmware functions are called across memory regions.

[0067] The number of calls can refer to the total frequency of a firmware function being called by the target chip within the execution cycle of the target scenario test. The number of calls can reflect the activity level of the firmware function in the target scenario test.

[0068] The number of region switching times can refer to the number of times firmware functions stored in different storage regions are called consecutively during target scenario testing.

[0069] For example, firmware function 1 is stored in storage area 1 and firmware function 2 is stored in storage area 2. In the target scenario test, if firmware function 1 is called and then firmware function 2 is called, then a cross-storage area call is completed, and the number of area switching between firmware function 1 and firmware function 2 will increase by one accordingly.

[0070] In one embodiment, during the execution cycle of the target scenario test, the order of firmware function calls is Function1->Function2->Function7->Function10->Function13. Then, the corresponding FunctionCallDependence Frequency is incremented by 1, i.e., FCDF1(2)=1, FCD1(1)=1, FCDF1(7)=1, FCDF1(10)=1, FCDF1(13)=1. Here, FCDF(2) refers to the number of times firmware function 2 is called in the target scenario test. By analogy, the number of times other firmware functions are called in the target scenario test can be counted. Until the target scenario test is completed, the firmware function call tree can calculate MaxFunctionCallNumber (number of calls) and MinCodePageLoadNumber (number of area switching).

[0071] Based on this, the number of times each firmware function is called and the number of times the region is switched when different firmware functions are called across storage regions can be obtained, thereby determining the call association of each firmware function in the target chip during the target scenario test.

[0072] Step 350: Determine whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data.

[0073] Specifically, the calling correlation of each firmware function can be determined by test data, and the calling efficiency of firmware functions in the target scenario test can be determined by the program execution time in the target scenario test. If the calling efficiency of a certain firmware function in the target scenario test is low, for example, the number of times the firmware function is called is very high and the corresponding number of area switching is also very high, it means that calling the firmware function takes more time. In this case, its storage location in the target chip needs to be adjusted.

[0074] Step 370: If it is determined that the initial storage area of ​​the firmware function needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test as indicated by the test data, so as to obtain the target firmware data.

[0075] The target firmware data includes each firmware function and its adjusted target storage area.

[0076] In one embodiment, step 370 may further include the following steps: if the test data determines that the number of region switching of any consecutively called firmware function meets the third set condition, then the initial storage area of ​​the consecutively called firmware function is adjusted so that the consecutively called firmware functions after the adjustment are located in the same storage area, thereby obtaining the target firmware data.

[0077] The third setting condition can be used to determine whether the number of region switching of the continuously called firmware function has reached the performance overhead limit for triggering memory region optimization. In other words, the third setting condition can determine whether the cross-memory region calls of the continuously called firmware function are too frequent, so as to seriously affect the chip performance.

[0078] The third setting condition can be a preset switching number threshold. If the number of region switching exceeds this threshold, it can indicate that the initial storage area of ​​the continuously called firmware functions needs to be adjusted. This switching number threshold can be preset according to the RAM capacity and NAND read latency parameters of the target chip. Alternatively, the third setting condition can be that, in the statistical results of the target scenario test, the number of region switching of the continuously called firmware functions ranks in the top percentage range among all firmware functions or firmware function pairs (i.e., two continuously called firmware functions) that have cross-region calls (e.g., the top 10% of region switching counts). It can also be that the firmware loading wait time caused by the number of region switching accounts for a proportion of the total time spent by the target chip in processing the corresponding target scenario test, which is greater than or equal to a preset overhead proportion threshold, without specific limitations here.

[0079] If the test data determines that the number of region switching operations for any consecutively called firmware function meets the third set condition, it can indicate that the storage region distribution of the currently consecutively called firmware function is unreasonable. The high-frequency cross-storage region calls trigger intensive NAND to RAM code paging operations, which seriously occupy the computing resources of the target chip and affect the chip performance of the target chip. Therefore, it is necessary to optimize the distribution of the storage region of the consecutively called firmware function.

[0080] For example, firmware function 1 is stored in storage area 1, and firmware function 2 is stored in storage area 2. If test data shows that the number of area switching between firmware function 1 and firmware function 2 exceeds the set switching threshold (meeting the third set condition), it is determined that the storage area distribution of the two needs to be optimized. Then, firmware function 1 and / or firmware function 2 are migrated to the same storage area for storage. In this way, the process that originally required cross-storage area calls is optimized into a single read within the same storage area, which significantly improves the execution efficiency of the target chip.

[0081] Conversely, if the test data determines that the number of region switching for any consecutively called firmware function does not meet the third set condition, then the storage region distribution of the currently consecutively called firmware function can be indicated as reasonable. Cross-storage region calls do not seriously affect the overall efficiency of the target chip, so there is no need to optimize the distribution of the storage region for consecutively called firmware functions.

[0082] Based on the above, after optimizing the distribution of storage areas for continuously called firmware functions, the target firmware data can be obtained. By transmitting the target firmware data to the target chip, the target chip can be controlled to store each firmware function as indicated by the target firmware data and its adjusted target storage area. This optimizes the storage area of ​​firmware functions within the target chip, reducing cross-storage area calls and improving execution efficiency when the target chip performs subsequent tasks.

[0083] Through the above process, the testing equipment can send the initial firmware data to the target chip for storage and control the target chip to execute target scenario tests to obtain test data. Based on the test data, it determines whether the initial storage location of each firmware function needs to be adjusted. If the initial storage location needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test indicated by the test data. This improves the calling efficiency of the firmware function and effectively solves the problem in related technologies where frequent reading of NAND CodeBlock firmware programs and refreshing them into RAM affects the overall efficiency of program execution and the performance of eMMC storage chips.

[0084] Please see Figure 5 In one exemplary embodiment, step 350 may further include the following steps:

[0085] Step 351: If the test data indicates that the call association of each firmware function meets the first set condition, determine the program running time in the target scenario test.

[0086] In this context, program execution time can refer to the time spent by the target chip running the target firmware program during the target scenario test. It can be understood that the target firmware program includes multiple firmware functions; that is, the target chip will call different firmware functions to execute the target scenario test. Therefore, program execution time can also refer to the time spent by the target chip calling and running the required firmware functions during the target scenario test.

[0087] The first set condition can be used to identify firmware functions that have both high call frequency and are originally stored in the same storage area. It can be understood that if there is a firmware function that meets the first set condition, it can be said that the firmware function is executed continuously at high frequency, but hardly causes a state of jumping across storage areas.

[0088] In one embodiment, step 351 may further include the following steps: if the test data indicates that the number of times the current firmware function is called is the maximum value in multiple target scenario tests and the number of times the firmware function switches regions is the minimum value in multiple target scenario tests, then the firmware function call association satisfies the first set condition.

[0089] Based on this first condition, when the number of calls reaches its maximum and the number of region switches reaches its minimum, it indicates that the firmware function is in an optimal distribution state within the current storage region partition (i.e., high-frequency execution with minimal page swapping across storage regions). Meeting this first condition serves as a prerequisite for subsequent program runtime verification, preventing the system from performing redundant redistribution optimization operations on firmware functions that are already in an optimal distribution.

[0090] Step 353: If the program runtime meets the second set condition, then there is no need to adjust the initial storage area of ​​the firmware function.

[0091] The second setting condition can be used to determine whether the program execution time is optimal under the current firmware function's storage space distribution.

[0092] Understandably, in evaluating the efficiency of firmware function calls, program execution time can be a quantitative indicator that characterizes the overall execution efficiency of the target chip.

[0093] Specifically, during the optimization process of adjusting the storage area, a negative optimization situation may occur. That is, after the area distribution is adjusted, although the test data shows that the number of area switching times has indeed decreased, the current program running time is greater than the program running time before the adjustment (i.e. the previous program running time). This indicates that simply storing firmware functions together may encounter other speed-affecting problems or abnormal conditions at the target chip's underlying level in actual operation.

[0094] Based on the above, this embodiment introduces a verification method based on program runtime. If calculations show that the adjusted program runtime not only fails to decrease but actually increases (i.e., it does not meet the second set condition), then the current firmware function distribution optimization is determined to have failed. In this case, a rollback can be triggered: that is, the target chip can be controlled to roll back to the storage area distribution state of the previous firmware function; or, based on the abnormal test data, the distribution weight can be recalculated, and the continuously called firmware function can be redirected to other storage areas for secondary testing until its program runtime meets the second set condition again.

[0095] In one embodiment, step 353 may further include the following steps: determining the previous program execution time of the target chip in the previous target scenario test; calculating the difference between the current program execution time and the previous program execution time of the target chip in the current target scenario test; if the difference obtained by the difference calculation is within a set range, then it is not necessary to adjust the initial storage area of ​​the firmware function.

[0096] The set range can refer to the normal time fluctuation range that the program's runtime is allowed to occur in multiple target scenario tests.

[0097] In one implementation, a preset allowable fluctuation ratio (e.g., 1% to 3%) can be used to calculate the corresponding time range as a set range. If the difference between the current program running time and the previous program running time does not exceed the set range, it is considered that the time is consistent.

[0098] It should be noted that by introducing multiple target scenario tests, random fluctuation errors can be eliminated. By calculating the program execution time of two adjacent target scenario tests, it can be verified whether the execution time of the firmware function will fluctuate drastically during multiple target scenario tests. If the difference remains within a very small set range, it indicates that the firmware function is not only in an optimal state in terms of storage space distribution (meeting the first set condition), but also that the time consumed by each run is highly consistent and has not been seriously affected by anomalies or interference.

[0099] Under the above embodiments, firmware functions that have both high call frequency and are originally concentrated in the same storage area are identified by the first set condition. The program running time is determined by the second set condition under the current storage space distribution of the firmware function. If the first or second set condition is not met, the storage space distribution of the firmware function is optimized to continuously reduce the cross-storage area switching overhead of each firmware function during continuous call, shorten the actual running time of the firmware program, and ultimately maximize the overall processing performance of the target chip.

[0100] The following is a detailed process of a method for storing firmware functions in an eMMC memory chip in an application scenario. In this application scenario, the target chip is an eMMC memory chip.

[0101] First, the test device obtains the target firmware program of the eMMC storage chip and compiles it to generate multiple firmware functions. Then, the location of the firmware functions can be recorded according to the compilation order of the firmware functions and numbered from Function1 (firmware function 1) to FunctionN (firmware function N), and a corresponding initial storage area can be set for each firmware function.

[0102] Furthermore, the testing equipment divides the underlying NAND Flash Code Block into multiple storage areas based on the size of the internal RAM space of the eMMC storage chip. Subsequently, according to the initial storage area corresponding to each firmware function, each firmware function is burned into the storage area corresponding to the target chip through the host interface universal asynchronous receiver / transmitter (UART).

[0103] When the eMMC memory chip is powered on, the test equipment sends target test commands through UART to perform chip performance tests and records the corresponding test data.

[0104] The test equipment can select at least one of the following test items as the target scenario test: Reboot test, Power On test, Sudden Power Off Recovery (SPOR) test, Sequence Read test, Sequence Write test, Random Read test, Random Write test, Built-in Test (BIT), High Temperature Operating Life (HTOL) test, Sleep test, Awake test, and Reliability test.

[0105] The number of test cycles for the target scenario can be set through the testing equipment: a single test of a single test item can be performed, a single test item can be performed multiple times, or a combination of multiple test items can be performed.

[0106] The call relationships of various firmware functions during the runtime of the eMMC storage chip are statistically recorded using CodePageSwitchAlgorithm (statistics module).

[0107] Among them, the CodePage Switch Algorithm uses a full matrix recursive algorithm to count and record the FunctionCallNumber (number of calls) of each firmware function under the target scenario test; it can also count and record the number of code page switches (CodePageLoadNumber) when each firmware function is called under the target scenario test.

[0108] The test device determines whether the location of firmware functions in the storage area needs to be adjusted by statistically analyzing the FunctionCallNumber and CodePageLoadNumber of all firmware functions.

[0109] If the test data indicates that the number of times the current firmware function is called is the maximum value in multiple target scenario tests, and the number of times the firmware function switches regions is the minimum value in multiple target scenario tests, then there is no need to adjust the storage location of the firmware function; otherwise, the storage location of the firmware function needs to be adjusted.

[0110] Determine the previous program execution time of the eMMC storage chip in the previous target scenario test; calculate the difference between the current program execution time and the previous program execution time in the current target scenario test of the eMMC storage chip. If the difference obtained by the difference calculation is within the set range, the test ends without adjusting the initial storage area of ​​the firmware function; otherwise, the storage location of the firmware function needs to be adjusted.

[0111] If it is determined that there are any consecutively called firmware functions that require adjustment of the storage area, then the storage location of the aforementioned firmware functions is adjusted to the same storage area. In this way, the process that originally required cross-storage area calls is optimized into a single read from the same storage area, which significantly improves the execution efficiency of the target chip.

[0112] Figure 6 The diagram illustrates the specific implementation of the optimized storage area distribution of firmware functions in the eMMC memory chip for this application scenario. Figure 6 As shown, Figure 6 The left side shows the initial storage locations of each firmware function (Function1 to FunctionN). Figure 6 On the right are the firmware functions that complete the storage area distribution optimization. After the storage area distribution optimization is completed, the program execution time of the target chip is shorter, which significantly improves the performance of the target chip.

[0113] In this application scenario, the correlation of firmware function processing flow and firmware function calling strategy of eMMC storage chip can be fully verified, and potential risks and defects in firmware function flow can be fully resolved, improving the stability and compatibility of firmware program, improving the smoothness and efficiency of target chip operation, and solving the problem that poor correlation of firmware functions may occur when the firmware program cannot be fully loaded into RAM at once due to RAM storage space limitations of eMMC storage chip, and the need to frequently switch storage areas when firmware function calls are required.

[0114] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0115] The following are embodiments of the apparatus described in this application, which can be used to execute the firmware function storage method involved in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments of the firmware function storage method involved in this application.

[0116] Please see Figure 7 This application provides a firmware function storage device 900, including but not limited to: a data acquisition module 910, an instruction transmission module 930, a region determination module 950, and a region adjustment module 970.

[0117] The data acquisition module 910 is used to acquire initial firmware data and transmit the initial firmware data to the target chip for storage; the initial firmware data includes multiple firmware functions and corresponding initial storage areas;

[0118] The instruction transmission module 930 is used to send target test instructions to the target chip and obtain test data returned by the target chip; the target test instructions are used to instruct the target chip to call the corresponding firmware function to perform at least one target scenario test;

[0119] The region determination module 950 is used to determine whether the initial storage region of the firmware function needs to be adjusted based on the test data.

[0120] The region adjustment module 970 is used to adjust the initial storage area of ​​the firmware function according to the call association of each firmware function in the target scenario test as indicated by the test data, when the initial storage area of ​​the firmware function that needs to be adjusted is determined, so as to obtain the target firmware data; the target firmware data includes each firmware function and its target storage area after adjustment.

[0121] It should be noted that the firmware function storage device provided in the above embodiments is only illustrated by the division of the above functional modules when storing firmware functions. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the firmware function storage device will be divided into different functional modules to complete all or part of the functions described above.

[0122] Furthermore, the firmware function storage device and firmware function storage method provided in the above embodiments belong to the same concept, and the specific way in which each module performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0123] This document describes various exemplary embodiments with reference to them. However, those skilled in the art will recognize that changes and modifications can be made to the exemplary embodiments without departing from the scope of this document. For example, various operational steps and components for performing operational steps can be implemented in different ways depending on the specific application or considering any number of cost functions associated with the operation of the system (e.g., one or more steps can be deleted, modified, or combined with other steps).

[0124] Those skilled in the art will understand that all or part of the functions of the various methods in the above embodiments can be implemented by hardware or by computer programs. When all or part of the functions in the above embodiments are implemented by computer programs, the program can be stored in a computer-readable storage medium, which may include: read-only memory, random access memory, disk, optical disk, hard disk, etc., and the program is executed by a computer to achieve the above functions. For example, the program can be stored in the memory of a device, and when the program in the memory is executed by the processor, all or part of the above functions can be achieved. In addition, when all or part of the functions in the above embodiments are implemented by computer programs, the program can also be stored in a server, another computer, disk, optical disk, flash drive, or external hard drive, etc., and can be downloaded or copied to the memory of a local device, or the system of the local device can be updated. When the program in the memory is executed by the processor, all or part of the functions in the above embodiments can be achieved.

[0125] In the above embodiments, implementation can be achieved, in whole or in part, by software, hardware, firmware, or any combination thereof. Furthermore, as those skilled in the art will understand, the principles herein can be reflected in a computer program product on a computer-readable storage medium pre-loaded with computer-readable program code. Any tangible, non-transitory computer-readable storage medium may be used, including magnetic storage devices (hard disks, floppy disks, etc.), optical storage devices (CD-ROMs, DVDs, Blu-ray discs, etc.), flash memory, and / or the like. These computer program instructions can be loaded onto a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to form a machine, such that instructions executing on the computer or other programmable data processing apparatus can generate means for performing a specified function. These computer program instructions can also be stored in a computer-readable storage medium that can instruct the computer or other programmable data processing apparatus to operate in a particular manner, such that instructions stored in the computer-readable storage medium can form an article of manufacture including means for implementing the specified function. The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to perform a series of operational steps on the computer or other programmable apparatus to produce a computer-implemented process, such that instructions executing on the computer or other programmable apparatus can provide steps for implementing the specified function.

[0126] While the principles herein have been illustrated in various embodiments, numerous modifications to the structure, arrangement, proportions, elements, materials, and components, particularly suited to specific environmental and operational requirements, may be used without departing from the principles and scope of this disclosure. These modifications and other alterations or alterations will be included within the scope of this document.

[0127] The foregoing specific descriptions have been described with reference to various embodiments. However, those skilled in the art will recognize that various modifications and changes can be made without departing from the scope of this disclosure. Therefore, considerations for this disclosure are to be illustrative rather than restrictive, and all such modifications are to be included within its scope. Similarly, advantages, other advantages, and solutions to problems with respect to various embodiments have been described above. However, benefits, advantages, solutions to problems, and any elements that produce these, or make them more explicit, should not be construed as critical, essential, or necessary. The term “comprising” and any other variations thereof as used herein are non-exclusive inclusion, meaning that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed or not part of the process, method, system, article, or apparatus. Furthermore, the term “coupled” and any other variations thereof as used herein refer to physical connections, electrical connections, magnetic connections, optical connections, communication connections, functional connections, and / or any other connections.

[0128] Those skilled in the art will recognize that many changes can be made to the details of the above embodiments without departing from the basic principles of the invention. Therefore, the scope of the invention should be determined only by the claims.

Claims

1. A method for storing firmware functions, characterized in that, Applied to testing equipment, the testing equipment being used to test the target chip; The method includes: Acquire initial firmware data and transfer the initial firmware data to the target chip for storage; the initial firmware data includes multiple firmware functions and corresponding initial storage areas. Send a target test command to the target chip and obtain the test data returned by the target chip; the target test command is used to instruct the target chip to call the corresponding firmware function to perform at least one target scenario test; Determine whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data; If it is determined that the initial storage area of ​​the firmware function needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test as indicated by the test data, to obtain target firmware data; the target firmware data includes each firmware function and its target storage area after the adjustment.

2. The method as described in claim 1, characterized in that, The process of obtaining initial firmware data includes: Obtain the target firmware program for the target chip; The multiple firmware functions are generated by compiling the target firmware program. The initial storage area of ​​each firmware function is determined based on the compilation order of each firmware function. The initial firmware data is generated based on the initial storage area of ​​each firmware function.

3. The method as described in claim 1, characterized in that, The step of transferring the initial firmware data to the target chip for storage includes: The target chip is controlled to divide its internal storage space into multiple storage areas according to the memory size; The target chip is controlled to store each firmware function in its respective storage area according to each firmware function and its corresponding initial storage area.

4. The method as described in claim 1, characterized in that, The step of sending a target test command to the target chip and obtaining the test data returned by the target chip includes: During the target scenario test, the target chip is controlled to record the call associations of each firmware function; The test data is obtained based on the call associations of each firmware function.

5. The method as described in claim 4, characterized in that, During the target scenario test, the target chip is controlled to record the call associations of each firmware function, including: The target chip is controlled to record the number of times each firmware function is called; And / or, control the target chip to record the number of region switching times when different firmware functions are called across storage regions.

6. The method as described in claim 1, characterized in that, The step of determining whether the initial storage area of ​​the firmware function needs to be adjusted based on the test data includes: If the test data indicates that the call association of each firmware function meets the first set condition, the program running time in the target scenario test is determined. If the program runtime meets the second set condition, then there is no need to adjust the initial storage area of ​​the firmware function.

7. The method as described in claim 6, characterized in that, The step of, where the test data indicates that the call association of each firmware function meets a first set condition, includes: If the test data indicates that the current number of times the firmware function is called is the maximum value in multiple target scenario tests, and the number of times the firmware function switches regions is the minimum value in multiple target scenario tests, then the firmware function call association satisfies the first set condition.

8. The method as described in claim 6, characterized in that, The statement that if the program execution time meets the second set condition, then the initial storage area of ​​the firmware function does not need to be adjusted includes: Determine the last program execution time of the target chip in the previous target scenario test; The difference between the current program execution time and the previous program execution time in the current target scenario test of the target chip is calculated. If the difference obtained by the difference calculation is within a set range, then there is no need to adjust the initial storage area of ​​the firmware function.

9. The method as described in claim 1, characterized in that, When it is determined that the initial storage area of ​​the firmware function needs to be adjusted, the initial storage area of ​​the firmware function is adjusted according to the call association of each firmware function in the target scenario test as indicated by the test data, to obtain target firmware data, including: If, based on the test data, it is determined that the number of region switching operations for any consecutively called firmware function meets the third preset condition, then the initial storage area of ​​the consecutively called firmware function is adjusted so that the consecutively called firmware functions after the adjustment are located in the same storage area, thereby obtaining the target firmware data.

10. A storage device for firmware functions, characterized in that, Deployed on a test device used to test the target chip; The device includes: A data acquisition module is used to acquire initial firmware data and transmit the initial firmware data to the target chip for storage; the initial firmware data includes multiple firmware functions and corresponding initial storage areas. The instruction transmission module is used to send a target test instruction to the target chip and obtain test data returned by the target chip; the target test instruction is used to instruct the target chip to call the corresponding firmware function to perform at least one target scenario test; The region determination module is used to determine whether the initial storage region of the firmware function needs to be adjusted based on the test data. The region adjustment module is used to adjust the initial storage region of the firmware function according to the call association of each firmware function in the target scenario test as indicated by the test data, when it is determined that the initial storage region of the firmware function needs to be adjusted, so as to obtain target firmware data; the target firmware data includes each firmware function and its target storage region after the adjustment.

Images