Soundbar firmware U disk upgrading method

Abstract

The present application relates to the technical field of firmware upgrade, in particular to a Soundbar firmware U disk upgrade method, comprising the following steps: reading and normalizing the U disk hardware serial number to obtain a normalized serial number, signing the normalized serial number by an authorized system after the consent of a manager, generating an authorization file and storing it in the U disk; a maintenance personnel client verifies the U disk according to the U disk hardware serial number and the authorization file, and downloads an upgrade configuration file and an upgrade package after verification. In the present application, after all upgrade objects complete the upgrade, the final upgrade judgment is completed, and the SHA256 value corresponding to the successful upgrade package is recorded, so that the device forms a sustainable upgrade history, provides a unified data basis for subsequent version identification, repeated upgrade judgment and batch maintenance, and improves the safety, stability and maintenance efficiency of the upgrade process.

Description

Technical Field

[0001] This invention relates to the field of firmware upgrade technology, and in particular to a method for upgrading Soundbar firmware via USB flash drive. Background Technology

[0002] A soundbar is an audio device that integrates multiple channel speakers and an amplifier into a single, elongated enclosure. It is primarily used with flat-screen TVs to compensate for the limitations of their built-in speakers and to provide a more convenient alternative to traditional multi-speaker home theaters.

[0003] In soundbar products, especially those without Wi-Fi, USB flash drive upgrades are the most common method. While simple and convenient, it has significant drawbacks: lack of control and low security. Any USB flash drive containing any upgrade package can trigger an upgrade. If the wrong firmware is installed, the soundbar software may become completely unusable, resulting in substantial after-sales maintenance costs. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method for upgrading Soundbar firmware via USB flash drive.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for upgrading Soundbar firmware via USB flash drive, comprising the following steps:

[0006] The system reads and normalizes the USB flash drive's hardware serial number to obtain a normalized serial number. After the administrator approves the normalized serial number, the system signs the normalized serial number, generates an authorization file, and stores it in the USB flash drive.

[0007] The maintenance personnel client verifies the USB flash drive based on the USB flash drive's hardware serial number and the authorization file. After successful verification, the upgrade configuration file and upgrade package are downloaded.

[0008] The upgrade package is verified according to the SHA256 value in the upgrade configuration file;

[0009] The SOC verifies the USB flash drive based on its hardware serial number and the authorization file, and verifies the upgrade package according to the file size and SHA256 value in the upgrade configuration file.

[0010] The target upgrade package is obtained by comparing the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash.

[0011] The SOC determines the peripherals to be upgraded based on the target upgrade package, performs concurrent upgrades, and performs packet CRC16 verification and retransmission on the transmitted data.

[0012] After all the peripherals to be upgraded are successfully upgraded, the SOC upgrade determination is performed according to the target upgrade package. If the determination is successful, the SHA256 value of the successful upgrade package is written to Flash.

[0013] Preferably, the steps of reading and normalizing the USB flash drive hardware serial number to obtain a normalized serial number, having the normalized serial number signed by the authorization system after approval by the administrator, generating an authorization file, and storing it in the USB flash drive are as follows:

[0014] Generate an RSA-4096 key pair, configure the private key of the RSA-4096 key pair in the authorization system, and configure the public key of the RSA-4096 key pair in the maintenance personnel client and the SOC;

[0015] The maintenance personnel read the USB flash drive's hardware serial number from the client, and then perform space removal and lowercase conversion on the USB flash drive's hardware serial number to obtain the normalized serial number;

[0016] The maintenance personnel's client sends the standardized serial number and authorization request to the authorization system, and the management personnel's client receives the consent instruction input by the management personnel;

[0017] The authorization system responds to the consent instruction by signing the normalized serial number with the private key to obtain the authorization file and returns it to the maintenance personnel's client.

[0018] The maintenance personnel's client writes the authorization file to a fixed directory and a fixed file on the USB drive, and sets the fixed directory and the fixed file to have hidden attributes.

[0019] Preferably, the maintenance personnel client verifies the USB flash drive based on the USB flash drive hardware serial number and the authorization file, and then downloads the upgrade configuration file and upgrade package after successful verification. The specific steps are as follows:

[0020] The maintenance personnel's client reads the USB flash drive's hardware serial number, performs space removal and lowercase conversion on the USB flash drive's hardware serial number, and obtains the hardware serial number to be verified.

[0021] The maintenance personnel's client reads the authorization file and uses the public key to verify the serial number of the hardware to be verified and the authorization file;

[0022] After the signature verification is passed, the maintenance personnel's client downloads the upgrade configuration file from the upgrade management system. The upgrade configuration file records the file name, file size, download address, version number, and SHA256 value of each upgrade package.

[0023] The maintenance personnel download the upgrade packages one by one from the download address using the client, and write the upgrade configuration file and the upgrade package to the USB drive.

[0024] Preferably, the step of verifying the upgrade package based on the SHA256 value in the upgrade configuration file specifically includes:

[0025] The maintenance personnel read each downloaded upgrade package from their client and calculate the client's SHA256 value.

[0026] The maintenance personnel client queries the configuration SHA256 value in the upgrade configuration file according to the file name of the upgrade package, and compares the client SHA256 value with the configuration SHA256 value byte by byte.

[0027] When the client's SHA256 value is inconsistent with the configured SHA256 value, the corresponding upgrade package is deleted, and the upgrade package is re-downloaded according to the download address until the recalculated client SHA256 value is consistent with the configured SHA256 value.

[0028] Preferably, the steps of the SOC verifying the USB flash drive based on the USB flash drive hardware serial number and the authorization file, and verifying the upgrade package according to the file size and SHA256 value in the upgrade configuration file, are as follows:

[0029] The SOC detects the USB flash drive connection, reads the USB flash drive hardware serial number, and performs space removal and lowercase conversion on the USB flash drive hardware serial number to obtain the device-side hardware serial number.

[0030] The SOC reads the authorization file and uses the public key to verify the hardware serial number on the device side and the authorization file. If the verification fails, the upgrade process is terminated.

[0031] After the signature verification is passed, the SOC reads the upgrade configuration file and each upgrade package, counts the actual number of bytes in each upgrade package, and calculates the device-side SHA256 value.

