A camera firmware upgrading method, system, device and storage medium

Abstract

Embodiments of the present application relate to the technical field of computer, and disclose a camera firmware upgrading method, system, device and storage medium, the method comprising: obtaining an OTA upgrading package, and extracting a check mapping table recording expected hash values corresponding to each sector; according to the check mapping table, issuing a hash calculation instruction of a sector to be checked to a functional module to be upgraded; obtaining actual hash values of the sector to be checked calculated and returned by the functional module; comparing the expected hash values and the actual hash values, and if the results are inconsistent, performing an upgrading operation on the sector. The technical solution of the present application solves the communication congestion problem of a low-speed bus when multiple cameras are concurrently upgraded by OTA in the prior art, and avoids communication timeout and bus lock.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, specifically to a method, system, device, and storage medium for upgrading camera firmware. Background Technology

[0002] In intelligent driving domain control systems, multi-view vehicle cameras are core components for environmental perception, and camera firmware needs to be frequently upgraded and iterated remotely via OTA. The cameras and domain controllers are interconnected via SerDes (serializer / deserializer): image and video data are transmitted through the high-speed SerDes channel, while control interactions such as firmware upgrades and register configurations can only be achieved through a bypass low-speed bus (I2C / SPI).

[0003] The existing firmware uses a differential upgrade scheme. To reduce the wear and tear on the camera's Flash memory, the upgrade process is as follows: read back the original firmware, compare all data with the domain controller, and write the new firmware only to the different partitions. This method works normally when upgrading a single camera, but it has many drawbacks when upgrading multiple cameras simultaneously via OTA: First, because the domain controller needs to transmit all firmware data of a single sector (4096 bytes) of the camera's Flash memory back to the domain controller's memory for byte-by-byte comparison via a low-speed I2C / SPI bus; the low transmission rate of I2C and SPI means that the simultaneous transmission of large amounts of data from multiple cameras can easily cause bus congestion, communication timeouts, or even bus freezes, directly reducing the efficiency and success rate of multi-camera OTA upgrades. Second, the domain controller's underlying driver needs to allocate a large amount of memory to cache the transmitted firmware, relying on the CPU to perform massive data byte-by-byte comparison operations, which consumes a large amount of system computing power and memory resources, squeezing the running resources of other high-priority tasks. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a camera firmware upgrade method, system, device and storage medium to solve the communication congestion problem of low-speed bus during concurrent OTA upgrades of multiple cameras in the prior art, and avoid communication timeouts and bus jamming.

[0005] According to one aspect of the present invention, a camera firmware upgrade method is provided, the method comprising: Obtain the OTA upgrade package and extract the verification mapping table containing the expected hash value for each sector. Based on the verification mapping table, a hash calculation instruction for the sector to be verified is sent to the functional module to be upgraded in firmware. Obtain the actual hash value of the sector to be verified, calculated and returned by the aforementioned functional module; If the expected hash value and the actual hash value are compared, and the results are inconsistent, an upgrade operation is performed on the sector.

[0006] In one alternative approach, issuing a hash calculation instruction for the sector to be verified to the functional module to be upgraded based on the verification mapping table includes the following sub-steps: Based on the aforementioned verification mapping table; A specific sector hash calculation instruction containing the instruction code, the starting physical address of the sector, and the length of the sector data is issued to the functional module.

[0007] In one alternative approach, obtaining the actual hash value of the sector to be verified, calculated and returned by the functional module, includes the following sub-steps: The functional module identifies and parses the hash calculation instruction; Read the raw data of the sector to be verified, calculate and return the actual hash value of the sector.

[0008] In one alternative approach, the step of reading the original data of the sector to be verified, calculating and returning the actual hash value of the sector, further includes the following sub-steps: The functional module performs a local hash operation based on the original data of the sector to be verified and obtains a 4-byte checksum. Write the check code into a preset register and set the status flag indicating that the calculation is complete. The check code is read when a status flag indicating that the calculation is complete is detected.

[0009] In an alternative approach, the step of reading the check code when the status flag is detected further includes the following sub-steps: The status flag is read according to a preset polling cycle; If a status flag indicating completion of the calculation is detected, then the checksum is read; If no completion status flag is detected, wait for the next query cycle and query again.

[0010] In one alternative approach, the step of waiting for the next query cycle after the status flag indicating completion of the calculation is not detected further includes: If the polling time exceeds the preset timeout threshold and the calculation completion status flag is still not detected; Then skip that sector and report the fault information to the outside world.

