A multi-partition software upgrading method and device for a dual-core dual-system chip

Abstract

The application relates to a multi-partition software upgrading method and device of a dual-core dual-system chip, which comprises the following steps: S1, a preparation stage: S1-1, firmware splitting and instruction file generation; S1-2, upgrading execution program loading; S2, an execution stage: S2-1, instruction analysis and delivery; S2-2, bus communication and partition operation; S2-3, result feedback; and S3, a completion stage. The application provides a multi-partition software upgrading method of a dual-core dual-system chip, which can independently update or restore specific partitions by splitting firmware logic into multiple independent partitions and performing partition operation based on instruction files, can significantly reduce memory resource occupation, can improve the flexibility of upgrading operation and system reliability, and can enhance the overall robustness.

Description

Technical Field

[0001] This invention relates to the field of embedded system software upgrade technology, and in particular to a multi-partition software upgrade method and apparatus for a dual-core, dual-system chip. Background Technology

[0002] In a dual-core, dual-system-on-a-chip (SoC), the main processing unit (MPU) and the auxiliary processing unit (APU) typically have independent processing cores and storage resources, and communicate via a system bus. The APU is often used to perform peripheral control, real-time processing, or low-power related tasks, and its software stability and maintainability have a significant impact on the overall system operation.

[0003] In existing technologies, software upgrades for auxiliary function processors typically involve a complete firmware replacement. This means the main processor acquires the complete firmware data of the auxiliary processor, writes the firmware to the auxiliary processor's storage via a bus, and then reboots. This type of upgrade is usually performed on a per-complete firmware image basis.

[0004] The above upgrade method has at least the following problems: 1. During the upgrade process, the main processor needs to temporarily store the complete firmware data, which consumes a large amount of storage resources; 2. Upgrade operations are usually performed on the entire firmware as a unit, making it difficult to perform upgrade or erase operations separately on different storage partitions such as the operating system code area, application area, configuration area, or running data area; 3. When the accessibility processor malfunctions or the data area is damaged, targeted recovery cannot be performed without affecting other partitions; 4. The upgrade process lacks flexibility, which is not conducive to achieving on-demand upgrades or rapid recovery.

[0005] Therefore, existing technologies are insufficient to meet the upgrade requirements of auxiliary function processors for low storage footprint, independent partition upgrades, and abnormal partition recovery. Summary of the Invention

[0006] The purpose of this invention is to provide a multi-partition software upgrade method and apparatus for dual-core, dual-system chips. By introducing an upgrade execution mechanism driven by partition operation instructions, it enables independent upgrades and write / recovery of different storage partitions of the auxiliary function processor, thereby: Reduce temporary storage consumption of the main processing unit during the upgrade process; Improve the flexibility of the accessibility processor upgrade process; Supports recovery of specified partitions in the event of an accessibility processor malfunction; Improve the maintainability and reliability of the overall system.

[0007] Therefore, this invention provides a multi-partition software upgrade method for dual-core, dual-system chips, comprising the following steps: S1. Preparation Phase: S1-1 Firmware Splitting and Instruction File Generation: The overall firmware of the auxiliary function processor is logically split into multiple independent storage partitions, and independent firmware data is prepared for each partition. The main processing processor generates an upgrade operation instruction file according to the specific requirements of this upgrade or recovery. S1-2, Upgrade Execution Program Loading: Before the actual upgrade process begins, the main computing processor loads the upgrade execution program used to perform partition-level upgrade operations into the running memory of the auxiliary function processor; S2, Execution Phase: S2-1, Instruction Parsing and Issuance: The main processing unit begins to parse the pre-generated upgrade operation instruction file line by line; S2-2, Bus Communication and Partition Operation: The main processing processor sends the parsed partition operation instructions to the auxiliary function processor in the upgrade execution state through the system bus. After receiving these instructions and data, the upgrade execution program on the auxiliary function processor side parses them. S2-3, Result Feedback: After completing each partitioning operation, the auxiliary function processor feeds back the execution result of the operation to the main processing processor through the system bus; S3. Completion Phase: Once the main processing processor confirms that all upgrade operation instructions have been successfully executed and all partitions have been updated or restored as required, it will send a control instruction to the auxiliary function processor to exit the upgrade execution state.

[0008] This invention provides a multi-partition software upgrade method for dual-core dual-system chips. By logically splitting the firmware into multiple independent partitions and performing partition operations based on instruction files, it is possible to independently update or restore specific partitions, significantly reducing memory resource consumption, improving the flexibility of upgrade operations and system reliability, thereby enhancing overall robustness.

[0009] In one embodiment of the present invention, the upgrade operation instruction file is used to describe the partition-level operations that need to be performed during this upgrade process, driving the execution order and operation content of the entire upgrade process. It contains multiple upgrade operation instructions arranged in sequence, and the upgrade operation instructions include at least: partition identification information, partition start address, and maximum available storage space of the partition.

[0010] In one embodiment of the present invention, the upgrade execution program is used to cooperate with the main processing processor to complete the partition upgrade operation during the upgrade process, and it comprises: Receive partition operation instructions sent by the main processing processor via the system bus; According to the partition operation instructions, erase, write or verify operations are performed on the target storage partition of the auxiliary function processor; The partitioning operation execution result is fed back to the main processing processor; After the upgrade process is completed, the corresponding business program is started according to the control instructions of the main computing processor.

[0011] In one embodiment of the present invention, the overall firmware of the auxiliary function processor is logically divided into multiple independent storage partitions, including: an operating system code area, an application code area, a configuration parameter area, and a runtime data area.

[0012] The present invention also provides a multi-partition software upgrade device for a dual-core dual-system chip, which communicates through a system bus between the main computing processor and the auxiliary function processor to realize software upgrade and erase / write operations on different storage partitions of the auxiliary function processor, including: an upgrade control device disposed on the main computing processor side and an upgrade execution device disposed on the auxiliary function processor side.

[0013] In one embodiment of the present invention, the upgrade control device on the main processing processor side is used to generate and issue upgrade operation instructions for each storage partition of the auxiliary function processor; the upgrade execution device on the auxiliary function processor side is used to receive and parse the upgrade operation instructions, and perform corresponding storage operations on the target partition according to the instructions.