[0032] The SOC compares the actual number of bytes with the file size, and the SHA256 value on the device side with the SHA256 value in the upgrade configuration file. The upgrade package that matches both comparisons is determined to be the verified upgrade package.

[0033] Preferably, the specific steps for comparing the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash to obtain the target upgrade package are as follows:

[0034] The SOC reads the historical SHA256 value stored in the Flash according to the upgrade object identifier. The historical SHA256 value is the SHA256 value of the last successful upgrade package of the corresponding upgrade object. The upgrade object identifier corresponding to each verified upgrade package is determined according to the upgrade configuration file.

[0035] The SOC compares the SHA256 value of each verified upgrade package with the corresponding historical SHA256 value byte by byte according to the upgrade object identifier;

[0036] The SOC excludes upgrade packages with the same SHA256 value, and determines upgrade packages with inconsistent SHA256 values ​​and upgrade packages for which there is no corresponding historical SHA256 value in the Flash as the target upgrade packages;

[0037] If the target upgrade package is not available, the SOC will terminate the upgrade process.

[0038] Preferably, the SOC determines the peripheral device to be upgraded based on the target upgrade package, performs concurrent upgrades, and the specific steps of packetizing, CRC16 checking, and retransmitting the transmitted data are as follows:

[0039] The peripherals include an HDMI unit, a Bluetooth unit, a TX unit, a Subwoofer, a left Surround speaker, and a right Surround speaker. The upgrade object identifier of each target upgrade package is read from the upgrade configuration file, and the peripheral to be upgraded is determined based on the upgrade object identifier.

[0040] The HDMI unit, Bluetooth unit, and TX unit in the peripheral device to be upgraded are concurrently upgraded by the SOC, and the Subwoofer subwoofer, left Surround speaker, and right Surround speaker in the peripheral device to be upgraded are concurrently upgraded by the TX unit.

[0041] The SOC divides the corresponding upgrade package data into multiple data packets, writes a packet sequence number and a CRC16 checksum into each data packet, and sends the data packet to the corresponding peripheral device to be upgraded.

[0042] The CRC16 checksum of the received data is calculated by the external device to be upgraded, and the calculation result is compared with the CRC16 checksum carried by the data packet. If the comparison is inconsistent, a retransmission request containing the packet sequence number is returned.

[0043] The SOC retransmits the corresponding data packet according to the retransmission request. After all the corresponding data packets pass the verification and are written, the peripheral device to be upgraded sends an upgrade success message to the SOC.

[0044] Preferably, after all the peripherals to be upgraded have been successfully upgraded, the step of performing a SOC upgrade determination based on the target upgrade package, and writing the SHA256 value of the successful upgrade package to Flash after the determination is passed, specifically includes:

[0045] The SOC receives the upgrade success message sent by each of the peripherals to be upgraded, checks the upgrade status of all the peripherals to be upgraded, and determines that the SOC upgrade determination has failed if not all the peripherals to be upgraded have been successfully upgraded.

[0046] When all the peripherals to be upgraded have been successfully upgraded and the target upgrade package includes the SOC upgrade package, the SOC executes the SOC upgrade package to complete the writing and startup verification of the SOC's own firmware. When the upgrade is successful, the SOC upgrade determination is passed.

[0047] When all the peripherals to be upgraded have been successfully upgraded and the target upgrade package does not include the SOC upgrade package, the SOC upgrade decision is determined to be successful.

[0048] When the SOC upgrade determination is passed, the SOC writes the SHA256 value of each target upgrade package that was successfully upgraded into the Flash according to the upgrade object identifier, and updates the corresponding historical SHA256 value.

[0049] If the SOC upgrade fails, the corresponding historical SHA256 value in the Flash memory will not be updated.

[0050] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0051] In this invention, by reading and standardizing the USB flash drive's hardware serial number and generating an authorization file after authorization confirmation, a stable association is established between the upgrade medium and the unique hardware identifier. This avoids the mixing of upgrade data between different storage media, improves the accuracy of upgrade target identification, and ensures clear identity verification criteria during the upgrade preparation phase. Authorization verification is completed before downloading the upgrade package, and integrity verification is performed based on the file information and SHA256 value recorded in the upgrade configuration file. This ensures consistency of upgrade data during acquisition, storage, and use, reducing the impact of file corruption, download anomalies, and data tampering on the upgrade results and guaranteeing the reliability of data entering the upgrade process. During the upgrade phase, verification is again performed based on the standardized serial number and authorization file, and file size and SHA256 value are simultaneously verified. This creates a continuous verification link between the data states before and after the upgrade, enhancing the consistency of the entire upgrade process. The SHA256 value of the verified upgrade package is compared with historical SHA256 values. Only data with differences is selected for the upgrade, avoiding repeated writing of the same version to memory, which increases storage write cycles and extends upgrade time, thus improving upgrade resource utilization efficiency. Based on the target upgrade package, the system identifies the objects to be upgraded and performs concurrent upgrades. Simultaneously, it employs packet verification and anomaly retransmission mechanisms for transmitted data to maintain the continuity and integrity of the upgrade transmission. In the event of local data anomalies, only the corresponding data packets are retransmitted, reducing the time consumed by overall repetitive transmissions. The final upgrade determination is performed only after all upgrade objects have been upgraded, and the SHA256 value corresponding to the successful upgrade package is recorded. This creates a continuously traceable upgrade history for the device, providing a unified data basis for subsequent version identification, duplicate upgrade determination, and batch maintenance, thereby improving the security, stability, and maintenance efficiency of the upgrade process. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0054] The meanings of non-Chinese technical terms and English abbreviations used in this manual are explained as follows: Soundbar refers to a soundbar enclosure, also known as a soundbar speaker; USB flash drive refers to a USB flash drive, where USB is an abbreviation for Universal Serial Bus; SOC is an abbreviation for System on Chip; HDMI is an abbreviation for High Definition Multimedia Interface; Bluetooth refers to a short-range wireless communication technology, where BT is an abbreviation for Bluetooth; TX is an abbreviation for Transmit or Transmitter, indicating a transmitting unit or transmitter in this manual; Subwoofer refers to a subwoofer or subwoofer speaker, where SUB is an abbreviation for Subwoofer; Surround refers to a surround sound system, where Left Surround indicates a left surround speaker, Right Surround indicates a right surround speaker, LS is an abbreviation for Left Surround, indicating a left surround speaker in this manual, and RS is an abbreviation for Right Surround. Surround is an abbreviation for right surround speakers in this manual; SHA256, also written as SHA-256, is an abbreviation for Secure Hash Algorithm 256-bit, used to generate a 256-bit message digest, which corresponds to 64 hexadecimal characters when represented in hexadecimal; Flash is a flash memory or flash storage device used in this manual to store upgrade history information and other data; CRC16, also written as CRC-16, is an abbreviation for 16-bit Cyclic Redundancy Check, used to detect errors in transmitted data; RSA is an abbreviation for Rivest-Shamir-Adleman, an asymmetric cryptographic algorithm, and RSA-4096 indicates an RSA algorithm using a 4096-bit key length; ".bin" is an abbreviation for binary, and in this manual, ".bin" represents the file extension for binary firmware files; ECDSA is an abbreviation for Elliptic Curve Digital Signature. The abbreviation for Algorithm refers to Elliptic Curve Digital Signature Algorithm. Ed25519 is a digital signature algorithm constructed based on the Edwards curve and related parameters of Curve25519, and is used in this specification to represent an optional digital signature algorithm. Unless otherwise specified, the above English names, abbreviations, or symbols appearing in this specification thereafter have the same meanings as described in this paragraph.