[0011] In one alternative approach, the sector to be verified is configured as a sector storing raw data from the camera.

[0012] In one alternative approach, after comparing the expected hash value and the actual hash value, and upgrading the sector if the results are inconsistent, the method further includes: After performing the upgrade operation on the sector; The hash calculation instruction is issued again to obtain the actual hash value of the sector; A second comparison is performed between the expected hash value and the actual hash value; If the results are consistent, the final verification is completed and the process moves to the next sector.

[0013] In one alternative approach, after comparing the expected hash value and the actual hash value, and upgrading the sector if the results are inconsistent, the method further includes: Compare the expected hash value with the actual hash value; If the results are the same, skip that sector.

[0014] According to a second aspect of the present invention, a camera firmware upgrade system is provided, comprising: At least one functional chip module for performing a preset function; and An upgrade module is configured to perform the steps of the camera firmware upgrade method according to any one of claims 1 to 9, in order to perform an upgrade operation on at least one of the functional chip modules.

[0015] In one alternative approach, at least one of the functional chip modules includes a computing module for calculating the actual hash value of the sector to be verified.

[0016] In one alternative embodiment, the upgrade module includes: The communication module is used to obtain OTA upgrade packages; to issue hash calculation commands; and to obtain the actual hash value of the sector to be verified. The parsing module is used to parse OTA upgrade packages and extract a verification mapping table containing the expected hash values ​​for each sector; and The execution module is used to compare the expected hash value with the actual hash value, and if the results are inconsistent, it performs an upgrade operation on the sector.

[0017] According to a third aspect of the present invention, a camera firmware upgrade device is provided, comprising: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform upgrade operations on each sector as described in the camera firmware upgrade method above.

[0018] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, wherein when the device containing the computer-readable storage medium executes the computer program, it implements the camera firmware upgrade method as described above.

[0019] This invention significantly reduces the need for the domain controller and camera to transmit large amounts of raw data back via a low-speed bus by offloading the firmware sector data verification task to a functional module inside the camera. This effectively alleviates communication congestion on the low-speed bus during concurrent OTA upgrades of multiple cameras, preventing communication timeouts and bus freezes. Simultaneously, the domain controller does not need to allocate large amounts of memory cache or perform massive data comparison operations, thus significantly reducing the consumption of system computing power and memory resources, and improving the overall efficiency and success rate of multi-camera OTA upgrades.

[0020] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a first embodiment of the camera firmware upgrade method provided by the present invention is shown. Figure 2 The flowchart illustrates a sub-step in step 120 of the first embodiment of the camera firmware upgrade method provided by the present invention. Figure 3 The flowchart of a sub-step in step 130 of the first embodiment of the camera firmware upgrade method provided by the present invention is shown. Figure 4 The flowchart illustrates a sub-step in step 132 of the first embodiment of the camera firmware upgrade method provided by the present invention. Figure 5 A schematic diagram of an embodiment of the camera firmware upgrade system provided by the present invention is shown; Figure 6 The flowchart illustrating the implementation of the camera firmware upgrade method provided by the present invention is shown. Detailed Implementation

[0022] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0023] Example 1: Figure 1 A flowchart of a first embodiment of the camera firmware upgrade method of the present invention is shown, which is executed by a camera firmware upgrade system. Figure 1 As shown, the method includes the following steps: Step 110: Obtain the OTA upgrade package and extract the verification mapping table that records the expected hash value corresponding to each sector.

[0024] The OTA upgrade package is a file package containing firmware update information and related metadata; the verification mapping table is a data structure that records the pre-calculated hash value corresponding to each sector in the OTA upgrade package, serving as the basis for data integrity verification.

[0025] Specifically, the upgrade module receives the OTA upgrade package through the communication interface. After receiving the package, the upgrade module can parse the entire OTA upgrade package to identify the firmware data and verification information contained within it. For example, the upgrade module can scan a specific header or footer of the upgrade package to locate and extract a pre-embedded verification mapping table. This verification mapping table can be a simple data structure that lists the identifier of each sector to be upgraded and its corresponding expected hash value.

[0026] Step 120: Based on the verification mapping table, send a hash calculation command for the sector to be verified to the functional module to be upgraded.

[0027] Among them, the functional module is a hardware or software unit inside the camera responsible for performing specific functions (such as data storage and hash calculation), such as a microcontroller or a dedicated processing unit; the hash calculation instruction is a command sent by the domain controller to the functional module, instructing the functional module to perform hash calculation on the data of a specified sector.

