Firmware updating and testing method, readable storage medium and electronic device

Abstract

The application discloses a firmware updating and testing method, a readable storage medium and an electronic device, and relates to the technical field of firmware updating and testing. The method comprises the following steps: detecting whether a target firmware file of an SD card exists in an absolute path; if the target firmware file exists, reading the target firmware file to a cache area of a system; updating the target firmware file in the cache area to a firmware area of the SD card according to an updating instruction, wherein the firmware area stores an original firmware file; after the firmware updating of the firmware area, reading first firmware information from the firmware area according to a reading instruction; comparing the first firmware information with original firmware information of the firmware area, and if the comparison result is consistent with an expected difference, confirming that the firmware updating of the SD card is successful. The application can realize the FFU of the SD card under the Linux system, and improve the universality and user-friendliness of the FFU of the SD card.

Description

Technical Field

[0001] This invention relates to the field of firmware update technology, and more particularly to a firmware update and testing method, a readable storage medium, and an electronic device. Background Technology

[0002] The SD Jedec protocol (a storage protocol) standard does not explicitly include a Field Firmware Update (FFU) function for SD cards, which are Secure Digital Flash Memory cards. Currently, simulating FFU testing for SD cards is quite cumbersome, primarily involving developing and recompiling the uboot (bootloader) test source code for XU4 (a hardware platform), and requiring a PMIC (Power Management Integrated Circuit) power-down external board, with power controlled via the IIC (Synchronous Serial Communication) protocol. However, this testing method lacks versatility and offers a poor user experience.

[0003] First, FFU testing based on this implementation method can only be applied to platforms equipped with a uboot image and cannot be implemented on general-purpose systems. In practical applications, storage components such as SSDs, eMMC, and RAID cards usually have tools for firmware upgrades on general-purpose systems. However, for SD cards, especially on some test platforms that require a Linux kernel system image, there is a lack of corresponding general-purpose tools for FFU testing. Although on Linux systems with an MMC interface (an interface for non-volatile storage devices), some commands (such as ls / sys / block / mmcblk1 / device / cat) can be used to view some device node information of the SD card, this information does not include a valid firmware version field. Users can only obtain basic information such as the SD card's CID and date, but cannot use the relevant tools of the MMC interface to perform in-depth analysis of the SD card's firmware information or execute related commands. Therefore, when starting firmware-related tests on an SD card on a Linux system, the necessary matching conditions are lacking on the system side.

[0004] Secondly, since the uboot system does not have a file system and ecosystem similar to the Linux operating system, the FW file corresponding to the SD card needs to be stored on an external host running a Linux operating system before FFU boot. Then, it needs to be burned to the SD card under test using a script, or the FW file can be burned to the user partition of the SD card using a Windows burning tool, or the file can be transferred via the Xmodem protocol in a serial terminal. The transfer time is relatively long, so the FW file cannot be directly and quickly copied into the uboot image system.

[0005] Finally, this implementation method presents significant challenges in deployment and portability. A highly portable tool should be easy for users to download, copy, and unzip for direct use, without requiring complex development, compilation, flashing, and environment setup processes. However, the current testing methods clearly fail to meet this requirement.

[0006] In summary, existing FFU testing methods do not fully consider common firmware operation-related tests under Linux systems for test platforms running Linux kernels such as Ubuntu. Testers lack universal tools to obtain firmware information from SD cards, while developing new tools for development boards running different system distributions lacks user-friendliness. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a firmware update and testing method, a readable storage medium and an electronic device that can implement FFU on SD cards under Linux system, thereby improving the universality and user-friendliness of FFU on SD cards.

[0008] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0009] A firmware update method, comprising:

[0010] Check if the target firmware file for the SD card exists in the current absolute path;

[0011] If the target firmware file exists, then the target firmware file is read into the system's cache.

[0012] The update instruction is called according to the input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored.

[0013] After the firmware in the firmware area is updated, a read instruction is called according to the input / output control function to read the first firmware information from the firmware area;

[0014] The first firmware information is compared with the original firmware information in the firmware area. If the comparison result matches the expected difference, the firmware update of the SD card is confirmed to be successful.