[0014] In one embodiment of the present invention, the upgrade control device on the main processing processor side includes the following functional modules: Upgrade program loading module: It is used to load the upgrade execution program required for the upgrade stage into the running memory of the auxiliary function processor before the auxiliary function processor performs the software upgrade, and control the auxiliary function processor to enter the upgrade execution state; Partition upgrade instruction parsing module: It is used to obtain and parse the upgrade operation instruction file; Partition data management module: It is used to obtain firmware data of the corresponding partition or generate an erase request for the target partition according to the operation instructions parsed by the partition upgrade instruction parsing module. Upgrade instruction sending module: It is used to send partition operation instructions to the auxiliary function processor through the system bus. When the operation instruction is a write operation, it is also used to synchronously send firmware data of the corresponding partition.

[0015] In one embodiment of the present invention, the upgrade execution device on the auxiliary function processor side includes the following functional modules: Upgrade instruction receiving module: It is used to receive partition operation instructions and partition firmware data corresponding to the partition operation instructions sent by the main computing processor through the system bus; Partition instruction parsing module: It is used to parse the received partition operation instructions and obtain the target partition's identification information, partition start address, partition capacity, and corresponding operation type; Partition storage operation module: It is used to perform corresponding storage operations on the target storage partition specified by the instruction in the auxiliary function processor according to the parsed operation type. When the operation type is a write operation, the partition storage operation module writes the received partition firmware data to the target partition. When the operation type is an erase operation, the partition storage operation module performs an erase operation on the target partition. Upgrade completion control module: It is used to control the auxiliary function processor to exit the upgrade execution state and start the upgraded software system after all partition operation instructions have been executed.

[0016] In one embodiment of the present invention, the firmware data of the partition is an independent data file obtained by splitting the firmware storage structure of the auxiliary function processor, and the firmware data corresponding to different partitions are stored independently of each other.

[0017] The multi-partition software upgrade method and apparatus for dual-core dual-system chips of the present invention have the following advantages compared with the prior art: 1. Enables independent upgrades and write / recovery of multiple storage partitions in the auxiliary function processor; 2. The main processing unit does not need to temporarily store complete firmware data, effectively reducing storage resource consumption; 3. Supports targeted recovery of specified partitions such as configuration area or data area in case of abnormal situations; 4. The upgrade process is driven by operation commands, making the upgrade process clear, controllable, and easy to expand and maintain; 5. Improve the software upgrade flexibility and system reliability of dual-core dual-system chips. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart of the multi-partition software upgrade method for a dual-core, dual-system chip according to the present invention; Figure 2 This is a block diagram of the multi-partition software upgrade device for a dual-core, dual-system chip according to the present invention. Detailed Implementation

[0020] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0021] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] It should be noted that the following description covers various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0023] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0024] Additionally, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that practice can be carried out without these specific details.

[0025] In dual-core, dual-system chips, software upgrades for the auxiliary function processor (ADC) typically involve a complete firmware replacement. This type of upgrade processes the entire firmware image, requiring the main processor to temporarily store the complete firmware data during the upgrade process, resulting in significant storage resource consumption. Furthermore, it's difficult to perform separate upgrades or write / erase operations on different storage partitions, such as the operating system code area, application area, configuration area, or runtime data area. When the ADC malfunctions or its data area is corrupted, targeted recovery without affecting other partitions is also impossible. The upgrade process lacks flexibility and fails to meet the requirements for low storage consumption, independent partition upgrades, and recovery from abnormal partitions.

[0026] To address this issue, this application proposes a multi-partition software upgrade method for a dual-core, dual-system chip. During the preparation phase, the overall firmware of the auxiliary function processor (ADC) is logically divided into multiple independent storage partitions, with independent firmware data prepared for each partition. Simultaneously, the main processing unit (MSU) generates an upgrade operation instruction file and loads the upgrade execution program before the upgrade is executed. During the execution phase, the MSU parses the instructions line by line and sends them to the ADC via the system bus. The ADC performs the partitioning operations and provides feedback on the results. Finally, in the completion phase, the MSU confirms the operation and controls the ADC to exit the upgrade state. Thus, this application achieves low storage footprint for the ADC software, independent partition upgrades, and recovery from abnormal partitions.

[0027] The multi-partition software upgrade method for dual-core dual-system chips in this application includes: a preparation phase, an execution phase, and a completion phase, as described above. Figure 1 As shown, the specific steps include the following: S1. Preparation Phase: S1-1 Firmware Splitting and Command File Generation: The auxiliary function processor's overall firmware is logically split into multiple independent storage partitions, with independent firmware data prepared for each partition. The main processing processor generates an upgrade operation command file based on the specific requirements of this upgrade or recovery. Specifically, one implementation method is that during the firmware development phase, developers manually split the overall firmware according to a preset storage structure and manually extract or generate corresponding firmware data files for each logical partition. These data files can be stored independently in the main processing processor's storage medium. For example, the main processing processor can dynamically generate an upgrade operation command file based on user selections in the graphical interface or preset configuration files. This file can simply contain a series of partition identifiers and corresponding operation types.

[0028] S1-2, Upgrade Execution Program Loading: Before the actual upgrade process begins, the main computing processor loads the upgrade execution program used to perform the partition-level upgrade operation into the running memory of the auxiliary function processor; one implementation is that, before starting the auxiliary function processor, the main computing processor transfers the upgrade execution program from the main computing processor's storage space to the auxiliary function processor's running memory through a specific boot loading mechanism.

[0029] S2, Execution Phase: S2-1, Instruction Parsing and Issuance: The main processing unit begins to parse the pre-generated upgrade operation instruction file line by line; S2-2, Bus Communication and Partition Operation: The main processing processor sends the parsed partition operation instructions to the auxiliary function processor in the upgrade execution state through the system bus. After receiving these instructions and data, the upgrade execution program on the auxiliary function processor side parses them. S2-3, Result Feedback: After completing each partitioning operation, the auxiliary function processor feeds back the execution result of the operation to the main processing processor through the system bus; S3. Completion Phase: Once the main processing processor confirms that all upgrade operation instructions have been successfully executed and all partitions have been updated or restored as required, it sends a control command to the auxiliary function processor to exit the upgrade execution state. Specifically, when the main processing processor confirms through received feedback that all upgrade operation instructions have been successfully executed and all target partitions have reached the expected update or restoration state, it sends a specific control command to the auxiliary function processor. Upon receiving this control command, the auxiliary function processor terminates its upgrade execution program and exits the upgrade execution state. Subsequently, the auxiliary function processor can start its updated software system according to preset logic to restore normal business functions.