[0055] Please see Figure 1 The following describes a method for upgrading soundbar firmware via USB flash drive, using specific embodiments. This embodiment applies to soundbars that are maintained offline via USB flash drive. The soundbar includes a SOC, HDMI unit, Bluetooth unit, TX unit, subwoofer, left surround speaker, and right surround speaker. Maintenance personnel apply for USB flash drive authorization and download upgrade data. Management personnel review the authorization application, and the device manufacturer pre-uploads the upgrade configuration file and upgrade package.

[0056] This embodiment divides the upgrade process into USB flash drive authorization, client-side verification and download, client-side integrity verification, device-side verification and integrity verification, duplicate upgrade screening, concurrent peripheral upgrade, SOC upgrade determination, and upgrade history writing. Each stage calls the data generated in the previous stage, forming a control link that links the upgrade media identity, upgrade file content, and upgrade result.

[0057] Read and standardize the USB flash drive hardware serial number to obtain a standardized serial number. After the administrator approves the standardized serial number, the authorization system signs the standardized serial number, generates an authorization file, and saves it to the USB flash drive.

[0058] In this embodiment, the maintenance personnel client reads the hardware serial number provided by the USB flash drive controller, removes spaces, and converts English letters to lowercase to obtain a normalized serial number. The maintenance personnel client sends the normalized serial number and authorization request to the authorization system. After the administrator verifies the applicant, maintenance task, and USB flash drive information, they input an agreement command. Only then does the authorization system use its private key to digitally sign the normalized serial number. The generated authorization file is returned to the maintenance personnel client and written to a fixed directory on the USB flash drive, establishing a verifiable relationship between the authorization file and the current hardware identity of the USB flash drive.

[0059] The maintenance personnel's client verifies the USB flash drive based on its hardware serial number and authorization file. After successful verification, the upgrade configuration file and upgrade package are downloaded.

[0060] In this embodiment, the maintenance personnel client reads the hardware serial number of the current USB drive again and performs the same normalization process. It reads the authorization file from a fixed directory and uses a preset public key to verify whether the authorization file corresponds to the current USB drive. If the verification passes, the maintenance personnel client requests the upgrade configuration file based on the Soundbar product model, hardware version, and target version, and obtains the corresponding upgrade package from the download address recorded in the upgrade configuration file. If the verification fails, the download process is not initiated, thereby preventing unauthorized USB drives from obtaining controlled upgrade data.

[0061] Verify the upgrade package based on the SHA256 value in the upgrade configuration file;

[0062] In this embodiment, after each upgrade package is downloaded, the maintenance personnel read all bytes of the file on the client and calculate its SHA256 value. The calculated result is compared with the SHA256 value of the record with the same name in the upgrade configuration file. If they match, the temporary file is renamed to the official file name and written to the upgrade directory; if they do not match, the file is deleted and downloaded again. This process can detect content changes caused by network transmission interruptions, cache anomalies, file replacements, and USB drive write errors.

[0063] SOC verifies the USB flash drive based on its hardware serial number and authorization file, and verifies the upgrade package according to the file size and SHA256 value in the upgrade configuration file.

[0064] In this embodiment, after the USB flash drive is connected to the soundbar, the SOC rereads and normalizes the USB flash drive's hardware serial number, and uses the pre-installed public key in the SOC to verify the authorization file. After successful verification, the SOC reads the upgrade configuration file and upgrade package, counts the actual number of bytes for each upgrade package, and calculates the device-side SHA256 value. Only when the actual number of bytes equals the file size in the configuration file and the device-side SHA256 value equals the SHA256 value in the configuration file is the corresponding upgrade package allowed to proceed to the next step. Therefore, it can identify file truncation, overwriting, or tampering that occurs after the USB flash drive is disconnected from the computer.

[0065] The target upgrade package is obtained by comparing the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash.

[0066] In this embodiment, the SOC reads the historical SHA256 value of the most recent successful upgrade package from the Flash memory according to the upgrade target identifier. If the SHA256 value of the current upgrade package matches the corresponding historical SHA256 value, the SOC excludes the upgrade package; if they do not match or there is no corresponding record in the Flash memory, the SOC adds the upgrade package to the target upgrade package set. Therefore, when the same USB drive is repeatedly inserted into the same soundbar, the same firmware will not be erased or rewritten, and the same USB drive can still be used to upgrade multiple soundbars.

[0067] The SOC determines the peripherals to be upgraded based on the target upgrade package, performs concurrent upgrades, and performs packet CRC16 verification and retransmission on the transmitted data.

[0068] In this embodiment, the SOC establishes multiple upgrade tasks based on the upgrade target identifier in the target upgrade package, directly controlling the HDMI unit, Bluetooth unit, and TX unit, and transmitting data to the Subwoofer subwoofer, left Surround speaker, and right Surround speaker through the TX unit. Upgrade tasks are alternately scheduled when the communication link is available, allowing the transmission and writing processes of multiple peripherals to occur concurrently. Each upgrade package is divided into data packets with a packet sequence number and a CRC16 checksum. When the receiving end detects a CRC16 checksum failure, it returns the corresponding packet sequence number, and the SOC only retransmits the erroneous data packet.