[0028] Specifically, after obtaining the verification mapping table, the upgrade module can select a sector to be verified based on the information in the table. Subsequently, the upgrade module sends a general hash calculation request to the functional module via the communication bus. This request may contain only a simple command word instructing the functional module to perform a hash calculation on the currently processed sector. Upon receiving this request, the functional module determines the range of sectors for which hash values ​​need to be calculated.

[0029] Step 130: Obtain the actual hash value of the sector to be verified, calculated and returned by the functional module.

[0030] The actual hash value refers to the hash value calculated locally by the functional module based on the original data of the sector to be verified, which is used to compare with the expected hash value.

[0031] Specifically, after completing the hash calculation, the functional module can directly return the calculated actual hash value to the upgrade module via the communication bus. The upgrade module can continuously monitor the communication bus, and once it receives data from the functional module, it will identify it as the actual hash value; for example, the functional module can package the calculation result into a fixed-length data frame and send it directly.

[0032] By sending only a fixed-length data frame to the upgrade module, the functional module addresses the problem in existing camera firmware upgrade solutions where, during simultaneous OTA upgrades of multiple cameras, the upgrade module transmits all firmware data from a single sector of the camera's Flash memory via a low-speed I2C / SPI bus. This causes bus congestion, communication timeouts, and even bus freezes due to the simultaneous transmission of large amounts of data from multiple cameras. The implementation of this invention significantly reduces the amount of communication data, and the low data transmission also greatly reduces the consumption of system computing power and memory resources, thereby improving the efficiency and success rate of multi-camera OTA upgrades.

[0033] Step 140: Compare the expected hash value with the actual hash value. If the results are inconsistent, perform an upgrade operation on the sector.

[0034] The expected hash value refers to the hash value recorded in the verification mapping table and pre-calculated when the firmware is released. It represents the correct state of the data in that sector and is used to compare it with the actual hash value. A sector refers to the smallest erasable and writable unit in flash memory, which usually has a fixed size, such as 4096 bytes.

[0035] Specifically, after receiving the actual hash value, the upgrade module compares it bit by bit with the expected hash value of the corresponding sector in the verification mapping table. If the comparison result shows any difference between the two hash values, it is determined that the data in that sector is inconsistent. In this case, the upgrade module will initiate the upgrade process for the inconsistent sector, for example, writing the new firmware data of the corresponding sector in the OTA upgrade package into the memory of the functional module. If the comparison result is consistent, no operation is performed, and the module directly proceeds to the verification of the next sector.

[0036] The above method significantly reduces the need for the domain controller and cameras to transmit large amounts of raw data back via a low-speed bus by offloading the firmware sector data verification task to the functional modules inside the cameras. This effectively alleviates communication congestion on the low-speed bus during concurrent OTA upgrades of multiple cameras, preventing communication timeouts and bus freezes. Simultaneously, the domain controller does not need to allocate large amounts of memory cache or perform massive data comparison calculations, thus significantly reducing the system's computing power and memory resource consumption and improving the overall efficiency and success rate of multi-camera OTA upgrades.

[0037] Please combine Figure 2 , Figure 2 The flowchart of a sub-step in step 120 of the camera firmware upgrade method of the present invention is shown.

[0038] In step 120, based on the verification mapping table, a hash calculation instruction for the sector to be verified is issued to the functional module to be upgraded. This includes the following sub-steps: Step 121: Based on the verification mapping table.

[0039] Before issuing a hash calculation instruction, the system needs to refer to a verification mapping table to determine which sectors need to be verified and their logical or physical location information in the firmware. The verification mapping table records the expected hash value for each sector (e.g., 4096 bytes) in the firmware. This verification mapping table can be stored in the memory of the main control chip (such as a domain controller) and used as a lookup table. When a sector needs to be verified, the main control chip retrieves the relevant information for that sector from the verification mapping table and then constructs the hash calculation instruction.

[0040] Step 122: Issue a specific sector hash calculation instruction to the functional module, which includes the instruction code, the starting physical address of the sector, and the length of the sector data.

[0041] Specifically, the main control chip sends control commands to the functional modules to be upgraded, such as the microcontroller or Flash controller inside the camera, to instruct the functional modules to perform hash calculations on the specified storage area.