[0030] During the execution phase, the main processing unit begins parsing the pre-generated upgrade operation instruction file line by line. The main processing unit can read sequentially, starting from the beginning of the instruction file and parsing each instruction. After each instruction is parsed, information such as the partition identifier and operation type is extracted. Subsequently, the main processing unit sends the parsed partition operation instructions to the auxiliary function processor (AFM) in the upgrade execution state via the system bus. The upgrade execution program on the AFM side receives these instructions and data and parses them. When an instruction is issued, the main processing unit encapsulates the parsed partition operation instructions into a specific communication protocol data packet via the system bus and sends it to the AFM. The upgrade execution program on the AFM side continuously monitors the system bus; once it receives the partition operation instruction data packet from the main processing unit, it unpacks and parses it. The parsing process identifies the target storage partition, the required operation, and any accompanying firmware data. Based on the parsed instructions, the upgrade execution program calls the storage controller interface inside the AFM to perform the corresponding operation on the specified target storage partition. For example, for a write operation, the program writes the received firmware data to the specified address of the target partition; for an erase operation, the program sends an erase command to the storage controller.

[0031] After each partitioning operation is completed, the auxiliary function processor (AFC) feeds back the execution result to the main processing unit (MTU) via the system bus. Specifically, the upgrade execution program on the AFC side generates an operation result report, which includes information such as whether the operation was successful, error codes (if any), and the partition identifier of the completed operation. This result report is then sent back to the MTU via the system bus. Upon receiving the feedback, the MTU updates its internal upgrade status record and determines the next step.

[0032] This application logically divides the overall firmware of the auxiliary function processor into multiple independent storage partitions, allowing the main processing processor to generate partition-level upgrade operation instruction files as needed. This avoids the problem of the main processor needing to temporarily store the complete firmware data in traditional overall firmware upgrade methods, significantly reducing storage resource consumption. Furthermore, through partition-level instruction parsing, bus communication, and operation, independent upgrades or erasures of different storage partitions, such as the operating system code area, application area, configuration parameter area, and runtime data area, are achieved, improving upgrade flexibility. When the auxiliary function processor malfunctions or its data area is damaged, targeted recovery can be performed without affecting other normal partitions, thereby improving system maintainability and recovery efficiency.

[0033] Based on the above, this application further proposes that the upgrade operation instruction file is used to describe the partition-level operations that need to be performed during this upgrade process, driving the execution order and operation content of the entire upgrade process. It contains multiple upgrade operation instructions arranged in sequence, and the upgrade operation instructions include at least: partition identification information, partition start address, and maximum available storage space of the partition.

[0034] This upgrade instruction file is a structured collection of data whose core function is to plan and guide the software upgrade or recovery process on the auxiliary function processor in detail. It not only defines the specific operations to be performed (such as erase, write, and verify), but also specifies the target partitions, the order of execution, and the specific content of these operations. For example, this file can be encoded in text formats such as XML or JSON, where each node or object represents a partition operation instruction and contains corresponding attribute fields, such as operation type and target partition.

[0035] The instructions in the upgrade instruction file are not randomly stacked, but arranged in a predetermined logical order. This ordering is crucial to ensuring the correctness and stability of the upgrade process. For example, these instructions can be stored in an ordered list or array structure, and the main processor will read and execute them strictly according to their position in the file during parsing.

[0036] Partition identification information is a unique identifier used to identify a specific memory partition within the auxiliary function processor. Its purpose is to ensure that each upgrade operation instruction accurately targets the intended partition, preventing erroneous operations on non-target partitions. For example, partition identification information can be a predefined integer value (e.g., 0x01 for the operating system code area, 0x02 for the application code area), a descriptive string (e.g., "OS_CODE", "APP_DATA"), or even a composite code combining the chip model and partition function. Through this identifier, the main processing processor can clearly inform the auxiliary function processor on which logical partition to perform subsequent operations.

[0037] The partition start address refers to the physical or logical starting location of the target storage partition in the secondary function processor's memory space. This address provides precise spatial positioning for operations, allowing operations such as erasing, writing, or verification to begin execution from the exact starting point of the partition. For example, it can be an absolute physical memory address (such as 0x08000000).

[0038] The maximum available storage space for a partition refers to the total amount of data that the target storage partition can hold, or the size of its physical boundaries. This information is used to limit the scope of operations, preventing data from overflowing into adjacent partitions and thus protecting the data integrity of other partitions. For example, it can be a value in bytes representing the total capacity of the partition; or a count in blocks, where each block has a fixed size; or it can be measured in pages. By specifying the maximum storage space, the main processing unit and auxiliary processing units can work together to ensure that all operations are performed within the predetermined partition boundaries, effectively managing storage resources.

[0039] Through the above technical solution, this application defines the upgrade operation instruction file in detail, enabling it to describe the partition-level operations to be performed during the upgrade process and drive the execution order and operation content of the entire upgrade process. Specifically, the file contains multiple upgrade operation instructions arranged in sequence, and each instruction includes at least partition identification information, partition start address, and the maximum available storage space of the partition. This design allows the main processing processor to perform highly precise and detailed control over the storage partitions of the auxiliary function processor when generating upgrade instructions.

[0040] In light of this, the main processing unit can accurately identify the target partition based on the partition identifier information, precisely locate the start point of the operation using the partition's starting address, and limit the operation range by the maximum available storage space of the partition, thereby avoiding erroneous operations or data overflows on non-target partitions. Simultaneously, the sequential arrangement of instructions ensures the determinism and predictability of the upgrade process, effectively preventing data corruption or system instability caused by disordered operation sequences. Due to these explicit details, this application enables independent and precise upgrades and recovery of auxiliary function processor storage partitions. For example, when an application partition encounters a problem, only that partition can be erased or rewritten without affecting the operating system or other data partitions. This greatly improves the flexibility, reliability, and efficiency of the upgrade process and significantly reduces the storage resource consumption of the main processing unit during the upgrade process, meeting the requirements of low storage consumption, independent partition upgrades, and recovery of abnormal partitions.

[0041] Based on the above, this application further proposes that the upgrade execution program is used to cooperate with the main computing processor to complete the partition upgrade operation during the upgrade process, and it has the following features: Receive partition operation instructions sent by the main processing processor via the system bus; According to the partition operation instructions, erase, write or verify operations are performed on the target storage partition of the auxiliary function processor; The partitioning operation execution result is fed back to the main processing processor; After the upgrade process is completed, the corresponding business program is started according to the control instructions of the main computing processor.