[0069] After all peripherals have been successfully upgraded, the SOC upgrade determination is performed based on the target upgrade package. If the determination is successful, the SHA256 value of the successful upgrade package is written to Flash.

[0070] In this embodiment, each peripheral device to be upgraded sends an upgrade success message to the SOC after completing data reception, firmware writing, and boot check. After confirming that all peripheral devices to be upgraded have succeeded, the SOC determines whether the target upgrade package includes the SOC upgrade package. If it does, the SOC performs its own firmware writing and boot verification; otherwise, it does not perform any irrelevant SOC writing. After the SOC upgrade determination is passed, it writes the SHA256 value of the successful upgrade package to Flash according to the upgrade target identifier for use in the next upgrade selection.

[0071] The specific steps for reading and standardizing the USB flash drive's hardware serial number, obtaining a standardized serial number, having it approved by administrators, having the authorized system sign the standardized serial number, generating an authorization file, and saving it to the USB flash drive are as follows:

[0072] This embodiment adopts a public-private key separation configuration. The signing private key is only located in the authorization system, and the maintenance personnel client and SOC only store the signature verification public key. Therefore, the public data in the client or USB flash drive cannot be used to generate a valid authorization file.

[0073] Generate an RSA-4096 key pair, configure the private key of the RSA-4096 key pair in the authorization system, and configure the public key of the RSA-4096 key pair in the maintenance personnel client and SOC;

[0074] In this embodiment, the device manufacturer generates an RSA-4096 key pair in a controlled environment, imports the private key into the protected storage area of ​​the authorization system, and writes the public key as a read-only resource into the maintenance personnel's client and the SOC firmware. The authorization system restricts access to the private key, only allowing it to be accessed when an administrator approves the corresponding authorization request. The authorization file may record the public key version number so that a matching public key can be selected for verification after a key update.

[0075] The maintenance personnel read the USB flash drive's hardware serial number from the client, and then perform space removal and lowercase letter conversion on the USB flash drive's hardware serial number to obtain a normalized serial number;

[0076] In this embodiment, if the read hardware serial number is AB 12 CD 34 EF, after removing spaces and lowercase letters, it becomes ab12cd34ef. The same processing rule is applied simultaneously to the authorization stage, client verification stage, and SOC verification stage to eliminate display differences in spaces and letter case in the operating system interface. If no hardware serial number is read or the processing result is empty, the maintenance personnel terminate the application on the client side.

[0077] The maintenance personnel's client sends a standardized serial number and authorization request to the authorization system, and the administrator's client receives the consent instruction entered by the administrator;

[0078] In this embodiment, the authorization application includes a standardized serial number, maintenance personnel account, application time, target product series, and usage description. The authorization system generates an application number and displays the application information to the administrator's client. After verifying the actual maintenance task, the administrator enters an approval command; if the application is rejected or not processed within the approval period, the authorization system does not execute the signature.

[0079] The authorization system responds to the consent instruction, uses the private key to sign the normalized serial number, obtains the authorization file, and returns it to the maintenance personnel's client;

[0080] In this embodiment, the authorization system forms a sequence of bytes to be signed using a predefined character encoding based on the normalized sequence number, and generates a signature value using an RSA-4096 private key. The authorization file includes at least the file version, public key version, signature length, and signature value. After receiving the authorization file, the maintenance personnel client can first perform a self-verification signature using the local public key to confirm that the file has not been corrupted during transmission.

[0081] The maintenance personnel write the authorization file to a fixed directory and a fixed file on the USB drive using the client, and set the fixed directory and fixed file to have hidden attributes.

[0082] In this embodiment, the fixed directory is located in the root directory of the USB drive, and the fixed file uses a filename agreed upon by all clients and the SOC. After writing is complete, the maintenance personnel client sets the directory and file to hidden attributes and can set the fixed file to read-only attributes, then reads the fixed file again to confirm that the written content is consistent with the content returned by the authorization system. The hidden attribute is used to reduce the probability of accidental deletion caused by ordinary file browsing and cleanup operations.

[0083] The maintenance personnel client verifies the USB flash drive based on its hardware serial number and authorization file. After successful verification, the steps for downloading the upgrade configuration file and upgrade package are as follows:

[0084] This embodiment establishes a USB drive identity threshold before upgrading data download. When the authorization file is copied to other USB drives, the copied authorization file cannot pass the signature verification due to the different hardware serial numbers.

[0085] The maintenance personnel read the USB flash drive's hardware serial number from the client, and then perform space removal and lowercase conversion on the USB flash drive's hardware serial number to obtain the hardware serial number to be verified.

[0086] In this embodiment, the maintenance personnel client removes spaces and converts them to lowercase in the same order as during authorization to obtain the hardware serial number to be verified. The drive letter, volume label, and file system volume serial number are not used as the hardware serial number to avoid changes in authorized identity due to formatting or user modification of the volume label.

[0087] The maintenance personnel read the authorization file from the client and use the public key to verify the signature of the hardware serial number to be verified and the authorization file.

[0088] In this embodiment, the maintenance personnel client selects a public key based on the public key version in the authorization file, uses the hardware serial number to be verified as the signature verification message, and performs RSA signature verification on the signature value in the authorization file. If the signature verification fails, an error message is displayed indicating that the USB drive is unauthorized or the authorization file is abnormal, and the call to the upgrade management system's upgrade package download interface is prohibited.

[0089] After the signature verification is successful, the maintenance personnel download the upgrade configuration file from the upgrade management system via the client. The upgrade configuration file records the file name, file size, download address, version number, and SHA256 value of each upgrade package.

[0090] In this embodiment, when the device manufacturer releases the upgrade package, it simultaneously generates an upgrade configuration file. Each record corresponds to an upgrade object, and further records the upgrade object identifier. The upgrade object identifier is used to determine the recipient of the upgrade package, the file name is used to match local files, the file size and SHA256 value are used for dual integrity verification, the download address is used by the client to obtain the file, and the version number is used by maintenance personnel to identify the release batch.