[0015] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0016] A firmware testing method, comprising:

[0017] Create a data template, and fill the SD card with data according to the data template to obtain static data;

[0018] Perform each step in the firmware update method described above;

[0019] After the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware update process.

[0020] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0021] A firmware testing method, comprising:

[0022] When testing the SD card using an input / output performance testing tool, each step in the firmware update method described above is executed to perform hot upgrades and hot downgrades of the SD card's firmware.

[0023] If the firmware update of the SD card is successful, it is determined that the SD card supports firmware hot-upgrade and hot-downgrade operations when performing input / output operations.

[0024] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0025] A firmware testing method, comprising:

[0026] Create a data template, and fill the SD card with data according to the data template to obtain static data;

[0027] When testing the SD card using an input / output performance testing tool, each step in the firmware update method described above is executed to perform hot upgrades and hot downgrades of the SD card's firmware.

[0028] If the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware hot upgrade and hot downgrade process.

[0029] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0030] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the firmware update method described above.

[0031] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows:

[0032] An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the firmware update method described above.

[0033] The beneficial effects of this invention are as follows: After the firmware update process begins, the target firmware file for updating the SD card is first located in the absolute path of the current program. Then, the target firmware file is read from the current absolute path into the system cache. Finally, the target firmware file in the cache is updated to the firmware area of ​​the SD card. Simultaneously, the first firmware information in the firmware area of ​​the SD card is read, and the firmware information before and after the update is compared to confirm whether the firmware update was successful. Since traditional SD card firmware update methods are based on commands provided by the uboot source code, different images require repeated redevelopment of their respective source code. Compared to traditional SD card firmware update methods, this invention uses highly universal input / output control function calls to update and read commands to achieve firmware update and information reading. It eliminates the need to consider command set differences caused by different system images, enabling SD cards to perform firmware updates based on Linux systems. This improves the versatility and user-friendliness of SD cards for FFU multi-dimensional testing. Attached Figure Description

[0034] Figure 1 A flowchart of a firmware update method provided in an embodiment of the present invention;

[0035] Figure 2 Another flowchart of a firmware update method provided in an embodiment of the present invention;

[0036] Figure 3 A flowchart illustrating a firmware testing method for verifying firmware platform compatibility, provided as an embodiment of the present invention;

[0037] Figure 4 A flowchart illustrating a firmware testing method for verifying static data consistency, provided as an embodiment of the present invention;

[0038] Figure 5 A flowchart of a firmware testing method for verifying firmware hot-upgrade / downgrade is provided in an embodiment of the present invention;

[0039] Figure 6 A flowchart of another firmware testing method for verifying static data consistency provided in an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0041] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0042] An embodiment of the present invention provides a firmware update method, comprising:

[0043] Check if the target firmware file for the SD card exists in the current absolute path;

[0044] If the target firmware file exists, then the target firmware file is read into the system's cache.

[0045] The update instruction is called according to the input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored.

[0046] After the firmware in the firmware area is updated, a read instruction is called according to the input / output control function to read the first firmware information from the firmware area;

[0047] The first firmware information is compared with the original firmware information in the firmware area. If the comparison result matches the expected difference, the firmware update of the SD card is confirmed to be successful.

[0048] As described above, the beneficial effects of this invention are as follows: After the firmware update process begins, the target firmware file on the SD card is first located in the absolute path of the current program. Then, the target firmware file is read from the current absolute path into the system's cache area. Finally, the target firmware file in the cache area is updated to the firmware area of ​​the SD card. Simultaneously, the first firmware information in the firmware area of ​​the SD card is read, and the firmware information before and after the update is compared to confirm whether the firmware update was successful. Since the traditional SD card firmware update method is based on the command sending interface provided by the uboot source code, and the FFU function interface needs to be redeveloped to implement the firmware update, for different images, the redevelopment of the respective image source code needs to be repeated. Furthermore, if it is necessary to expand to other dimensions of use cases, such as adding IO scenarios, traversing multiple firmware FFUs, and obtaining test data output in a specific format, additional development of the source code function interface is required. Compared to traditional SD card firmware update methods, this invention uses highly universal input / output control function calls to update and read commands to achieve firmware updates and information reading. It eliminates the need to consider command set differences caused by different system images, enabling SD cards to perform firmware updates based on Linux systems. This improves the versatility and user-friendliness of FFU multi-dimensional testing on SD cards. Within the operating system, thanks to a robust ecosystem, the firmware update program only needs to be paired with shell language to easily achieve applications in various scenarios. The richness and dimensions of test cases can be quickly expanded and satisfied. Calls to the program described in this invention within shell scripts can integrate testing of various complex scenarios and easily achieve various specific test data parsing and log formats. It also exhibits high compatibility across different Linux system architectures.