[0042] Specifically, the upgrade executor has the capability to receive partition operation instructions sent by the main processing processor via the system bus. This capability means that the upgrade executor can acquire commands generated and sent by the main processing processor to operate on a specific memory partition in the auxiliary function processor. The system bus is the communication channel for data and instruction transmission between the main processing processor and the auxiliary function processor. In one implementation, the upgrade executor may include a dedicated communication interface module that continuously monitors a specific address or message type on the system bus. Once a partition operation instruction from the main processing processor is detected, it is captured and passed to other parts of the program for processing.

[0043] Based on this, the upgrade executor can perform erase, write, or verification operations on the target storage partition of the auxiliary function processor according to the partition operation instructions. This capability is the core function of the upgrade executor, namely, performing specific storage operations on a specified logical storage area within the auxiliary function processor according to the received instructions. These operations include erasure (clearing the partition contents), writing (storing new data into the partition), and verification (verifying the integrity or correctness of the partition data). In one implementation, the upgrade executor can integrate a storage controller interface that can directly access the flash memory, EEPROM, or other non-volatile memory of the auxiliary function processor. When an erase instruction is received, the interface calls the corresponding memory driver function to perform sector or block erasure; when a write instruction is received, the firmware data transmitted with the instruction is written to the specified address; when a verification instruction is received, the target partition data is read and a checksum (such as CRC, MD5, etc.) is calculated and compared with the expected value.

[0044] Simultaneously, the upgrade executor can also provide feedback on the partition operation execution results to the main processing unit. This capability ensures that the main processing unit can understand the execution status and results of various partition operations on the auxiliary function processors in real time. Feedback information typically includes whether the operation was successful, the reason for failure (such as a checksum error, write failure, etc.), and possible related data. In one implementation, the upgrade executor can send specific status messages or event notifications to the main processing unit via the system bus. For example, a set of status codes can be defined: a "operation completed" status code is sent when the operation is successful, and error codes such as "write failure" or "checksum mismatch" are sent when the operation fails, possibly along with the address or data information at the time of the error.

[0045] Furthermore, after the upgrade process is complete, the upgrade executor can launch the corresponding business application according to the control instructions of the main computing processor. This capability describes the final behavior of the upgrade executor after completing all upgrade tasks, namely, launching the updated or specified business application on the auxiliary function processor according to the instructions of the main computing processor, restoring it to normal working state. This ensures a smooth transition in the upgrade process and normal system operation. In one implementation, after confirming the success of all upgrade operations, the main computing processor sends a "start business application" control instruction. Upon receiving this instruction, the upgrade executor locates and loads the entry point address of a specific storage partition (such as the application code area) in the auxiliary function processor, and then jumps to that address to begin executing the business application.

[0046] Through the above technical solution, the upgrade execution program can efficiently and reliably cooperate with the main processing processor to complete the partition upgrade. Specifically, by receiving partition operation instructions sent by the main processing processor through the system bus, it ensures the accurate transmission and timely acquisition of instructions, providing a solid foundation for subsequent operations and effectively avoiding upgrade interruptions caused by missing or delayed instructions. Simultaneously, the upgrade execution program can perform erase, write, or verification operations on the target storage partition of the auxiliary function processor according to the partition operation instructions. This makes the upgrade process highly flexible and reliable, enabling fine-grained operations on different storage partitions such as the operating system code area, application code area, configuration parameter area, and runtime data area. This avoids the drawbacks of traditional whole firmware replacement methods, significantly reduces storage resource consumption, and improves the ability to upgrade on demand and recover from abnormal partitions. Furthermore, by feeding back the partition operation execution results to the main processing processor, real-time monitoring of the operation status is achieved, allowing the main processing processor to promptly detect and handle potential errors, thereby enhancing the reliability and stability of the entire upgrade process. Finally, after the upgrade process is completed, the upgrade execution program can start the corresponding business program according to the control instructions of the main computing processor, ensuring that the auxiliary function processor can automatically and smoothly resume normal business operation after the upgrade is completed. This greatly improves the automation level of the system and the user experience, and further enhances the software maintainability and system stability of the dual-core dual-system chip.

[0047] Based on the above, this application further proposes that the overall firmware of the auxiliary function processor is logically divided into multiple independent storage partitions, including: operating system code area, application code area, configuration parameter area and running data area.

[0048] Specifically, the auxiliary function processor's overall firmware is logically divided into multiple independent storage partitions. This logical division is not physical isolation, but rather a software-defined approach that conceptually divides a complete firmware image into several independent and manageable units. For example, a partition table can be embedded in the header or a specific location of the firmware image. This partition table records detailed metadata such as the starting address, size, type, and verification information of each logical partition. Before performing an upgrade, the main processing processor can read and parse this partition table to accurately identify and locate each logical partition.

[0049] The operating system code area is specifically used to store the core operating system code required for the assistive function processor to run, including the bootloader, kernel, and basic system service programs. For example, this area can be a read-only flash memory area to ensure the integrity and security of the operating system code and prevent accidental modification during runtime. Alternatively, the operating system code can be stored in compressed form in this area and decompressed into the running memory for execution when the assistive function processor starts. The application code area stores the code for various applications or functional modules that run on the assistive function processor. For example, separate sub-areas can be allocated for different application functions (such as sensor data acquisition, communication protocol stacks, specific algorithm processing, etc.), allowing these applications to be updated or replaced independently. Alternatively, this area can serve as a dynamic loading area, allowing the main processing unit to load different application code into the assistive function processor for execution as needed. The configuration parameter area stores various configuration parameters, calibration data, or user-defined settings for the assistive function processor. These parameters may need to be modified or updated during device operation. For example, this area could be a non-volatile memory (NVM) area, storing configuration items in key-value pairs for easy reading and modification by the main processing unit. Alternatively, configuration parameters could be stored as structured data blocks and accessed and updated through specific API interfaces. The runtime data area stores dynamic data generated by the auxiliary function processor during operation, such as log information, historical records, temporary files, or raw data collected by sensors. For example, this area could be designed as a circular buffer or a log file system to continuously record system running status and events. Alternatively, this area could be used to store intermediate computation results or status information that need to be persisted so that work can be resumed after the auxiliary function processor restarts.