[0042] The "instruction code" is a specific code in the instruction set used to identify the type and function of the instruction. In this context, it explicitly instructs the functional module to perform a "hash calculation" operation. The instruction code can be a predefined 8-bit or 16-bit value; for example, 0xAA indicates "calculate hash," and 0xBB indicates "read data." The firmware inside the functional module parses this instruction code and calls the corresponding processing function. The "sector starting physical address" refers to the actual physical starting location of the sector to be verified in the functional module's internal memory (such as Flash memory). It ensures that the functional module can accurately locate the data block that needs to be hashed. The sector starting physical address can be a direct absolute address in Flash memory, such as 0x08000000, or it can be an offset relative to a base address, converted by the address mapping unit inside the functional module. "Sector data length" refers to the amount of data contained in the sector to be verified, usually in bytes. It defines the range of hash calculations, ensuring that the functional module only performs calculations on data of the specified length, avoiding out-of-bounds or omissions. The sector data length can be a fixed value, for example, 4096 bytes (the size of a typical Flash sector). The "specific sector hash calculation instruction" is a combination of the above instruction code, the sector's starting physical address, and the sector data length, forming a complete command packet that can be recognized and executed by the functional module. This instruction can be sent in the form of a data packet via a low-speed bus such as I2C or SPI, containing the instruction code, address, and length fields. Alternatively, it can be written into the functional module's control register via memory-mapped registers, and periodically read and executed by the functional module's hardware logic or firmware.

[0043] Please combine Figure 3 , Figure 3 The flowchart of a sub-step in step 130 of the camera firmware upgrade method of the present invention is shown.

[0044] In step 130, the actual hash value of the sector to be verified, calculated and returned by the functional module, is obtained. This includes the following sub-steps: Step 131: The functional module identifies and parses the hash calculation instruction.

[0045] This refers to the ability of a functional module to understand the intent and parameters of a hash calculation instruction received from an upgrade module. For example, a functional module may be configured with a specific communication interface and protocol stack. When it receives a data packet from the upgrade module, its internal firmware or hardware logic will parse it according to a preset instruction format to determine the hash calculation task to be performed.

[0046] Step 132: Read the original data of the sector to be verified, calculate and return the actual hash value of the sector.

[0047] After the functional module identifies and parses the instructions, it will execute the read of the raw data of the sector to be verified. The functional module can directly access the storage medium where the sector to be verified is located through its internal memory controller or flash memory interface. For example, the functional module can use the direct memory access (DMA) mechanism to read the raw data with a specified starting physical address and data length of the sector from flash memory into its internal cache or RAM.

[0048] Specifically, after obtaining the raw data of the sector to be verified, the functional module performs a hash operation based on this data. For example, the functional module can utilize its integrated hardware hash accelerator to quickly generate a fixed-length hash value by taking the read raw data as input. Alternatively, the functional module's processor can run a pre-defined software hash algorithm to calculate the actual hash value from the raw data. After the calculation is complete, the functional module returns the actual hash value to the upgrade module through a pre-defined communication mechanism.

[0049] Please combine Figure 4 , Figure 4 A flowchart illustrating a sub-step in step 132 of the camera firmware upgrade method of the present invention is shown.

[0050] In step 132, the original data of the sector to be verified is read, and the actual hash value of the sector is calculated and returned. This also includes the following sub-steps: Step 1321: The functional module performs a local hash operation based on the original data of the sector to be verified and obtains a 4-byte checksum.

[0051] The core computational task of data verification is offloaded to the local execution of the functional module to generate a compact fingerprint that represents the integrity of the original data. For example, the functional module can use the CRC32 algorithm to perform a hash operation on the original data. The CRC32 algorithm can efficiently verify data blocks and generate a 32-bit checksum, which is 4 bytes.

[0052] Step 1322: Write the checksum into the preset register and set the status flag indicating that the calculation is complete.

[0053] This step provides a standardized interface for external modules to read the checksum and explicitly indicates whether the hash calculation has been completed. The preset registers can be configured as specific memory-mapped registers within the functional module, and the upgrade module can access these registers via low-speed bus protocols such as I2C and SPI.

[0054] Step 1323: When a status flag indicating that the calculation is complete is detected, the checksum is read.

[0055] This ensures that the upgrade module only reads data after the functional module has completed the hash calculation and prepared the data, thereby guaranteeing data consistency and validity.