[0091] Table 1 Example of upgrade configuration file

[0092] SOC soc_v210.bin 8388608 bytes 2.1.0 64-bit hexadecimal characters HDMI hdmi_v135.bin 1048576 bytes 1.3.5 64-bit hexadecimal characters BT bt_v122.bin 524288 bytes 1.2.2 64-bit hexadecimal characters TX tx_v108.bin 786432 bytes 1.0.8 64-bit hexadecimal characters SUB sub_v114.bin 1048576 bytes 1.1.4 64-bit hexadecimal characters LS ls_v114.bin 1048576 bytes 1.1.4 64-bit hexadecimal characters RS rs_v114.bin 1048576 bytes 1.1.4 64-bit hexadecimal characters

[0093] As can be seen from Table 1, the upgrade configuration file associates each upgrade package with the corresponding object through the upgrade object identifier, and provides two independent integrity verification criteria through file size and SHA256 value. Each upgrade object can be configured with different file names and version numbers.

[0094] The maintenance personnel download the upgrade packages one by one from the download address using the client, and write the upgrade configuration file and upgrade package to a USB flash drive.

[0095] In this embodiment, the maintenance personnel first check the remaining capacity of the USB drive on the client side, and then establish a download queue. The upgrade package is first written to a temporary file, and after being verified by SHA256 on the client side, it is moved to the official upgrade directory. After all upgrade packages have been written, the upgrade configuration file is written to the same directory, and the file names and file quantities are scanned to confirm that all files listed in the configuration file exist.

[0096] The specific steps for verifying the upgrade package based on the SHA256 value in the upgrade configuration file are as follows:

[0097] In this embodiment, the verification is performed between the completion of file download and the writing to the official upgrade directory, ensuring that abnormal files cannot be stored on the USB drive as usable upgrade packages.

[0098] The maintenance personnel read each downloaded upgrade package from the client and calculate the client's SHA256 value;

[0099] In this embodiment, the maintenance personnel read the upgrade package in segments and continuously update the SHA256 calculation status, outputting the client's SHA256 value at the end of the file. Segmented reading does not require loading the complete upgrade package into memory at once; if a reading fails, the corresponding upgrade package is directly marked as verification failed.

[0100] The maintenance personnel use the client to query the configuration SHA256 value in the upgrade configuration file based on the file name of the upgrade package, and then compare the client's SHA256 value with the configuration SHA256 value byte by byte.

[0101] In this embodiment, the maintenance personnel use the file name to query a unique configuration record, convert the configuration SHA256 value into a byte format identical to the client's SHA256 value, and then compare all bytes. If the configuration file contains duplicate file names, abnormal digest lengths, or illegal characters, the download task is terminated to avoid mismatches caused by incorrect configurations.

[0102] If the client's SHA256 value is inconsistent with the configured SHA256 value, delete the corresponding upgrade package and re-download the upgrade package according to the download address until the recalculated client SHA256 value is consistent with the configured SHA256 value.

[0103] In this embodiment, if a discrepancy is found, the temporary file is deleted and the corresponding download cache is cleared, and the file is retrieved again from the original download address. The maximum number of retries can be set to 3; if there are 3 consecutive discrepancies, the download is recorded as failed and processing of that file is stopped. Only when the recalculation results are consistent is the file written to the official upgrade directory.

[0104] The SOC verifies the USB flash drive based on its hardware serial number and authorization file, and verifies the upgrade package according to the file size and SHA256 value in the upgrade configuration file. The specific steps are as follows:

[0105] In this embodiment, the Soundbar independently verifies the USB drive's identity and upgrade package content, without directly relying on the verification results provided by the maintenance personnel's client, thus covering data changes that may occur during USB drive portability and on-site use.

[0106] The SOC detects the USB flash drive connection, reads the USB flash drive's hardware serial number, and performs space removal and lowercase conversion on the USB flash drive's hardware serial number to obtain the device-side hardware serial number.

[0107] In this embodiment, the SOC detects and enumerates the USB flash drive through the USB host interface, reads the hardware serial number from the device description information, and forms a device-side hardware serial number according to the same rules as the client. If USB enumeration fails, the hardware serial number is missing, or the fixed directory does not exist, the upgrade package is not read.

[0108] The SOC reads the authorization file and uses the public key to verify the hardware serial number and authorization file on the device side. The upgrade process is terminated if the verification fails.

[0109] In this embodiment, the SOC reads the signature value and public key version from the authorization file and selects the corresponding public key to verify the device-side hardware serial number. If signature verification fails, the SOC does not erase any existing firmware, but outputs the authorization failure status via indicator lights, a display screen, or a maintenance log, and securely uninstalls the USB flash drive file system.

[0110] After the signature verification is successful, the SOC reads the upgrade configuration file and each upgrade package, counts the actual number of bytes in each upgrade package, and calculates the SHA256 value on the device side.

[0111] In this embodiment, the SOC sequentially opens the upgrade package according to the upgrade configuration file, accumulates the number of bytes actually successfully read, and inputs the read content into the SHA256 calculation process. When the file reading is complete, the device-side SHA256 value is obtained. The actual number of bytes is based on the successful read result, rather than directly using the nominal length in the file directory entry.

[0112] The SOC compares the actual number of bytes with the file size, and the SHA256 value on the device side with the SHA256 value in the upgrade configuration file. Upgrade packages that match both comparisons are identified as verified upgrade packages.

[0113] In this embodiment, a discrepancy in the actual number of bytes indicates that the file may have been truncated or have data appended, while a discrepancy in the SHA256 value indicates that the file content has changed. For any discrepancy, the upgrade object identifier and the reason for failure are recorded, and the corresponding file is not added to the set of verified upgrade packages.

[0114] The specific steps to compare the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash to obtain the target upgrade package are as follows:

[0115] In this embodiment, independent historical records are set for different upgrade objects in Flash, so that the update of one upgrade object does not affect the repeated upgrade judgment of other upgrade objects.

[0116] The SOC reads the historical SHA256 values ​​stored in Flash according to the upgrade object identifier. The historical SHA256 values ​​are the SHA256 values ​​of the last successful upgrade package of the corresponding upgrade object. The upgrade object identifier corresponding to each verified upgrade package is determined according to the upgrade configuration file.