[0050] The above technical solution clearly defines the logical partition types of the auxiliary function processor firmware, enabling upgrade operations to be precisely targeted at different functional areas. Specifically, when the operating system needs to be updated, the main processing processor can operate only on the operating system code area, without processing the application code area, configuration parameter area, or runtime data area, thus significantly reducing the amount of data and time required for the upgrade. Similarly, when an application needs to be updated or configuration parameters need to be adjusted, precise local upgrades can be achieved, avoiding unnecessary overall firmware erasure and reducing resource consumption during the upgrade process. In addition, this clear partitioning greatly improves the maintainability and robustness of the system. For example, when the runtime data area encounters problems due to abnormal operation or data corruption, the main processing processor can only perform recovery or erasure operations on that data area without affecting the normal operation of the core operating system code or applications, thereby avoiding the risk of the entire system being paralyzed due to local problems and improving the stability and reliability of the system. Overall, this refined partition management strategy makes the software upgrade process of dual-core dual-system chips more flexible, efficient, and secure, effectively solving the problems of high resource consumption, insufficient flexibility, and difficulty in targeted recovery faced by traditional overall firmware upgrade methods.

[0051] Reference Figure 2 As shown, this application also provides a multi-partition software upgrade device for a dual-core, dual-system chip. It communicates via a system bus between the main processing unit and the auxiliary function processor to achieve software upgrades and write / erase operations on different storage partitions of the auxiliary function processor. The multi-partition software upgrade method for a dual-core, dual-system chip includes: an upgrade control device located on the main processing unit side and an upgrade execution device located on the auxiliary function processor side. During the software upgrade process, the upgrade control device on the main processing unit side generates operation instructions for different partitions sequentially according to the upgrade operation instruction file and sends them to the auxiliary function processor via the system bus. The upgrade execution device on the auxiliary function processor side, supported by the upgrade execution program, parses and executes the partition operation instructions one by one, performing the corresponding storage operation only on the target partition specified by the instruction. Through the above device structure, independent upgrades and write / erase operations on different storage partitions of the auxiliary function processor are achieved, avoiding the storage occupation problem caused by downloading the entire firmware package, and improving the flexibility and reliability of software upgrades.

[0052] This application discloses a multi-partition software upgrade device for a dual-core, dual-system chip. By combining an upgrade control device located on the main processing unit side with an upgrade execution device located on the auxiliary function processor side through system bus communication, this application avoids the need for the main processing unit to temporarily store complete firmware data and enables independent operation of different storage partitions. Specifically, the upgrade control device dynamically generates partition-level instructions based on upgrade requirements, and the upgrade execution device precisely executes partition operations according to the instructions, ensuring reliable interaction between instructions and data. This design not only reduces storage resource consumption but also improves the flexibility of the upgrade process and the maintainability of the system, effectively meeting the upgrade requirements of low storage consumption, independent partition upgrades, and abnormal partition recovery for auxiliary function processors.

[0053] Based on the above-mentioned device, this application further proposes that the upgrade control device on the main processing processor side is used to generate and issue upgrade operation instructions for each storage partition of the auxiliary function processor; the upgrade execution device on the auxiliary function processor side is used to receive and parse the upgrade operation instructions, and perform corresponding storage operations on the target partition according to the instructions.

[0054] Specifically, the upgrade control unit on the main processor side is used to generate and issue upgrade operation instructions for each memory partition of the auxiliary function processor. The generation of upgrade operation instructions can be based on a preset upgrade strategy, such as automatic generation based on the version differences of the firmware to be upgraded, or dynamic generation based on the upgrade partition and operation type (such as erase, write, verification) selected by the user on the main processor side's interactive interface. These instructions are designed to precisely instruct the auxiliary function processor to operate on specific memory partitions, rather than blindly processing the entire firmware. Instruction issuance is typically achieved through the system bus. For example, the main processor can transfer instruction data blocks to specific memory areas of the auxiliary function processor via DMA (Direct Memory Access) mechanisms, or communicate through shared memory, message queues, etc., to ensure that instructions can be efficiently and accurately transmitted to the auxiliary function processor.

[0055] Simultaneously, the upgrade execution device on the auxiliary function processor side is used to receive and parse the upgrade operation instructions. The receiving process can detect the arrival of new instructions by polling specific registers or memory addresses on the system bus, or by using an interrupt mechanism; when the main processing processor issues an instruction, the auxiliary function processor generates an interrupt, thus responding promptly and acquiring the instruction. Instruction parsing refers to decoding the received binary or structured instruction data according to a predefined protocol or format to extract key information, such as the operation type (e.g., erase, write, checksum), the target partition's identifier, the partition's starting address, partition capacity, and the length of any data blocks involved.

[0056] Building upon this, the upgrade execution unit on the auxiliary function processor side is also used to perform corresponding storage operations on the target partition according to the instructions. Storage operations may include, but are not limited to: erasing data from the target storage partition to clear old data; writing new firmware data to the target partition; or verifying the data in the target partition to ensure data integrity and correctness. These operations are typically performed by accessing the storage controller or flash memory controller interface within the auxiliary function processor, thereby achieving precise control over a specific partition.

[0057] Through the above technical solution, this application clearly defines the functional responsibilities of the upgrade control device on the main processing processor side and the upgrade execution device on the auxiliary function processor side, making the generation, issuance, reception, and parsing of upgrade operation instructions more specific and precise. The upgrade control device on the main processing processor side can generate upgrade operation instructions for specific storage partitions according to actual needs, avoiding unnecessary resource consumption and data transmission in traditional overall firmware upgrade methods. The upgrade execution device on the auxiliary function processor side can accurately receive, parse, and execute these partition operation instructions, ensuring the accuracy of storage operations (such as erasure, writing, or verification) on the target partition. This refined partition management and operation mechanism significantly improves the reliability and efficiency of software upgrades. Especially when the auxiliary function processor malfunctions or the data area is damaged, targeted recovery can be achieved without affecting other partitions, thus effectively solving the problem of inaccurate instruction processing caused by the lack of specific device functions.

[0058] Based on the above-mentioned device, this application further proposes that the upgrade control device on the main processing processor side includes the following functional modules: an upgrade program loading module, a partition upgrade instruction parsing module, a partition data management module, and an upgrade instruction sending module.

[0059] The upgrade program loading module is used to load the upgrade execution program required for the upgrade phase into the auxiliary function processor's runtime memory before the auxiliary function processor performs the software upgrade, and to control the auxiliary function processor to enter the upgrade execution state. Specifically, this module can be an independent software component or firmware function block, called by the main processor during system startup or upgrade initialization. It interacts with the auxiliary function processor through a specific communication protocol (e.g., JTAG, SPI, or a custom bus protocol) to transfer the upgrade execution program (typically a small, efficient bootloader or firmware update agent) into the auxiliary function processor's runtime memory. After loading, the module sends control signals (e.g., reset signals, interrupt signals, or specific register write operations) to instruct the auxiliary function processor to jump to the program's entry point for execution. In another implementation, this module can also be part of the main processor's operating system kernel, directly writing the upgrade execution program into the auxiliary function processor's runtime memory through memory mapping or DMA (Direct Memory Access) mechanisms. Subsequently, by writing preset values ​​to specific control registers of the auxiliary function processor, the auxiliary function processor is triggered to execute the program from a specified address, thereby entering the upgrade execution state.