[0056] Specifically, by offloading the hash calculation task to the local execution of the functional module, the original data of the sector to be verified is avoided from being sent back to the domain controller for comparison. This significantly reduces the data transmission volume of low-speed buses (such as I2C / SPI), thereby effectively alleviating bus congestion and improving the efficiency and success rate of concurrent OTA upgrades for multiple cameras. Compared to existing camera firmware upgrade solutions, which require sending back all 4096 bytes of a single sector of the camera Flash via a low-speed I2C / SPI bus, causing multiple cameras to simultaneously send back large amounts of data, which can easily lead to bus congestion, communication timeouts, or even bus freezes, this invention only requires sending back 4 bytes of verification code, greatly reducing the amount of communication data and thus preventing bus congestion.

[0057] In some embodiments, when a status flag is detected, the checksum is read, which further includes the following sub-steps: Read the status flags according to the preset polling cycle.

[0058] By setting a preset polling cycle, the upgrade module is prevented from continuously occupying bus resources for high-frequency queries, while also providing sufficient computing time for functional modules.

[0059] If a status flag indicating completion of the calculation is detected, the checksum is read.

[0060] Specifically, the upgrade module only reads data when the functional module explicitly indicates that the hash calculation task has been successfully completed and the result is ready. This status flag is usually a register bit or the value of a specific memory address within the functional module. When the hash calculation is completed, the functional module sets this flag. Once the upgrade module detects that the status flag is set, it immediately performs a read operation to retrieve the calculated 4-byte checksum from the register or memory area preset by the functional module.

[0061] If no completion status flag is detected, wait for the next query cycle and query again.

[0062] Specifically, if the upgrade module does not detect a completion status flag within the current polling cycle, it will not retry immediately. Instead, it will wait for a period of time according to a preset polling cycle before querying the status flag again. This avoids invalid retries and bus congestion caused by functional modules not yet completing their calculations, thus improving the system's fault tolerance.

[0063] In this embodiment, asynchronous collaboration between the upgrade module and the functional modules in hash calculation tasks is implemented, ensuring the accuracy of data reading. Simultaneously, it avoids continuous occupation of bus resources, optimizing system performance. Especially in scenarios with concurrent upgrades of multiple cameras, it effectively alleviates bus congestion and communication timeout issues, thereby improving the efficiency and success rate of multi-camera OTA upgrades.

[0064] In some embodiments, if no completion status flag is detected, the query will be performed again after the next query cycle, and the following further steps will be taken: If the polling time exceeds the preset timeout threshold and the calculation completion status flag is still not detected.

[0065] One approach is to set a time limit for the hash calculation process to prevent functional modules from remaining in the calculation state indefinitely due to abnormal situations, thereby halting the entire upgrade process.

[0066] In practice, after sending the hash calculation instruction to the functional module, a timer can be started. Each time the calculation completion status flag is checked, the system will check the time that has elapsed since the instruction was sent.

[0067] Then skip that sector and report the fault information to the outside world.

[0068] When the polling time exceeds a preset timeout threshold, the system will stop waiting for the hash calculation result of the current sector and instead adopt a "skip the sector" strategy. Simultaneously, the system will "report fault information" by sending specific error codes, faulty sector identifiers, and fault types to the domain controller or other upper-level monitoring systems via a low-speed bus (such as I2C / SPI).

[0069] In this embodiment, the problem of infinite waiting that may occur during hash calculation by functional modules is resolved. When a functional module fails to complete the hash calculation in a timely manner due to a fault or other reasons, the system no longer gets stuck in endless polling, but can promptly identify and respond to such abnormal situations. This ensures that even if some sectors experience anomalies, the overall upgrade process can continue, avoiding prolonged occupation of system resources and a decline in user experience.

[0070] In some embodiments, the sector to be verified is configured as a sector storing raw data from the camera.

[0071] The sector to be verified refers to the smallest addressable storage unit in the camera's internal memory that requires data integrity or consistency checks.

[0072] Specifically, in firmware upgrade scenarios, the data content of these sectors is compared with the expected hash value to determine whether an update is needed. By explicitly configuring the sectors to be verified as those storing the camera's raw data, the hash verification instructions during the firmware upgrade process can accurately target the core firmware area. This effectively avoids invalid readings and hash calculations of non-raw data areas in the camera's memory, thereby significantly reducing the amount of data transmitted on the low-speed bus and lowering the risk of bus congestion.

[0073] In some embodiments, after comparing the expected hash value and the actual hash value, and if the results are inconsistent, an upgrade operation is performed on the sector, the method further includes: After performing the sector upgrade operation.

[0074] After completing the data writing operation to the target sector, the upgrade module's internal state machine automatically transitions to the stage of waiting for verification.