[0117] In this embodiment, each historical record includes an upgrade object identifier, a validity flag, and a historical SHA256 value. The SOC reads all valid records and, based on the upgrade configuration file, searches for records with the same upgrade object identifier for each verification through the upgrade package. When a new device is upgraded for the first time or when a newly added object has no historical records, the corresponding validity flag is empty.

[0118] The SOC compares the SHA256 value of each verified upgrade package with the corresponding historical SHA256 value byte by byte, according to the upgrade object identifier.

[0119] In this embodiment, the SOC only compares digests with the same upgrade object identifier, covering all bytes of the SHA256 value; any difference in any byte indicates an inconsistency. Even if the version number is the same but the file content has been revised, the SHA256 values ​​will still be different, thus the revised file can be identified as needing an upgrade.

[0120] The SOC excludes upgrade packages with the same SHA256 value, and identifies upgrade packages with inconsistent SHA256 values ​​and upgrade packages with no corresponding historical SHA256 value in Flash as target upgrade packages.

[0121] In this embodiment, upgrade packages with the same SHA256 value are marked as not requiring upgrades, and no corresponding task is created. Upgrade packages with inconsistent SHA256 values ​​or no historical records are added to the target upgrade package set, and their upgrade object identifier, file location, file size, and SHA256 value are retained for task scheduling and historical record updates.

[0122] If the target upgrade package is not available, the SOC will terminate the upgrade process.

[0123] In this embodiment, when all verified upgrade packages are consistent with the historical records, the SOC does not perform erasure, writing, or restart, outputs a prompt that the upgrade content has not changed, and safely unloads the USB drive, reducing invalid erasure and writing of Flash and peripheral memory.

[0124] The SOC determines the peripherals to be upgraded based on the target upgrade package, performs concurrent upgrades, and the specific steps of packetizing, CRC16 checking, and retransmitting transmitted data are as follows:

[0125] In this embodiment, concurrent upgrade refers to the SOC maintaining independent task states for multiple peripherals to be upgraded, scheduling other tasks to send data while one task is waiting for confirmation or performing a write operation, rather than requiring all links to send the same data at the same time.

[0126] The peripherals include an HDMI unit, a Bluetooth unit, a TX unit, a Subwoofer subwoofer, a left Surround speaker, and a right Surround speaker. The upgrade target identifier of each target upgrade package is read from the upgrade configuration file, and the peripherals to be upgraded are determined based on the upgrade target identifier.

[0127] In this embodiment, the SOC pre-stores the mapping between upgrade target identifiers and communication addresses. HDMI, BT, and TX correspond to direct-connect units, while SUB, LS, and RS are mapped to the corresponding wireless speakers through the TX unit. The SOC traverses the target upgrade packages and adds only peripherals with corresponding upgrade packages to the set of peripherals to be upgraded.

[0128] The HDMI unit, Bluetooth unit, and TX unit in the peripheral device to be upgraded are upgraded concurrently by the SOC, and the Subwoofer subwoofer, left Surround speaker, and right Surround speaker in the peripheral device to be upgraded are upgraded concurrently by the TX unit.

[0129] In this embodiment, the SOC establishes a transmission queue and state machine for directly connected peripherals, and cyclically schedules tasks in the transmittable state. After receiving the wireless speaker upgrade data, the TX unit forwards it according to the SUB, LS, and RS identifiers and maintains the reception progress. Objects not identified as peripherals to be upgraded retain their current firmware and are not required to return a success message.

[0130] The SOC divides the corresponding upgrade package data into multiple data packets, writes the packet sequence number and CRC16 checksum into each data packet, and sends the data packet to the corresponding peripheral device to be upgraded.

[0131] In this embodiment, the payload limit can be set to 1024 bytes, and the last packet is sent according to the actual remaining length. The packet sequence number starts from 0 and increments, and the CRC16 check range covers the packet sequence number, effective data length, and effective payload. The data packet carries an upgrade object identifier so that data is written to the correct receive buffer during concurrent transmission.

[0132] Table 2 Example of Subcontracting Data Structure

[0133] Upgrade object identifier 1 byte SOC, HDMI, BT, TX, SUB, LS, RS corresponding encoding Distinguish the receiving object Package number 4 bytes Incrementing from 0 Detection sequence and location retransmission Valid data length 2 bytes 1 to 1024 Indicates the effective payload length Payload 1 to 1024 bytes Upgrade package corresponding section Bearing firmware data CRC16 checksum 2 bytes Calculated according to parameters agreed upon by both communicating parties. Detect transmission errors

[0134] As can be seen from Table 2, the upgraded object identifier and packet sequence number can support the differentiation of multi-object tasks and the location of error packets, the effective data length is compatible with the last packet, and the CRC16 checksum can identify local transmission errors.

[0135] The outer casing to be upgraded calculates the CRC16 checksum of the received data, compares the calculation result with the CRC16 checksum carried in the data packet, and returns a retransmission request containing the packet sequence number when the comparison is inconsistent.

[0136] In this embodiment, the peripheral device to be upgraded uses the same CRC16 parameters as the SOC for calculation. If they match, the payload is written to the buffer according to the packet sequence number and an acknowledgment message is returned; if they do not match, the current data is not written, and the upgrade object identifier and packet sequence number are returned. When a duplicate packet or a packet sequence number out of range is received, the peripheral device to be upgraded outputs the corresponding status to avoid overwriting correct data.

[0137] The SOC resends the corresponding data packets according to the retransmission request. After all the corresponding data packets have been verified and written, the peripheral device to be upgraded sends an upgrade success message to the SOC.

[0138] In this embodiment, the SOC retains the transmission status and retransmission count of each data packet. Upon receiving a retransmission request, it rereads the corresponding segment from the upgrade packet. Other peripherals awaiting upgrade can still be scheduled during the retransmission of a data packet. After all data packets are confirmed, the peripheral to be upgraded verifies the complete image and performs firmware writing and boot checks. If successful, an upgrade success message is sent; if the preset retransmission count is exceeded, an upgrade failure message is sent.

[0139] After all peripherals have been successfully upgraded, the SOC upgrade determination is performed based on the target upgrade package. If the determination is successful, the SHA256 value of the successful upgrade package is written to the Flash. The specific steps are as follows:

[0140] This embodiment places the SOC's own upgrade after the peripheral device to be upgraded, to avoid the SOC restart interrupting the peripheral device transmission, and arranges the history update after the success determination to prevent failed tasks from being recorded as successful.

[0141] The SOC receives upgrade success messages from each peripheral to be upgraded, checks the upgrade status of all peripherals to be upgraded, and determines that the SOC upgrade decision has failed if not all peripherals to be upgraded have been successfully upgraded.

[0142] In this embodiment, the SOC records the waiting, transmitting, writing, successful, or failed status for each peripheral device to be upgraded. Upon receiving a successful upgrade message, the corresponding status is updated according to the upgrade object identifier. If any object fails or fails to return a success message within a preset time, the SOC determines that the upgrade has failed and records the failed object, packet sequence number, and error reason.

[0143] When all peripherals to be upgraded have been successfully upgraded and the target upgrade package includes the SOC upgrade package, the SOC executes the SOC upgrade package to complete the writing and boot verification of the SOC's own firmware. When the upgrade is successful, the SOC upgrade determination is confirmed to be passed.

[0144] In this embodiment, the SOC writes the SOC upgrade package to the backup firmware area. After writing, it verifies the contents of the backup firmware area and sets the boot flag. After rebooting, the new firmware completes basic peripheral initialization, configuration reading, and version self-check, writes the boot success flag, and the bootloader confirms the upgrade was successful. If the boot verification fails, the original firmware area is retained, and the upgrade is determined to have failed.

[0145] When all peripherals to be upgraded have been successfully upgraded and the target upgrade package does not include the SOC upgrade package, the SOC upgrade decision is deemed successful.

[0146] In this embodiment, when the target upgrade package only involves peripherals, there is no need to write to or restart the SOC to complete the process. After the SOC confirms that all peripherals to be upgraded are successful, it directly passes the judgment, reducing irrelevant operations and service interruption time.

[0147] When the SOC upgrade is approved, the SOC writes the SHA256 value of each target upgrade package that was successfully upgraded into the Flash according to the upgrade object identifier, and updates the corresponding historical SHA256 value.

[0148] In this embodiment, the SOC verifies the success status of each task corresponding to the target upgrade package. It first writes the upgrade target identifier and SHA256 value to a backup record, then reads back the verification data and updates the validity flag to reduce the probability of historical data corruption due to power failure. The historical SHA256 value of the SOC upgrade package is written after the new firmware boots and verification is successful.

[0149] If the SOC upgrade fails, the corresponding historical SHA256 value in Flash will not be updated.

[0150] In this embodiment, when the upgrade determination fails, the historical SHA256 value before the upgrade is retained, so that the failed object can still be identified as the target upgrade package when the USB flash drive is inserted again, and will not be skipped due to the error history.

[0151] To verify the above implementation process, scenarios were set up on the same Soundbar hardware, including unauthorized USB drive, copying of authorized files, corrupted upgrade package, repeated insertion of the same upgrade package, data packet error, and concurrent upgrade of multiple peripherals. Each scenario was repeated 100 times. The upgrade package used the file size shown in Table 1, and the maximum effective payload of the data packet was 1024 bytes. The test results are as follows.

[0152] Table 3. Verification Results of the Upgrade Process

[0153] Unauthorized USB flash drive access 100 100 0 2.1 seconds Copy the license file to another USB drive 100 100 0 2.3 seconds The contents of a single upgrade package are corrupted. 100 100 0 8.7 seconds Insert the same upgrade package again 100 100 0 6.4 seconds Injecting single-packet errors during transmission 100 100 0 96.8 seconds Upgrade 6 peripherals simultaneously 100 100 0 112.5 seconds Comparison of 6 peripheral upgrades 100 100 0 247.6 seconds

[0154] As shown in Table 3, USB drive identity mismatch, authorization file copying, and upgrade package corruption were all blocked before firmware writing. Reinsertion of the same upgrade package did not result in duplicate upgrades, and single-packet errors were resolved by retransmitting the corresponding data packet. Under the same file combination, the average completion time for concurrent upgrades was lower than that for sequential upgrades. The test data is consistent with the aforementioned verification, filtering, packet retransmission, and task scheduling logic.

[0155] The above parameters can be set according to the file system, storage capacity, and communication bandwidth. The signature algorithm can be ECDSA or Ed25519 while maintaining a verifiable binding relationship between the USB flash drive's hardware serial number and the authorization file.

[0156] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for upgrading Soundbar firmware via USB flash drive, characterized in that, Includes the following steps: The system reads and normalizes the USB flash drive's hardware serial number to obtain a normalized serial number. After the administrator approves the normalized serial number, the system signs the normalized serial number, generates an authorization file, and stores it in the USB flash drive. The maintenance personnel client verifies the USB flash drive based on the USB flash drive's hardware serial number and the authorization file. After successful verification, the upgrade configuration file and upgrade package are downloaded. The upgrade package is verified according to the SHA256 value in the upgrade configuration file; The SOC verifies the USB flash drive based on its hardware serial number and the authorization file, and verifies the upgrade package according to the file size and SHA256 value in the upgrade configuration file. The target upgrade package is obtained by comparing the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash. The SOC determines the peripherals to be upgraded based on the target upgrade package, performs concurrent upgrades, and performs packet CRC16 verification and retransmission on the transmitted data. After all the peripherals to be upgraded are successfully upgraded, the SOC upgrade determination is performed according to the target upgrade package. If the determination is successful, the SHA256 value of the successful upgrade package is written to Flash. The specific steps for reading and normalizing the USB flash drive hardware serial number to obtain a normalized serial number, having the normalized serial number signed by the authorization system after approval by the administrator, generating an authorization file, and storing it in the USB flash drive are as follows: Generate an RSA-4096 key pair, configure the private key of the RSA-4096 key pair in the authorization system, and configure the public key of the RSA-4096 key pair in the maintenance personnel client and the SOC; The maintenance personnel read the USB flash drive's hardware serial number from the client, and then perform space removal and lowercase conversion on the USB flash drive's hardware serial number to obtain the normalized serial number; The maintenance personnel's client sends the standardized serial number and authorization request to the authorization system, and the management personnel's client receives the consent instruction input by the management personnel; The authorization system responds to the consent instruction by signing the normalized serial number using the private key, obtaining the authorization file, and returning it to the maintenance personnel's client. The maintenance personnel's client writes the authorization file to a fixed directory and a fixed file on the USB drive, and sets the fixed directory and the fixed file to have hidden attributes; The SOC determines the peripherals to be upgraded based on the target upgrade package, performs concurrent upgrades, and the specific steps of packetizing, CRC16 verification, and retransmitting the transmitted data are as follows: The peripherals include an HDMI unit, a Bluetooth unit, a TX unit, a Subwoofer, a left Surround speaker, and a right Surround speaker. The upgrade object identifier of each target upgrade package is read from the upgrade configuration file, and the peripheral to be upgraded is determined based on the upgrade object identifier. The HDMI unit, Bluetooth unit, and TX unit in the peripheral device to be upgraded are concurrently upgraded by the SOC, and the Subwoofer subwoofer, left Surround speaker, and right Surround speaker in the peripheral device to be upgraded are concurrently upgraded by the TX unit. The SOC divides the corresponding upgrade package data into multiple data packets, writes a packet sequence number and a CRC16 checksum into each data packet, and sends the data packet to the corresponding peripheral device to be upgraded. The CRC16 checksum of the received data is calculated by the external device to be upgraded, and the calculation result is compared with the CRC16 checksum carried by the data packet. If the comparison is inconsistent, a retransmission request containing the packet sequence number is returned. The SOC retransmits the corresponding data packet according to the retransmission request. After all the corresponding data packets pass the verification and are written, the peripheral device to be upgraded sends an upgrade success message to the SOC.