[0060] The partition upgrade instruction parsing module is used to acquire and parse the upgrade operation instruction file. Specifically, this module can be a software parser that reads the upgrade operation instruction file (e.g., an XML, JSON, or custom binary format file) and, according to predefined syntax rules and data structures, parses the partition identification information, partition starting address, maximum available storage space of the partition, and operation type (e.g., erase, write, checksum) line by line. The parsing results are stored in a data structure in memory for use by subsequent modules. In another implementation, this module can also be implemented as a state machine or finite automaton, which identifies and extracts key information based on specific fields of the instruction file (e.g., opcode, parameter length, etc.). For example, for a binary instruction file, this module can read it sequentially by byte stream, identify fields such as instruction header, partition ID, address, and length, and perform CRC checks to ensure the integrity and correctness of the instructions.

[0061] The partition data management module is used to obtain firmware data for the corresponding partition or generate an erase request for the target partition based on the operation instructions parsed by the partition upgrade instruction parsing module. Specifically, this module can be a file system interface or a storage manager. Based on the partition identification information and operation type provided by the partition upgrade instruction parsing module, it locates and reads the corresponding firmware data block from the main processor's storage medium (e.g., flash memory, hard disk, or network storage). If the operation is erase, a logical erase request is generated without requiring actual data. In another implementation, this module can also be a memory buffer manager. Based on the parsed instructions, it extracts data for a specific partition from the pre-loaded firmware image and temporarily stores it in a DMA buffer for efficient subsequent transfer via the system bus. For erase operations, this module only needs to mark the target partition as pending erase and prepare the corresponding erase command.

[0062] The upgrade instruction sending module is used to send partition operation instructions to the auxiliary function processor via the system bus. When the operation instruction is a write operation, it is also used to synchronously send the firmware data of the corresponding partition. Specifically, this module can be a bus driver or a communication protocol stack. It encapsulates the operation instructions (e.g., erase command, write command, verification command) parsed by the partition upgrade instruction parsing module and the firmware data prepared by the partition data management module into data packets or transactions conforming to the system bus communication protocol. For example, this data can be sent to the auxiliary function processor via SPI, I2C, UART, or a custom parallel bus interface. In another implementation, this module can also be a DMA controller interface. It configures a DMA channel to directly transfer partition operation instructions and firmware data from the main processing processor's memory to the system bus, with the bus controller responsible for routing to the auxiliary function processor. During a write operation, this module ensures that the instruction and corresponding data are sent synchronously in time to avoid data misalignment or delay.

[0063] Through the above technical solution, the upgrade control device on the main processing processor side is refined into four functional modules: an upgrade program loading module, a partition upgrade instruction parsing module, a partition data management module, and an upgrade instruction sending module. This achieves modularization and efficient collaboration in the upgrade process. The upgrade program loading module prepares the upgrade environment for the auxiliary function processor before the upgrade, avoiding delays in program loading and errors in state switching during the upgrade process. The partition upgrade instruction parsing module accurately understands the upgrade operation instruction file, providing a reliable basis for subsequent operations and effectively preventing upgrade failures caused by instruction misunderstandings. The partition data management module implements targeted management of partition data, supporting flexible execution of erase or write operations, avoiding data management chaos. The upgrade instruction sending module optimizes communication efficiency, reduces data transmission frequency and latency, and ensures timely and accurate execution of operations. This modular design significantly reduces the coupling between various components, improves the efficiency and reliability of the upgrade operation, and effectively solves the problems of low efficiency, chaotic management, or increased error rates caused by a lack of specific module divisions. This makes the entire multi-partition software upgrade process more stable, efficient, and easy to maintain.

[0064] Based on the above-mentioned device, this application further proposes that the upgrade execution device on the auxiliary function processor side includes the following functional modules: an upgrade instruction receiving module, a partition instruction parsing module, a partition storage operation module, and an upgrade completion control module.

[0065] The upgrade instruction receiving module receives partition operation instructions and corresponding partition firmware data sent by the main processing processor via the system bus. This module serves as the data communication interface between the auxiliary function processor and the main processing processor. Its core function is to ensure that upgrade instructions and firmware data are reliably and completely transmitted from the main processing processor to the auxiliary function processor, thus providing accurate input for subsequent upgrade operations. Specifically, this module can be implemented through a hardware interface (e.g., DMA controller, SPI, I2C, etc.) in conjunction with corresponding software drivers. The hardware handles physical layer data transmission, while the software handles data packet assembly and unpacking. Alternatively, this module can be implemented by allocating a shared memory region in the system memory and combining it with an interrupt mechanism. After the main processing processor writes data to the shared memory, it notifies the auxiliary function processor to read the data via an interrupt.

[0066] The partition instruction parsing module parses received partition operation instructions to obtain the target partition's identifier, starting address, capacity, and corresponding operation type. This module is responsible for structured analysis and information extraction of the received raw partition operation instructions. Its role is to convert the received instructions from their raw format into structured information that subsequent modules can understand and execute, providing precise parameters for partition operations. Specifically, this module can be implemented using predefined data structures and parsing functions. For example, instructions may use TLV (Type-Length-Value) format, and the parsing module identifies fields based on type and extracts the length and value. Alternatively, this module can be implemented using a state machine or syntax parser, parsing the instruction stream step-by-step according to the instruction protocol specifications to extract key parameters such as partition identifier, starting address, capacity, and operation type.

[0067] The partitioned storage operation module performs corresponding storage operations on the target storage partition specified by the instructions in the auxiliary function processor according to the parsed operation type. When the operation type is a write operation, the partitioned storage operation module writes the received partition firmware data to the target partition; when the operation type is an erase operation, the partitioned storage operation module performs an erase operation on the target partition. This module is responsible for directly interacting with the storage hardware of the auxiliary function processor to perform actual data read / write, erase, and other operations. Its function is to perform specific storage operations on the target storage partition of the auxiliary function processor according to the parsed operation type and parameters, ensuring the correctness and integrity of the data. Specifically, this module can be implemented by calling the underlying storage driver interface (e.g., Flash driver, EEPROM driver, etc.), which encapsulates the physical operation details of the storage medium. Alternatively, this module can be implemented by directly manipulating the registers of the storage controller; for example, for NAND Flash, a series of low-level operations such as block erase, page programming, and page read are required.