[0075] Issue the hash calculation command again and obtain the actual hash value of the sector.

[0076] The upgrade module reuses the hash calculation instruction format used during the initial verification. This instruction contains information such as the starting physical address of the sector and the length of the sector data. After receiving the instruction, the functional module performs hash calculation on the data within the address range and returns the result.

[0077] A second comparison is made between the expected hash value and the actual hash value.

[0078] The verification logic unit inside the upgrade module receives the actual hash value obtained a second time and compares it byte by byte or bit by bit with the expected hash value of the sector stored in memory to determine whether the two are completely identical.

[0079] If the results are consistent, the final verification is completed and the process moves to the next sector.

[0080] In this process, after confirming that the second comparison is consistent, the upgrade module updates the upgrade status of the sector to "completed and verified" and selects the next sector to be processed from the verification mapping table, repeating the above verification and upgrade process.

[0081] Specifically, by issuing a hash calculation command again, the functional module is forced to recalculate the newly updated sector data to obtain its latest actual hash value; subsequently, this actual hash value is compared with the expected hash value a second time. This closed-loop verification effectively detects potential write errors, data corruption, or transmission anomalies that may occur during the upgrade process, ensuring that the upgraded firmware data is completely consistent with the expected target.

[0082] In some embodiments, after comparing the expected hash value and the actual hash value, and if the results are inconsistent, an upgrade operation is performed on the sector, the method further includes: Compare the expected hash value with the actual hash value; If the results are the same, skip that sector.

[0083] Specifically, this can be achieved by comparing the expected hash value extracted from the verification mapping table with the actual hash value obtained from the functional module bit by bit or byte by byte. For example, an XOR operation can be used to determine whether the two hash values ​​are exactly the same; if the XOR result is zero, it means that the two are consistent. If the comparison result is consistent, it means that the data of the current sector to be verified meets expectations, and any unnecessary subsequent operations on that sector should be avoided.

[0084] Example 2: like Figure 5 As shown, Figure 5 A schematic diagram of an embodiment of the camera firmware upgrade system of the present invention is shown. A camera firmware upgrade system includes: at least one functional chip module 10 and an upgrade module 20.

[0085] The functional chip module 10 is used to perform preset functions; the upgrade module 20 is used to perform the steps of the above-described camera firmware upgrade method to upgrade at least one functional chip module 10.

[0086] In some implementations, the functional chip module 10 is configured to directly calculate the actual hash value of the sector to be verified in the internal storage space of the camera, while the upgrade module 20 is responsible for obtaining the verification mapping table embedded in the OTA upgrade package, issuing a hash calculation instruction to the functional chip module 10, receiving the actual hash value and comparing it with the expected hash value in the verification mapping table; when the comparison result is inconsistent, the upgrade module 20 only performs firmware data writing operation for the sector with the difference.

[0087] Upgrade module 20 is specifically used to perform the following method steps: Obtain the OTA upgrade package and extract the verification mapping table containing the expected hash value for each sector. Based on the verification mapping table, a hash calculation instruction for the sector to be verified is sent to the functional module to be upgraded. Obtain the actual hash value of the sector to be verified, calculated and returned by the functional module; Compare the expected hash value with the actual hash value. If the results are inconsistent, perform an upgrade operation on the sector.

[0088] In some embodiments, at least one functional chip module 10 includes a calculation module for calculating the actual hash value of the sector to be verified.

[0089] Specifically, the functional chip module 10 is the core processing unit of the camera system, responsible for executing various preset functions of the camera, such as image acquisition, processing, and encoding. In firmware upgrade scenarios, it serves as the carrier for the firmware to be upgraded; the functional chip module 10 can be specifically represented as a microcontroller (MCU), digital signal processor (DSP), field-programmable gate array (FPGA), or application-specific integrated circuit (ASIC), etc.

[0090] The computing module is a dedicated hardware or software logic unit integrated within the functional chip module 10. Its main function is to perform hash operations. This computing module can be a hash accelerator, such as a hardware module integrated within a microcontroller or digital signal processor, specifically designed to efficiently execute hash algorithms such as SHA-256 and CRC32 to significantly improve computing speed and reduce the burden on the main processor.

[0091] In some embodiments, the upgrade module 20 includes a communication module 21, a parsing module 22, and an execution module 23.

[0092] The communication module 21 is used to acquire OTA upgrade packages, issue hash calculation commands, and obtain the actual hash value of the sector to be verified. The parsing module 22 is used to parse the OTA upgrade package and extract a verification mapping table that records the expected hash value corresponding to each sector. The execution module 23 is used to compare the expected hash value and the actual hash value; if the results are inconsistent, an upgrade operation is performed on the sector.