[0049] Furthermore, it also includes:

[0050] If the target firmware file does not exist, the read instruction is invoked to read the original firmware information from the firmware area, and the original firmware information is converted into a string format and then printed out.

[0051] As described above, if the target firmware file does not exist in the absolute path of the current program, it indicates that the user is only viewing the firmware information of the SD card and not performing an FFU operation. After reading the raw firmware information through the read command, the raw firmware information is converted into a string format and printed out. Compared with existing methods, this invention can obtain firmware information independently by simply reading the instruction set, without calling other command interfaces or redeveloping existing source code, effectively improving the versatility of SD card information viewing.

[0052] Furthermore, the step of detecting whether the target firmware file of the SD card exists in the current absolute path includes:

[0053] Check if the firmware file for the SD card exists in the current absolute path, and that the name of the firmware file conforms to the preset naming rules;

[0054] If so, then it is determined that the target firmware file exists under the absolute path;

[0055] Otherwise, it is determined that the target firmware file does not exist under the absolute path.

[0056] As described above, since other firmware files may be stored in the current absolute path, the naming rules for firmware files are restricted in order to achieve the ability to distinguish and detect firmware files.

[0057] Furthermore, the update command includes an access command and a standard write command for the SD card;

[0058] The process of calling an update instruction according to an input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored includes:

[0059] The input / output control function calls the access instruction to open the pre-packaged firmware interface of the SD card, so as to access the firmware area of ​​the SD card where the original firmware file is stored through the firmware interface;

[0060] After accessing the firmware area, the target firmware file in the cache is written to the firmware area by calling the standard write command according to the input / output control function.

[0061] As described above, because the SD card protocol does not define direct commands or related registers for FFU functionality, it cannot directly send related commands or access registers to implement FFU functionality like other flash memory components. Therefore, this invention first accesses the firmware area of ​​the SD card through an access command, i.e., enters the SD card area invisible to the user, and then calls the standard write command defined by the SD protocol to write the firmware. Since the write command called by this invention is a general command defined by the SD protocol, there is no need for redevelopment based on different systems, effectively improving the universality of update commands.

[0062] Furthermore, the read command includes an access command and the standard read command of the SD card;

[0063] Calling a read instruction according to the input / output control function to read first firmware information from the firmware area includes:

[0064] The input / output control function calls the access instruction to open the pre-packaged firmware interface of the SD card, so as to access the firmware area through the firmware interface;

[0065] After accessing the firmware area, the first firmware information is read from the firmware area by calling the standard read command according to the input / output control function.

[0066] As described above, the SD card protocol does not define direct instructions or registers for viewing firmware information. Therefore, the access instructions of this invention access the firmware area of ​​the SD card, that is, enter the SD card area that is not visible to the user, and then call the standard read commands defined by the SD protocol to view the firmware information, without the need to develop different commands for different systems.

[0067] Furthermore, after updating the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored, the method further includes:

[0068] The system's power management service controls the SD card to perform power-on and power-off initialization operations, enabling the SD card to complete firmware updates based on the target firmware file.

[0069] As described above, existing firmware update methods require the cooperation of software and hardware to implement power management. However, this invention only requires the software-side power management service to control the SD card to perform a single power-on / off initialization operation, which enables the firmware update of the SD card to take effect, effectively reducing development costs.

[0070] Furthermore, before checking if the target firmware file for the SD card exists in the current absolute path, the process also includes:

[0071] The system drive letter is obtained based on the SD card access interface, and the system drive letter is used as the control object parameter of the input / output control function.