[0068] Upgrade Completion Control Module: This module controls the auxiliary function processor to exit the upgrade execution state and start the upgraded software system after all partition operation instructions have been executed. This module is responsible for coordinating the auxiliary function processor's transition from the upgrade state to the normal operation state and starting the new system or business program after all upgrade operations are completed. Its role is to ensure the integrity of the upgrade process, achieve a smooth transition for the auxiliary function processor, and avoid system stagnation or startup failure. Specifically, this module can set specific status registers or flags, and after all partition operations are completed, the main processing processor sends a final confirmation instruction, triggering the auxiliary function processor to perform a reset or jump to the entry address of the new firmware. Alternatively, this module can maintain an upgrade state machine within the auxiliary function processor. When all operations are successfully completed and the main processing processor issues an exit instruction, the state machine switches to the "normal operation" state and jumps to a preset startup address to load and run the upgraded business program.

[0069] Through the above technical solution, the upgrade execution device on the auxiliary function processor side, with its modular design, achieves precise reception, parsing, and execution of partition operation commands, ensuring the integrity of the upgrade process and the stability of system startup. The upgrade command receiving module ensures reliable transmission of commands and firmware data, effectively preventing data loss or transmission errors. The partition command parsing module accurately obtains detailed information about the target partition, providing a precise basis for subsequent operations and preventing operational deviations due to command misunderstandings. The partition storage operation module performs targeted erase or write operations on the target partition based on the parsed operation type, ensuring the efficiency and correctness of data writing or erasing, significantly improving the flexibility of partition operations. Finally, after all partition operations are completed, the upgrade completion control module smoothly controls the auxiliary function processor to exit the upgrade state and start the new system, ensuring the integrity of the upgrade process and the stability of system startup, achieving a seamless transition. The collaborative work of these modules significantly enhances the execution capabilities of the auxiliary function processor side, thereby optimizing the reliability and efficiency of the entire upgrade process and effectively solving the problems of inaccurate command execution and unstable system recovery during partition upgrades.

[0070] Based on the above-mentioned device, this application further proposes that the firmware data of the partition is an independent data file obtained by splitting according to the auxiliary function processor firmware storage structure, and the firmware data corresponding to different partitions are stored independently of each other.

[0071] Specifically, the "partition firmware data" here refers to the data of each storage partition of the accessibility processor, rather than the overall firmware image of the entire accessibility processor. This data can be automatically generated by development tools based on a preset partition table during the firmware development phase, or obtained by parsing and extracting the complete firmware image through specific scripts or dedicated tools during the firmware packaging phase. Furthermore, the firmware data of this partition is an independent data file obtained by splitting the firmware storage structure of the accessibility processor. This means that each data file precisely corresponds to a specific storage partition within the accessibility processor, and its content and structure match the actual layout of that partition. For example, a unified firmware file format can be defined, containing partition metadata (such as starting address, size, and checksum), enabling the splitting tool to accurately identify and extract the data; or the firmware storage structure information can be obtained by utilizing the interface provided by the storage controller or bootloader within the accessibility processor, and splitting can be performed accordingly. In addition, the firmware data corresponding to different partitions is stored independently, meaning that the firmware data of each partition is managed and stored as an independent entity. For example, firmware data for each partition can be stored as a separate file, existing as an independent file in the file system; or the firmware data for all partitions can be packaged into a container file, but logically isolated by indexes or offsets to ensure that the data for each partition can be accessed and updated independently.

[0072] Through the above technical solution, the main processing unit (MPU) no longer needs to temporarily store or process the firmware image of the entire auxiliary function processor (AFC) when performing upgrade or recovery operations. Instead, the partition data management module only needs to acquire and process the independent firmware data file of the target partition. This approach significantly reduces the storage resource consumption required by the MPU because it avoids processing redundant data. Simultaneously, since the firmware data of each partition is independent and precisely matched to its storage structure, this makes the upgrade process highly flexible. For example, when only the application code area of ​​the AFC needs to be updated, the MPU only needs to load and transfer the independent firmware data of the application code area, without touching the operating system code area or configuration parameter area. Similarly, when the AFC malfunctions or a data area is corrupted, targeted recovery operations can be performed only on the corrupted partition without affecting other normally functioning partitions. This not only improves the efficiency of upgrades and recovery but also enhances the stability and maintainability of the system, fulfilling the requirements of low storage consumption, independent partition upgrades, and recovery of abnormal partitions.

[0073] The multi-partition software upgrade method for dual-core dual-system chips disclosed in this application includes the following steps: Step S101: Prepare the upgrade execution program Before performing a software upgrade for the auxiliary function processor, an upgrade execution program is provided in advance to perform the upgrade operation.

[0074] The upgrade executor includes basic boot capabilities and the storage drivers required to perform partition erasure and partition writing, and supports receiving and parsing partition operation instructions from the main processing unit via the system bus.

[0075] The upgraded execution program can run independently without relying on the existing business software of the auxiliary function processor.

[0076] Step S102: Partition and split the accessibility processor firmware Based on the software architecture and storage layout of the auxiliary function processor, the original overall firmware is split into multiple independent partition firmware data.

[0077] The partitions include at least one or more of the following: application code partition, configuration data partition, and runtime data partition. The firmware data corresponding to different partitions is stored separately and is independent of each other.

[0078] Step S103: Generate partition upgrade operation instruction file Based on the partition type required for this upgrade, an upgrade operation instruction file will be generated.

[0079] In the upgrade operation instruction file, each operation instruction corresponds to a target partition and includes at least the following information: Partition identifier; Partition start address; Maximum partition size; Operation type information, including write operations and erase operations.

[0080] Multiple operation instructions are arranged in a predetermined upgrade order to form an upgrade operation instruction file.

[0081] Step S104: Load the upgrade executor and start the upgrade mode. Once the upgrade begins, the main processing unit loads the upgrade execution program into the auxiliary function processor's memory and controls the auxiliary function processor to enter the upgrade execution state.

[0082] In this state, the auxiliary function processor runs the upgrade executor to perform subsequent partition upgrade operations.

[0083] Step S105: Parse the upgrade operation instruction file The main processing unit acquires and parses the upgrade operation instruction file, and sequentially obtains the firmware data of the corresponding partition according to the instruction order, or generates an erase request for the corresponding partition.

[0084] Step S106: Issue partition operation commands and partition data The main processing unit sends partitioning operation instructions to the auxiliary function processor via the system bus.