[0093] It should be noted that the upgrade module 20 can be dedicated to upgrading the functional chip module 10, or it can also be used for upgrading the functional chip module 10. For example, the upgrade module 20 can be the main control chip of the driving domain controller, which, when not performing the camera firmware upgrade operation of this application, is also used to implement intelligent assisted driving functions.

[0094] The above system significantly reduces the need for the domain controller and cameras to transmit large amounts of raw data back via a low-speed bus by offloading the firmware sector data verification task to the functional modules inside the cameras. This effectively alleviates communication congestion on the low-speed bus during concurrent OTA upgrades of multiple cameras, preventing communication timeouts and bus freezes. Simultaneously, the domain controller does not need to allocate large amounts of memory cache or perform massive data comparison calculations, thus significantly reducing the system's computing power and memory resource consumption and improving the overall efficiency and success rate of multi-camera OTA upgrades.

[0095] Example 3: Figure 6 The diagram shows a structural schematic of an embodiment of the camera firmware upgrade device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the camera firmware upgrade device.

[0096] like Figure 6 As shown, an OTA upgrade device may include: a processor 601, a communication interface 602, a memory 603, and a communication bus 604.

[0097] The processor 601, communication interface 602, and memory 603 communicate with each other via communication bus 604. Communication interface 602 is used to communicate with other network elements, such as a firmware upgrade server or other servers. The processor 601 executes program 610, which, during execution, performs upgrade operations on each sector as described in the camera firmware upgrade method.

[0098] Specifically, program 610 may include program code, which includes computer-executable instructions.

[0099] Specifically, processor 601 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The camera firmware upgrade device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0100] Memory 603 is used to store program 610. Memory 603 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0101] Specifically, program 610 can be called by processor 601 to cause the camera firmware upgrade device to perform the following operations: Obtain the OTA upgrade package and extract the verification mapping table containing the expected hash value for each sector. Based on the verification mapping table, a hash calculation instruction for the sector to be verified is sent to the functional module to be upgraded. Obtain the actual hash value of the sector to be verified, calculated and returned by the functional module; Compare the expected hash value with the actual hash value. If the results are inconsistent, perform an upgrade operation on the sector.

[0102] In an alternative implementation, program 610 is invoked by processor 601 to cause the camera firmware upgrade device to perform specific sub-steps of steps 120 and 130 in embodiment 1.

[0103] Specifically, by transforming the firmware verification logic from the traditional full data back-transmission comparison mode to a distributed processing mode based on hash verification, the computational pressure of data comparison is shifted from the domain controller to the local execution of the functional modules inside the camera. Only a very small amount of hash values ​​need to be exchanged on the bus, which effectively avoids the congestion risk when transmitting massive amounts of firmware data on a low-speed bus and significantly reduces the system's computing power and memory resource consumption.

[0104] The above devices significantly reduce the need for the domain controller and cameras to transmit large amounts of raw data back via a low-speed bus by offloading the firmware sector data verification task to the functional modules inside the cameras. This effectively alleviates communication congestion on the low-speed bus during concurrent OTA upgrades of multiple cameras, preventing communication timeouts and bus freezes. Simultaneously, the domain controller does not need to allocate large amounts of memory cache or perform massive data comparison calculations, thus significantly reducing the system's computing power and memory resource consumption and improving the overall efficiency and success rate of multi-camera OTA upgrades.

[0105] Example 4: This invention provides a computer-readable storage medium storing at least one executable instruction. When the executable instruction is executed on a camera firmware upgrade device, the camera firmware upgrade device performs the camera firmware upgrade method in any of the above method embodiments.

[0106] Specifically, the executable instructions can be used to cause the camera firmware upgrade device to perform the following operations: Obtain the OTA upgrade package and extract the verification mapping table containing the expected hash value for each sector. Based on the verification mapping table, a hash calculation instruction for the sector to be verified is sent to the functional module to be upgraded. Obtain the actual hash value of the sector to be verified, calculated and returned by the functional module; Compare the expected hash value with the actual hash value. If the results are inconsistent, perform an upgrade operation on the sector.