[0072] As described above, since the system may have multiple connected devices, the system drive letter is used to identify the current SD card, making it easier for the system to identify the object to be read and written, thus enabling access to the SD card.

[0073] Another embodiment of the present invention provides a firmware testing method, comprising:

[0074] Create a data template, and fill the SD card with data according to the data template to obtain static data;

[0075] Perform each step in the firmware update method described above;

[0076] After the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware update process.

[0077] As described above, the firmware update method described above can be used to verify whether the static data of the SD card remains consistent during the firmware update process.

[0078] Another embodiment of the present invention provides a firmware testing method, comprising:

[0079] When testing the SD card using an input / output performance testing tool, each step in the firmware update method described above is executed to perform hot upgrades and hot downgrades of the SD card's firmware.

[0080] If the firmware update of the SD card is successful, it is determined that the SD card supports firmware hot-upgrade and hot-downgrade operations when performing input / output operations.

[0081] As described above, the firmware update method described above can be used to verify whether the SD card supports firmware hot-upgrade and hot-downgrade operations when performing input / output operations.

[0082] Another embodiment of the present invention provides a firmware testing method, comprising:

[0083] Create a data template, and fill the SD card with data according to the data template to obtain static data;

[0084] When testing the SD card using an input / output performance testing tool, each step in the firmware update method described above is executed to perform hot upgrades and hot downgrades of the SD card's firmware.

[0085] If the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware hot upgrade and hot downgrade process.

[0086] As described above, the firmware update method described above can be used to verify whether the static data of the SD card remains consistent during firmware hot upgrades and hot downgrades.

[0087] Another embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the firmware update method described above.

[0088] Another embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that the processor executes the computer program to implement the various steps of the firmware update method described above.

[0089] The firmware update and testing method, readable storage medium, and electronic device described above are applicable to firmware update and testing scenarios for SD cards. Traditionally, SD cards implement FFU operations by developing a command interface from the uboot kernel source code to execute FFU operations, coupled with a PMIC power-down external board, and power control via the IIC protocol to enable FFU operations. However, with the expansion of test platforms, various development boards have been introduced and compatibility testing has been implemented during FFU operation implementation. Simultaneously, test platforms have begun to run Linux kernel operating systems, rendering the traditional XU4 uboot image no longer suitable. When operating new platforms with such Linux kernel operating systems, facing different Linux image distributions and development boards, continuing to perform FFU operations in the traditional way (downloading the image source code provided by the platform vendor and redeveloping the image kernel source code) results in high development costs, and requires repeated redevelopment of the image source code for different development boards. Furthermore, in terms of compatibility testing, the command interface developed based on the uboot kernel source code lacks high portability and cannot be compatible with all systems. Based on this, the present invention compiles a firmware update method into a program, thereby enabling the Linux kernel operating system to be invoked through the compiled program to send standard SD card commands. The program compiled based on the firmware update method in this invention is a standalone tool that can be easily copied and deployed on embedded platforms running different versions of Linux system images. It can also be deployed on current PC-compatible Linux distributions. Therefore, the firmware update method provided by this invention eliminates the need for repeated source code development for different images. The following describes specific implementation methods:

[0090] Example 1

[0091] Please refer to Figure 1 A firmware update method, comprising:

[0092] S110. Check if the target firmware file for the SD card exists in the current absolute path.

[0093] The firmware update method of this invention can be compiled into a standalone program for implementing FFU operation on an SD card. After the SD card is connected to the operating system, the compiled program and the target firmware file corresponding to the SD card are stored in the same path, which is the absolute path of the compiled program. An absolute path refers to the complete path from the root directory of the file system to the target file or directory.

[0094] Specifically, step S110 includes:

[0095] S1101. Detect whether there is a firmware file for the SD card in the current absolute path, and whether the name of the firmware file conforms to the preset naming rules; if so, determine that there is a target firmware file in the absolute path; otherwise, determine that there is no target firmware file in the absolute path.