[0085] When the operation instruction is a write operation, the main processing unit synchronously sends the partition firmware data corresponding to that partition. When the operation command is an erase operation, only the erase command information is sent.

[0086] Step S107: Perform partition upgrade operation Under the control of the upgrade executor, the auxiliary function processor receives and parses partition operation instructions, and performs corresponding erase or write operations on the target partition according to the partition information and operation type carried in the instructions.

[0087] In some implementations, the received partition firmware data is checked for integrity before the write operation is performed, and the write operation is performed after the check passes.

[0088] Step S108: Complete the upgrade and start the upgraded software. Once all partitioning operation instructions have been executed, the main processing unit controls the auxiliary function processor to exit the upgrade execution state and starts the upgraded software system, completing the software upgrade process for the auxiliary function processor.

[0089] The above method enables independent upgrading and erasing of different storage partitions of the auxiliary function processor, avoiding the storage pressure caused by downloading the entire firmware package, and improving the flexibility and reliability of the upgrade process.

[0090] Obviously, the above embodiments are merely illustrative examples for clear explanation and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations here. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A multi-partition software upgrade method for a dual-core, dual-system chip, characterized in that, Includes the following steps: S1. Preparation Phase: S1-1 Firmware Splitting and Instruction File Generation: The overall firmware of the auxiliary function processor is logically split into multiple independent storage partitions, and independent firmware data is prepared for each partition. The main processing processor generates an upgrade operation instruction file according to the specific requirements of this upgrade or recovery. S1-2, Upgrade Execution Program Loading: Before the actual upgrade process begins, the main computing processor loads the upgrade execution program used to perform partition-level upgrade operations into the running memory of the auxiliary function processor; S2, Execution Phase: S2-1, Instruction Parsing and Issuance: The main processing unit begins to parse the pre-generated upgrade operation instruction file line by line; S2-2, Bus Communication and Partition Operation: The main processing processor sends the parsed partition operation instructions to the auxiliary function processor in the upgrade execution state through the system bus. After receiving these instructions and data, the upgrade execution program on the auxiliary function processor side parses them. S2-3, Result Feedback: After completing each partitioning operation, the auxiliary function processor feeds back the execution result of the operation to the main processing processor through the system bus; S3. Completion Phase: Once the main processing processor confirms that all upgrade operation instructions have been successfully executed and all partitions have been updated or restored as required, it will send a control instruction to the auxiliary function processor to exit the upgrade execution state.

2. The multi-partition software upgrade method for a dual-core, dual-system chip according to claim 1, characterized in that: The upgrade operation instruction file is used to describe the partition-level operations that need to be performed during this upgrade process, driving the execution order and operation content of the entire upgrade process. It contains multiple upgrade operation instructions arranged in sequence, and the upgrade operation instructions include at least: partition identification information, partition start address, and maximum available storage space of the partition.

3. The multi-partition software upgrade method for a dual-core, dual-system chip according to claim 1, characterized in that: The upgrade execution program is used to cooperate with the main computing processor to complete the partition upgrade operation during the upgrade process, and it has the following features: Receive partition operation instructions sent by the main processing processor via the system bus; According to the partition operation instructions, erase, write or verify operations are performed on the target storage partition of the auxiliary function processor; The partitioning operation execution result is fed back to the main processing processor; After the upgrade process is completed, the corresponding business program is started according to the control instructions of the main computing processor.

4. The multi-partition software upgrade method for a dual-core, dual-system chip according to claim 1, characterized in that: The overall firmware of the auxiliary function processor is logically divided into multiple independent storage partitions, including: operating system code area, application code area, configuration parameter area, and runtime data area.

5. A dual-core, dual-system-chip multi-partition software upgrade device, which communicates via a system bus between a main processing processor and an auxiliary function processor to perform software upgrades and erase / write operations on different storage partitions of the auxiliary function processor, characterized in that: The multi-partition software upgrade method using a dual-core dual-system chip as described in any one of claims 1-4 includes: an upgrade control device disposed on the main processing processor side, and an upgrade execution device disposed on the auxiliary function processor side.

6. The multi-partition software upgrade device for a dual-core, dual-system chip according to claim 5, characterized in that: The upgrade control device on the main computing processor side is used to generate and issue upgrade operation instructions for each storage partition of the auxiliary function processor. The upgrade execution device on the auxiliary function processor side is used to receive and parse the upgrade operation instruction, and perform corresponding storage operations on the target partition according to the instruction.

7. The multi-partition software upgrade device for a dual-core, dual-system chip according to claim 5, characterized in that: The upgrade control device on the main processing processor side includes the following functional modules: Upgrade program loading module: It is used to load the upgrade execution program required for the upgrade stage into the running memory of the auxiliary function processor before the auxiliary function processor performs the software upgrade, and control the auxiliary function processor to enter the upgrade execution state; Partition upgrade instruction parsing module: It is used to obtain and parse the upgrade operation instruction file; Partition data management module: It is used to obtain firmware data of the corresponding partition or generate an erase request for the target partition according to the operation instructions parsed by the partition upgrade instruction parsing module. Upgrade instruction sending module: It is used to send partition operation instructions to the auxiliary function processor through the system bus. When the operation instruction is a write operation, it is also used to synchronously send firmware data of the corresponding partition.

8. The multi-partition software upgrade device for a dual-core, dual-system chip according to claim 7, characterized in that: The upgrade execution device on the auxiliary function processor side includes the following functional modules: Upgrade instruction receiving module: It is used to receive partition operation instructions and partition firmware data corresponding to the partition operation instructions sent by the main computing processor through the system bus; Partition instruction parsing module: It is used to parse the received partition operation instructions and obtain the target partition's identification information, partition start address, partition capacity, and corresponding operation type; Partition storage operation module: It is used to perform corresponding storage operations on the target storage partition specified by the instruction in the auxiliary function processor according to the parsed operation type. When the operation type is a write operation, the partition storage operation module writes the received partition firmware data to the target partition. When the operation type is an erase operation, the partition storage operation module performs an erase operation on the target partition. Upgrade completion control module: It is used to control the auxiliary function processor to exit the upgrade execution state and start the upgraded software system after all partition operation instructions have been executed.

9. The multi-partition software upgrade device for a dual-core, dual-system chip according to claim 7, characterized in that: The firmware data of the partition is an independent data file obtained by splitting the firmware storage structure of the auxiliary function processor, and the firmware data corresponding to different partitions are stored independently of each other.

Images