[0107] By offloading the firmware sector data verification task to the local functional module inside the camera, the need for transmitting large amounts of raw data between the domain controller and the camera via a low-speed bus is significantly reduced. This effectively alleviates communication congestion on the low-speed bus during concurrent OTA upgrades of multiple cameras, preventing communication timeouts and bus freezes. Simultaneously, the domain controller does not need to allocate large amounts of memory cache or perform massive data comparison calculations, thus significantly reducing the consumption of system computing power and memory resources, and improving the overall efficiency and success rate of multi-camera OTA upgrades.

[0108] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0109] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0110] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0111] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for upgrading camera firmware, characterized in that, include: Obtain the OTA upgrade package and extract the verification mapping table containing the expected hash value for each sector. Based on the verification mapping table, a hash calculation instruction for the sector to be verified is sent to the functional module to be upgraded in firmware. Obtain the actual hash value of the sector to be verified, calculated and returned by the aforementioned functional module; If the expected hash value and the actual hash value are compared, and the results are inconsistent, an upgrade operation is performed on the sector.

2. The camera firmware upgrade method according to claim 1, characterized in that, The step of issuing a hash calculation instruction for the sector to be verified to the functional module to be upgraded based on the verification mapping table includes the following sub-steps: Based on the aforementioned verification mapping table; A specific sector hash calculation instruction containing the instruction code, the starting physical address of the sector, and the length of the sector data is issued to the functional module.

3. The camera firmware upgrade method according to claim 1, characterized in that, Obtaining the actual hash value of the sector to be verified, calculated and returned by the functional module, includes the following sub-steps: The functional module identifies and parses the hash calculation instruction; Read the raw data of the sector to be verified, calculate and return the actual hash value of the sector.

4. The camera firmware upgrade method according to claim 3, characterized in that, The step of reading the original data of the sector to be verified, calculating and returning the actual hash value of the sector, also includes the following sub-steps: The functional module performs a local hash operation based on the original data of the sector to be verified and obtains a 4-byte checksum. Write the check code into a preset register and set the status flag indicating that the calculation is complete. The check code is read when a status flag indicating that the calculation is complete is detected.

5. The camera firmware upgrade method according to claim 4, characterized in that, The step of reading the verification code when the status flag is detected also includes the following sub-steps: The status flag is read according to a preset polling cycle; If a status flag indicating completion of the calculation is detected, then the checksum is read; If no completion status flag is detected, wait for the next query cycle and query again.

6. The camera firmware upgrade method according to claim 5, characterized in that, If no completion status flag is detected, the process of waiting for the next query cycle and then querying again also includes: If the polling time exceeds the preset timeout threshold and the calculation completion status flag is still not detected; Then skip that sector and report the fault information to the outside world.

7. The camera firmware upgrade method according to claim 1, characterized in that, The sector to be verified is configured as a sector storing the camera's raw data.

8. The camera firmware upgrade method according to claim 1, characterized in that, The process of comparing the expected hash value and the actual hash value, and upgrading the sector if the results are inconsistent, further includes: After performing the upgrade operation on the sector; The hash calculation instruction is issued again to obtain the actual hash value of the sector; A second comparison is performed between the expected hash value and the actual hash value; If the results are consistent, the final verification is completed and the process moves to the next sector.

9. The camera firmware upgrade method according to claim 1, characterized in that, The process of comparing the expected hash value and the actual hash value, and upgrading the sector if the results are inconsistent, further includes: Compare the expected hash value with the actual hash value; If the results are the same, skip that sector.

10. A camera firmware upgrade system, characterized in that, include: At least one functional chip module for performing a preset function; and An upgrade module is configured to perform the steps of the camera firmware upgrade method according to any one of claims 1 to 9, in order to perform an upgrade operation on at least one of the functional chip modules.

11. The camera firmware upgrade system according to claim 10, characterized in that, At least one of the functional chip modules includes a computing module for calculating the actual hash value of the sector to be verified.

12. The camera firmware upgrade system according to claim 10, characterized in that, The upgrade module includes: The communication module is used to obtain OTA upgrade packages; to issue hash calculation commands; and to obtain the actual hash value of the sector to be verified. The parsing module is used to parse OTA upgrade packages and extract a verification mapping table containing the expected hash values ​​for each sector; and The execution module is used to compare the expected hash value with the actual hash value, and if the results are inconsistent, it performs an upgrade operation on the sector.

13. A camera firmware upgrade device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the camera firmware upgrade method as described in any one of claims 1 to 9 to upgrade each sector when executed.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the device containing the computer-readable storage medium executes the computer program, it implements the camera firmware upgrade method as described in any one of claims 1 to 9.

Images