2. The Soundbar firmware USB flash drive upgrade method according to claim 1, characterized in that, The maintenance personnel client verifies the USB flash drive based on the USB flash drive's hardware serial number and the authorization file. After successful verification, the steps for downloading the upgrade configuration file and upgrade package are as follows: The maintenance personnel read the USB flash drive's hardware serial number from the client, and then perform space removal and lowercase conversion on the USB flash drive's hardware serial number to obtain the hardware serial number to be verified. The maintenance personnel's client reads the authorization file and uses the public key to verify the serial number of the hardware to be verified and the authorization file; After the signature verification is passed, the maintenance personnel's client downloads the upgrade configuration file from the upgrade management system. The upgrade configuration file records the file name, file size, download address, version number, and SHA256 value of each upgrade package. The maintenance personnel download the upgrade packages one by one from the download address using the client, and write the upgrade configuration file and the upgrade package to the USB drive.

3. The Soundbar firmware USB flash drive upgrade method according to claim 2, characterized in that, The specific steps for verifying the upgrade package based on the SHA256 value in the upgrade configuration file are as follows: The maintenance personnel read each downloaded upgrade package from their client and calculate the client's SHA256 value. The maintenance personnel client queries the configuration SHA256 value in the upgrade configuration file according to the file name of the upgrade package, and compares the client SHA256 value with the configuration SHA256 value byte by byte. When the client's SHA256 value is inconsistent with the configured SHA256 value, the corresponding upgrade package is deleted, and the upgrade package is re-downloaded according to the download address until the recalculated client SHA256 value is consistent with the configured SHA256 value.

4. The Soundbar firmware USB flash drive upgrade method according to claim 1, characterized in that, The SOC verifies the USB flash drive based on its hardware serial number and the authorization file, and verifies the upgrade package according to the file size and SHA256 value in the upgrade configuration file. The specific steps are as follows: The SOC detects the USB flash drive connection, reads the USB flash drive hardware serial number, and performs space removal and lowercase conversion on the USB flash drive hardware serial number to obtain the device-side hardware serial number. The SOC reads the authorization file and uses the public key to verify the hardware serial number on the device side and the authorization file. If the verification fails, the upgrade process is terminated. After the signature verification is passed, the SOC reads the upgrade configuration file and each upgrade package, counts the actual number of bytes in each upgrade package, and calculates the device-side SHA256 value. The SOC compares the actual number of bytes with the file size, and the SHA256 value on the device side with the SHA256 value in the upgrade configuration file. The upgrade package that matches both comparisons is determined to be the verified upgrade package.

5. The Soundbar firmware USB flash drive upgrade method according to claim 4, characterized in that, The specific steps to compare the SHA256 value of the verified upgrade package with the historical SHA256 value in Flash to obtain the target upgrade package are as follows: The SOC reads the historical SHA256 value stored in the Flash according to the upgrade object identifier. The historical SHA256 value is the SHA256 value of the last successful upgrade package of the corresponding upgrade object. The upgrade object identifier corresponding to each verified upgrade package is determined according to the upgrade configuration file. The SOC compares the SHA256 value of each verified upgrade package with the corresponding historical SHA256 value byte by byte according to the upgrade object identifier; The SOC excludes upgrade packages with the same SHA256 value, and determines upgrade packages with inconsistent SHA256 values ​​and upgrade packages for which there is no corresponding historical SHA256 value in the Flash as the target upgrade packages; If the target upgrade package is not available, the SOC will terminate the upgrade process.

6. The Soundbar firmware USB flash drive upgrade method according to claim 5, characterized in that, After all the peripherals to be upgraded have been successfully upgraded, the SOC upgrade determination is performed based on the target upgrade package. The specific steps for writing the SHA256 value of the successful upgrade package to Flash after the determination is passed are as follows: The SOC receives the upgrade success message sent by each of the peripherals to be upgraded, checks the upgrade status of all the peripherals to be upgraded, and determines that the SOC upgrade determination has failed if not all the peripherals to be upgraded have been successfully upgraded. When all the peripherals to be upgraded have been successfully upgraded and the target upgrade package includes the SOC upgrade package, the SOC executes the SOC upgrade package to complete the writing and startup verification of the SOC's own firmware. When the upgrade is successful, the SOC upgrade determination is passed. When all the peripherals to be upgraded have been successfully upgraded and the target upgrade package does not include the SOC upgrade package, the SOC upgrade decision is determined to be successful. When the SOC upgrade determination is passed, the SOC writes the SHA256 value of each target upgrade package that was successfully upgraded into the Flash according to the upgrade object identifier, and updates the corresponding historical SHA256 value. If the SOC upgrade fails, the corresponding historical SHA256 value in the Flash memory will not be updated.

Images