[0096] The target firmware file refers to all firmware files whose names conform to the preset naming rules. In some embodiments, if the currently running program only performs firmware change operations, a single FFU operation can be initiated as long as one target firmware file, fwx.bin (where x conforms to the integer requirement of the naming rules), is detected. If the currently running program is for FFU testing, and the purpose is to restore the device's firmware version to the initial version after the test is completed to avoid changes to the test firmware affecting subsequent use or testing, then at least two target firmware files (i.e., including the initial firmware fw1.bin and the test firmware fw2.bin) must be detected during FFU testing to meet the requirements of bidirectional FFU testing.

[0097] In some embodiments, the naming rule during FFU testing is specifically an ascending order. For example, if there are four firmware files in the absolute path of the current program, named fw1.bin, fw2.bin, fw3.bin, and fwf.bin, then it can be determined that a target firmware file exists in the absolute path, namely fw1.bin, fw2.bin, and fw3.bin. If there are two firmware files in the absolute path of the current program, named fw1.bin and fwf.bin, then it can be determined that a target firmware file does not exist in the absolute path.

[0098] Before step S110, the method further includes:

[0099] S100: Obtain the system drive letter based on the SD card access interface, and use the system drive letter as the control object parameter of the input / output control function. Specifically, after the SD card is connected to the operating system, the open function is called to return the file descriptor of the SD card to obtain the system drive letter.

[0100] In some embodiments, the operating system includes a USB interface and an MMC interface. Regardless of whether the SD card is connected via a USB interface or an MMC interface, the operating system will assign a corresponding system drive letter to the SD card.

[0101] S120. If the target firmware file exists, the target firmware file is read into the system's cache.

[0102] S130. Call the update instruction according to the input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored.

[0103] Specifically, the system drive letter and update command serve as input parameters to the input / output control function, and the return parameter of the input / output control function is used to characterize the execution result of the update command.

[0104] The update instructions include access instructions and the standard write command for the SD card.

[0105] Specifically, step S130 includes:

[0106] S1301. The access instruction is called according to the input / output control function to open the pre-encapsulated firmware interface of the SD card, so as to access the firmware area of ​​the SD card where the original firmware file is stored through the firmware interface.

[0107] S1302. After accessing the firmware area, the target firmware file in the cache area is written to the firmware area by calling the standard write command according to the input / output control function.

[0108] Following step S130, the method further includes:

[0109] S131. Based on the power management service of the system, control the SD card to perform power-on and power-off initialization operations so that the SD card can complete firmware update based on the target firmware file.

[0110] In some embodiments, the system's power management services may include host power management of devices, host reboot, and DC power cycle. Power Cycle refers to restarting a device by turning off its power, waiting a period of time, and then turning it back on.

[0111] In one alternative implementation, the SD card can be controlled for power-on / off initialization via an external power management device. For example, the SD card can be controlled for power-on / off initialization via a relay.

[0112] S140. After the firmware in the firmware area is updated, a read instruction is called according to the input / output control function to read the first firmware information from the firmware area.

[0113] Specifically, the system drive letter and the read command serve as input parameters to the input / output control function, and the return parameter of the input / output control function is used to characterize the execution result of the read command.

[0114] The read instructions include access instructions and the standard read command of the SD card;

[0115] Specifically, step S140 includes:

[0116] S1401. The input / output control function calls the access instruction to open the pre-packaged firmware interface of the SD card, so as to access the firmware area through the firmware interface.

[0117] S1402. After accessing the firmware area, the first firmware information is read from the firmware area by calling the standard read command according to the input / output control function.

[0118] In steps S130 and S140 above, the firmware interface provided by the SD card is the VU interface. Since the SD card protocol does not define direct commands or related registers for implementing FFU functionality and viewing firmware information, the SD card cannot directly send related commands and access register values ​​to implement FFU functionality and read firmware information like an eMMC memory. Furthermore, all reserved bits in the registers currently defined by the SD card protocol do not meet the requirements for storing firmware version numbers or other firmware information. Therefore, this invention accesses the firmware area of ​​the SD card through the VU interface provided by the SD card. The firmware area of ​​the SD card is the area of ​​the SD card that is not visible to the user externally, in order to implement the FFU function and read firmware information, which is not defined in the SD card protocol.

[0119] Because the target firmware file needs to be burned to the area where the original firmware file is located on the SD card to replace the original firmware file, rather than being directly burned to the user partition address of the SD card. If the target firmware file is only burned to the externally visible user partition of the SD card, then the target firmware file is simply stored as a file on the SD card and cannot replace the original firmware file in the firmware area of ​​the SD card to achieve firmware update. Therefore, this invention first enters the firmware area of ​​the SD card through an access command, and then uses the standard write command of the SD card to overwrite the target firmware file in the cache area into the firmware area of ​​the SD card, so as to replace the original firmware file in the firmware area. Similarly, after the firmware update takes effect based on Power Cycle, the firmware area of ​​the SD card must first be entered through an access command, and then the firmware information in the firmware area can be read through the standard read command of the SD card.

[0120] In steps S130 and S140 above, the access command is determined by the VU interface provided by different manufacturers' firmware. The standard write and read commands for the SD card come from the SD card's CMD command protocol. The CMD command protocol is a set of commands used to communicate with the SD card. Commands in this set can be used to initialize the SD card, read and write data, obtain the SD card's status, and perform other related operations. The commands in the CMD command protocol can be divided into application-specific commands (ACMD) and general commands (CMD). Some general commands and their functions are as follows: 1. CMD24: Puts the SD card into transfer mode and writes a single block; 2. CMD25: Puts the SD card into transfer mode and writes multiple blocks; 3. CMD17: Sets the SD card to operate on a single block and reads a single block; 4. CMD12: Forces the SD card to stop all transfer operations of CMD25. Therefore, the standard write command of this invention can be set to CMD24 or CMD25, and the standard read command can be set to CMD17.

[0121] S150. Compare the first firmware information with the original firmware information in the firmware area. If the comparison result matches the expected difference, then confirm that the firmware update of the SD card is successful.

[0122] In some embodiments, the firmware information in this invention includes a firmware version number. Step S5 specifically involves comparing the firmware version number of the firmware area before and after the firmware update. If the firmware version number is updated correctly, it is determined that the firmware update of the SD card was successful.

[0123] The method also includes:

[0124] S160. If the target firmware file does not exist, the read instruction is invoked to read the original firmware information from the firmware area, and the original firmware information is converted into a string format and then printed out.

[0125] Example 2

[0126] Please refer to Figure 2 and Figure 3 The firmware update method of Embodiment 1 is applied to a real-world scenario.

[0127] In this embodiment, the SD card is connected to the Linux system, and the Linux system assigns a corresponding system drive letter to the SD card. After copying the program compiled based on the above firmware update method and the target firmware file corresponding to the SD card (hereinafter referred to as the fw.bin file) to the same path, the program is run to perform the following steps:

[0128] S201. Check if there are multiple fw.bin files named in ascending order in the absolute path where the program is located. If so, execute steps S202 to S210. Otherwise, execute steps S207, S208 and S210 in sequence.

[0129] S202. Obtain a memory cache area from the system that is large enough to store all fw.bin files as the system cache area, and read all fw.bin files into the cache area.

[0130] S203. Call the ioctl function with the access command VU cmd and the system drive letter as input parameters to enter the firmware area of ​​the SD card. VU cmd is the command to access the firmware interface. Since there may be differences between different firmware manufacturers, its pointer structure is modified according to the actual firmware manufacturer.

[0131] S204. Call the ioctl function with the standard write command CMD25 as input parameter to overwrite all fw.bin files in the buffer area to the firmware area of ​​the SD card.

[0132] CMD24 and CMD25 can be used to write different amounts of data. CMD24 writes a data block size of 512 bytes at a time. CMD25 writes a data block size of 1024 bytes at a time.

[0133] S205. Call the ioctl function with CMD12 as input parameter to end the write operation and complete the FFU operation.

[0134] S206. Through a single power-on / off initialization operation (Power Cycle), firmware changes in the firmware area take effect.

[0135] S207. After the SD card is powered on, the ioctl function is called with the access command VU cmd and the system drive letter as input parameters to enter the firmware area of ​​the SD card.

[0136] S208. Call the ioctl function with the standard read command CMD18 as input parameter to read the current firmware version information now-info in the firmware area.

[0137] S209. Compare the firmware version information pre-info before the firmware change with the current firmware version information now-info. If the version information matches the expected change, then the firmware change is confirmed to be successful.

[0138] S210. After calling the sprintf function to convert the current firmware version information now-info into a string, the data is then concatenated and printed.

[0139] It should be noted that the firmware update method based on Embodiment 1 can be used to test whether the SD card can properly implement the FFU function on different platforms. For example... Figure 3 As shown, the test process is as follows: Step 311: Run the program compiled based on a firmware update method to enter the FFU process of the SD card. Step 312: After completing the FFU process, determine whether the firmware change has taken effect. If so, it means that the SD card can normally implement the FFU function on the current platform; otherwise, end the test.

[0140] Example 3

[0141] Please refer to Figure 4 A firmware testing method for verifying the consistency of static data on an SD card during the FFU process includes:

[0142] Step 321: Create a data template and fill the SD card with data according to the data template to obtain static data.

[0143] Step 322: Run the program compiled based on a firmware update method to enter the FFU process of the SD card.

[0144] Step 323: After completing the FFU process, determine whether the firmware change has taken effect. If so, proceed to step 324; otherwise, end the test.

[0145] Step 324: Perform data verification on the static data according to the data template. If the verification is successful, it means that the static data of the SD card remains consistent during the FFU process; otherwise, end the test.

[0146] Example 4

[0147] Please refer to Figure 5 A firmware testing method for verifying whether an SD card supports firmware hot-upgrade / downgrade functionality under I / O (input / output) conditions, including:

[0148] Step 331: Use the FIO tool (a tool for I / O performance testing) to perform I / O testing on the SD card.

[0149] Step 332: During the IO test, run the program compiled based on a firmware update method to enter the FFU process of the SD card to perform a hot upgrade of the SD card firmware.

[0150] Step 333: After completing the FFU process, determine whether the firmware change has taken effect. If so, it means that the SD card supports firmware hot upgrade test under I / O conditions; otherwise, end the test.

[0151] Step 334: After the hot upgrade is successful, continue the IO test process and run the program compiled based on a firmware update method again to enter the FFU process of the SD card in order to hot downgrade the firmware of the SD card.

[0152] Step 335: After completing the FFU process, determine whether the firmware change has taken effect. If so, it means that the SD card supports firmware hot downgrade test under I / O conditions; otherwise, end the test.

[0153] Example 5

[0154] Please refer to Figure 6 A firmware testing method for verifying the consistency of static data on an SD card during hot upgrades and downgrades under I / O (input / output) conditions, including:

[0155] Step 341: Create a data template and fill the SD card with data based on the data template.

[0156] Step 342: Use the FIO tool (a tool for I / O performance testing) to perform I / O testing on the SD card.

[0157] Step 343: During the IO test, run a program compiled based on a firmware update method to enter the FFU process of the SD card, so as to perform hot upgrade and hot downgrade of the firmware of the SD card.

[0158] Step 344: After completing the FFU process, determine whether the firmware change has taken effect. If yes, proceed to step 345; otherwise, end the test.

[0159] Step 345: Perform data verification on the static data according to the data template. If the verification is successful, it means that the static data remains consistent during the hot upgrade and downgrade process; otherwise, the test ends.

[0160] Example 6

[0161] A firmware testing method includes the firmware testing methods of Embodiments 2 to 5 described above, thereby expanding the types of test cases.

[0162] Example 7

[0163] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the firmware update method as described in Embodiments 1 and 2.

[0164] Example 8

[0165] Please refer to Figure 7 An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the firmware update method as described in Embodiment 1 and Embodiment 2.

[0166] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0167] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0168] In summary, this invention provides a firmware update and testing method, a readable storage medium, and an electronic device. It accesses the firmware area of ​​an SD card via a firmware interface, directly invoking standard SD card commands within the firmware area to achieve firmware updates and information reading. This eliminates the need to consider command set differences caused by different system images, reducing the cost of repetitive development and improving the versatility of SD card FFU operations. Furthermore, this invention determines whether a user needs to query firmware information by checking if a firmware file exists in the specified path, enabling separate reading and viewing of firmware information. Moreover, since the program compiled based on this firmware update method is a standalone tool, it can be easily copied and deployed on embedded platforms running different versions of Linux system images, eliminating the need for complex development, compilation, flashing, and environment setup processes, thus improving user-friendliness.

[0169] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0170] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0171] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0172] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0173] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0174] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0175] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A firmware update method, characterized in that, Platforms used with operating systems running the Linux kernel include: The system drive letter is obtained based on the SD card access interface, and the system drive letter is used as the control object parameter of the input / output control function; Check if the target firmware file for the SD card exists in the current absolute path; If the target firmware file exists, then the target firmware file is read into the system's cache. The update instruction is called according to the input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored; the update instruction includes the common standard write command of the SD card, and the standard write command is called according to the input / output control function to write the target firmware file in the cache area to the firmware area; After the firmware in the firmware area is updated, a read instruction is called according to the input / output control function to read the first firmware information from the firmware area; The first firmware information is compared with the original firmware information in the firmware area. If the comparison result matches the expected difference, the firmware update of the SD card is confirmed to be successful.

2. The firmware update method according to claim 1, characterized in that, Also includes: If the target firmware file does not exist, the read instruction is invoked to read the original firmware information from the firmware area, and the original firmware information is converted into a string format and then printed out.

3. The firmware update method according to claim 1, characterized in that, The detection of whether the target firmware file for the SD card exists in the current absolute path includes: Check if the firmware file for the SD card exists in the current absolute path, and that the name of the firmware file conforms to the preset naming rules; If so, then it is determined that the target firmware file exists under the absolute path; Otherwise, it is determined that the target firmware file does not exist under the absolute path.

4. The firmware update method according to claim 1, characterized in that, The update instruction also includes an access instruction; The process of calling an update instruction according to an input / output control function to update the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored includes: The input / output control function calls the access instruction to open the pre-packaged firmware interface of the SD card, so as to access the firmware area of ​​the SD card where the original firmware file is stored through the firmware interface; After accessing the firmware area, the target firmware file in the cache is written to the firmware area by calling the standard write command according to the input / output control function.

5. The firmware update method according to claim 1, characterized in that, The read instructions include access instructions and the standard read command of the SD card; Calling a read instruction according to the input / output control function to read first firmware information from the firmware area includes: The input / output control function calls the access instruction to open the pre-packaged firmware interface of the SD card, so as to access the firmware area through the firmware interface; After accessing the firmware area, the first firmware information is read from the firmware area by calling the standard read command according to the input / output control function.

6. The firmware update method according to claim 1, characterized in that, After updating the target firmware file in the cache area to the firmware area of ​​the SD card where the original firmware file is stored, the process further includes: The system's power management service controls the SD card to perform power-on and power-off initialization operations, enabling the SD card to complete firmware updates based on the target firmware file.

7. The firmware update method according to claim 1, characterized in that, Before checking if the target firmware file for the SD card exists in the current absolute path, the process also includes: The system drive letter is obtained based on the SD card access interface, and the system drive letter is used as the control object parameter of the input / output control function.

8. A firmware testing method, characterized in that, include: Create a data template, and fill the SD card with data according to the data template to obtain static data; Perform each step of the firmware update method as described in any one of claims 1-7; After the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware update process.

9. A firmware testing method, characterized in that, include: When testing the SD card using an input / output performance testing tool, each step of the firmware update method as described in any one of claims 1-7 is executed to perform hot upgrades and hot downgrades of the firmware of the SD card, respectively. If the firmware update of the SD card is successful, it is determined that the SD card supports firmware hot-upgrade and hot-downgrade operations when performing input / output operations.

10. A firmware testing method, characterized in that, include: Create a data template, and fill the SD card with data according to the data template to obtain static data; When testing the SD card using an input / output performance testing tool, each step of the firmware update method as described in any one of claims 1-7 is executed to perform hot upgrades and hot downgrades of the firmware of the SD card, respectively. If the firmware update of the SD card is successful, the static data is verified according to the data template. If the verification is successful, it is determined that the static data of the SD card remains consistent during the firmware hot upgrade and hot downgrade process.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the firmware update method as described in any one of claims 1-7.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements each step of the firmware update method as described in any one of claims 1-7.

Images