Partition table partitioning method for embedded device

Abstract

The invention provides a partition table partitioning method for embedded equipment, which comprises the following steps that: in a development stage, partition information required by the embedded equipment is deployed in a uniform partition table, and various partition table schemes are compatible in the uniform partition table; in a compiling stage, analyzing the unified partition table according to partition information to generate a partition table file, a burning configuration file and an upgrading configuration file which are required for starting the embedded equipment; in a mirror image generation stage, generating a burning full mirror image file according to the burning configuration file and all firmware partitions, and generating a firmware upgrade package according to the upgrade configuration file and a partition table mirror image needing to be upgraded; and in a production burning stage, burning the burning full mirror image file to a storage medium of embedded equipment to complete program burning. According to the method, the development process can be simplified, the maintenance efficiency is improved, the partition configuration consistency is ensured, and the problem of equipment starting or upgrading failure caused by improper management of information of multiple partitions is avoided.

Description

Technical Field

[0001] This invention relates to the field of chip and storage technology, and more specifically, to a partitioning method for a partition table in an embedded device. Background Technology

[0002] In current embedded systems, the choice of partition table scheme is constrained by various factors, such as hardware characteristics, storage media type, system requirements, and compatibility requirements. For high-performance, high-capacity embedded devices, such as industrial gateways and automotive systems, the GPT (GUID Partition Table) partitioning scheme is typically chosen. This scheme supports large-capacity storage media and has good scalability and reliability. For small-capacity NAND flash smart speaker devices, static MTD (Memory Technology Device) partitioning is often used. This scheme is simple and suitable for small-capacity storage. In addition, central control devices using eMMC storage chips may utilize the hardware partitioning scheme of eMMC itself. To balance boot reliability and storage flexibility, a hybrid partitioning scheme also exists, in which the kernel is loaded through static MTD partitioning during the bootloader stage, and the kernel is mounted with either GPT partitioning or eMMC user space during runtime.

[0003] In AIoT (Artificial Intelligence & Internet of Things) scenarios, embedded devices have diverse functions and business types, leading to the need to develop and maintain multiple partitioning schemes for different devices. For example, different devices may require different partition sizes, partition read / write attributes, and partition encryption attributes. Furthermore, this adds complexity when delivering SDKs to third-party developers, as different devices may require different partitioning configuration files.

[0004] In addition to the partition table used during device startup, the packaging process also requires generating a full firmware flashing image and an OTA (Over-The-Air) upgrade image based on the partition information. However, in traditional methods, different tools require different partition configuration files for image creation. This necessitates maintaining multiple partition description files with similar content but different formats in the development environment. For example, for the GPT partition scheme, a GPT partition file needs to be generated; for the MTD partition scheme, MTD partition parameters need to be generated. This approach is not only cumbersome but also prone to inconsistencies in partition configuration when partitions are changed, leading to partition corruption, device boot failure, and other problems.

[0005] In summary, existing technologies suffer from at least the following problems or shortcomings: They require maintaining multiple partitioning schemes and partition description files, increasing development and maintenance complexity and easily leading to inconsistent partition configurations. Furthermore, existing technologies lack flexibility in handling partition read / write and encryption attributes, failing to adequately meet the needs of different devices. Summary of the Invention

[0006] This invention provides a partitioning method for a partition table in an embedded device, comprising: S1: During the development phase, the partitioning information required by the embedded device is deployed in a unified partitioning table, wherein the unified partitioning table is compatible with multiple partitioning table schemes; S2: During the compilation phase, the unified partition table is parsed based on the partition information to generate the partition table file, burning configuration file and upgrade configuration file required for the embedded device to boot; S3: During the image generation stage, a full image file for burning is generated based on the burning configuration file and all firmware partitions, and a firmware upgrade package is generated based on the upgrade configuration file and the partition table image to be upgraded. S4: During the production burning stage, the full image file is burned to the storage medium of the embedded device to complete the program burning.

[0007] Furthermore, the partitioning information mentioned in step S1 includes any one or more of the following: Partition scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type.

[0008] Further, step S2, which involves parsing the unified partition table based on the partition information to generate the partition table file required for the embedded device to boot, includes: Generate a partition table file in the corresponding format based on the partition scheme type; If the partition scheme type is GPT partition table, then a GPT partition file is generated and packaged into a separate partition image; If the partition scheme type is DTB partition scheme, then a DTB file is generated and written to the unified DTB partition; If the partition scheme type is Bootloader hard-coded scheme, then MTD partition parameters are generated and written to the header file.

[0009] Furthermore, the compilation stage also includes: during the parsing and generation of the partition table file, the read / write attributes of the partitions will be judged and processed; specifically including: When a partition's read / write attribute is hidden, writing the partition's information to the partition table file is prohibited, and the partition's offset address is hardcoded to a specified module, making the partition directly accessible via its physical address and invisible to the system.

[0010] Furthermore, the compilation phase also includes: when compiling the image file for each partition, reading the encryption attributes of the partition and using this to determine whether to encrypt the image of the partition.

[0011] Furthermore, generating a full flashing image file based on the flashing configuration file and all firmware partitions includes: The flashing image creation tool is invoked to package all firmware partitions into a single full flashing image file according to the flashing configuration file.

[0012] Furthermore, generating the firmware upgrade package based on the upgrade configuration file and the partition table image to be upgraded includes: The upgrade image creation tool is invoked to package the partition image to be upgraded and the partition configuration information into a firmware upgrade package according to the upgrade configuration file.

[0013] Furthermore, it also includes the step: S5: During the device startup phase, the embedded device loads the partition table file and loads partitions according to the partition attributes.

[0014] Furthermore, it also includes the following step: S6: During the firmware update phase, the upgrade program parses the upgrade configuration file in the firmware upgrade package and writes the partition image to be upgraded to the specified address of the storage medium according to the partition offset address of the configuration file.

[0015] Furthermore, the embedded device loading the partition table file and loading partitions according to partition attributes includes: If the partition has encryption attributes, the decryption module is called to decrypt the partition. If the partition's read / write attribute is read-only, then the partition is set to read-only access mode with write access prohibited.

[0016] Furthermore, the unified partition table supports the addition of new partition scheme types, and the new partition scheme types generate corresponding format partition table files through scripts.

[0017] The embodiments of the present invention have at least the following beneficial effects: 1. By using a unified partition table, compatibility with multiple partitioning schemes is achieved, which solves the problem that traditional embedded devices need to maintain multiple partitioning schemes due to hardware differences, reduces development complexity and maintenance costs, and supports flexible expansion to new partitioning types.

[0018] 2. The system automatically processes the read / write and encryption attributes of partitions during the compilation phase, ensuring the security of sensitive partition data. This solves the problems of scattered, easily overlooked, or conflicting partition attribute configurations in traditional solutions, thus improving the stability and security of the system.

[0019] 3. Based on a unified partition table, the system automatically generates a full flashing image and firmware upgrade package, ensuring consistency in partition configuration between production flashing and OTA upgrades. This avoids flashing errors or upgrade failures caused by the inconsistency of multiple partition description files in traditional methods, thereby improving production efficiency and upgrade reliability. Attached Figure Description

[0020] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein: Figure 1 This is a flowchart illustrating a partitioning method for an embedded device according to an embodiment of the present invention. Figure 2 for Figure 1 A schematic diagram illustrating a specific application of the partition table partitioning method for embedded devices; Figure 3 This is a schematic diagram of the partition composition of a partition table partitioning method for embedded devices provided in an embodiment of the present invention; Figure 4 This is a firmware upgrade flowchart for a partition table partitioning method for embedded devices, provided as an embodiment of the present invention. Detailed Implementation

[0021] The principles and spirit of the invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided to make the invention more thorough and complete, and to fully convey the scope of the invention to those skilled in the art.

[0022] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, the present invention can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0023] It should be noted that the number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0024] Figure 1 This is a flowchart illustrating a partitioning method for an embedded device provided in an embodiment of the present invention. Figure 2 for Figure 1 A schematic diagram illustrating a specific application of the partition table partitioning method for embedded devices.

[0025] like Figure 1 As shown, a partitioning method for a partition table in an embedded device includes: S1: During the development phase, the partitioning information required by the embedded device is deployed in a unified partitioning table, wherein the unified partitioning table is compatible with multiple partitioning table schemes; S2: During the compilation phase, the unified partition table is parsed based on the partition information to generate the partition table file, burning configuration file and upgrade configuration file required for the embedded device to boot; S3: During the image generation stage, a full image file for burning is generated based on the burning configuration file and all firmware partitions, and a firmware upgrade package is generated based on the upgrade configuration file and the partition table image to be upgraded. S4: During the production burning stage, the full image file is burned to the storage medium of the embedded device to complete the program burning.

[0026] The following references Figure 1 and Figure 2 The partitioning method for embedded devices provided by this invention is described in detail.

[0027] It should be noted that this invention proposes a partitioning method for embedded devices. This method deploys the partitioning information required by the embedded device in a unified partitioning table within the packaging environment during the development phase, using a unified partitioning layout description. The unified partitioning table refers to a configuration file that centrally manages all partitioning information. It is compatible with various partitioning schemes, such as GPT, GUID Partition Table, DTB, Device Tree Blob, and Bootloader hard-coded schemes. This unified partitioning table deployment method allows for the generation of partitioning table files and image files in different formats based on the same configuration file during subsequent compilation and image generation stages, thereby simplifying the development and maintenance process. Simultaneously, the partitioning information includes partitioning scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type. This information details the characteristics of each partition, providing necessary parameters for subsequent partitioning table generation and image creation.

[0028] like Figure 3 The diagram showing the partition composition illustrates that, in some embodiments, the partition information in step S1 includes: Partition scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type.

[0029] It should be noted that the partition information mentioned in this invention includes partition scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type. This partition information is a core component of the embedded device's partition table, detailing the characteristics and configuration requirements of each partition. The partition scheme type determines the format and structure of the partition table, while the storage media information pertains to the physical storage device on which the partition depends. Parameters such as partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type further refine the specific configuration and management methods of the partitions. This comprehensive consideration and configuration of information enables the embedded device to flexibly manage storage space while ensuring data security and system stability.

[0030] Specifically, the partition scheme type refers to the partition table format used by the embedded device. Common formats include GPT, GUIDPartition Table, DTB, Device Tree Blob, and Bootloader hard-coded schemes. GPT partition tables are suitable for large-capacity storage media and offer good scalability and reliability. DTB partition schemes are typically used in embedded systems, describing hardware information through a device tree. Bootloader hard-coded schemes, on the other hand, directly write partition parameters into the bootloader code, suitable for scenarios with high boot speed requirements. Storage media information includes the type of storage media, such as NAND flash or eMMC, and its capacity. This information determines the layout and size of the partitions. The partition backup scheme type refers to the backup strategy used to improve data reliability, such as image backup or parity backup. The partition file path is the storage location of the partition data in the development environment, facilitating access to this data during the compilation and image generation stages. The partition offset address is the starting address of the partition in the storage media, determining its location. The partition size is the amount of storage space occupied by each partition, set according to the device's requirements. Partition read / write attributes define the access permissions of a partition, such as read-only, read-write, or hidden. Partition encryption attributes are used to protect the security of partition data; when encryption is enabled, partition data is encrypted during storage and transmission. Partition file system type refers to the file system format used by the partition, such as FAT32, EXT4, etc., which affects the partition's read / write performance and data management methods.

[0031] Preferably, when configuring partition information, developers can make detailed settings according to the specific needs of the embedded device. For example, in choosing the partition scheme type, if the device needs to support large-capacity storage and has high requirements for partition flexibility, the GPT partition scheme can be selected; if the device has high requirements for boot speed, the Bootloader hard-coded scheme can be selected. In setting the storage media information, if the device uses NAND flash storage media, its erase / write cycles and read / write speeds need to be considered, and partition sizes should be allocated reasonably to optimize performance. For the partition backup scheme type, if the device stores important data, a mirror backup scheme can be selected to ensure data redundancy and reliability. In setting the partition offset address, precise configuration is required based on the physical structure of the storage media and the partition layout to avoid conflicts between partitions. For partition encryption attributes, if the device stores sensitive data, encryption can be enabled, and a suitable encryption algorithm, such as the AES advanced encryption standard, can be selected to ensure data security. In setting the partition file system type, a suitable file system format can be selected according to the device's read / write requirements; for example, for devices requiring frequent read / write operations, the EXT4 file system can be selected to improve performance. With these detailed configurations, developers can ensure that the partition table of the embedded device meets the device's operational requirements and provides efficient data management and security.

[0032] In some embodiments, step S2, which involves parsing the unified partition table based on partition information to generate the partition table file required for the embedded device to boot, includes: Generate a partition table file in the corresponding format based on the partition scheme type; If the partition scheme type is GPT partition table, then a GPT partition file is generated and packaged into a separate partition image; If the partition scheme type is DTB partition scheme, then a DTB file is generated and written to the unified DTB partition; If the partition scheme type is Bootloader hard-coded scheme, then MTD partition parameters are generated and written to the header file.

[0033] It should be noted that the process of generating the partition table file mentioned in this invention involves generating a partition table file in a corresponding format based on the partition scheme type in the partition information. This means that during the compilation phase, the system will automatically generate a partition table file suitable for the partition scheme type defined in the unified partition table. For example, if the partition scheme type is GPT partition table, a GPT partition file is generated and packaged into a separate partition image; if the partition scheme type is DTB partition scheme, a DTB file is generated and written to the unified DTB partition; if the partition scheme type is Bootloader hard-coded scheme, MTD partition parameters are generated and written to the header file. This process ensures that the format of the partition table file matches the actual needs of the embedded device, while also simplifying the development process and reducing the complexity and possibility of errors in manual configuration.

[0034] Specifically, the process of generating partition table files involves various partitioning schemes and their corresponding processing methods. GPT partitioning is a modern scheme suitable for high-capacity storage media, offering good scalability and reliability. When generating a GPT partition file, the system generates a GPT partition table file based on partition information in a unified partition table, such as partition size and offset address, and packages it into a separate partition image. DTB partitioning is a device tree-based partitioning scheme, typically used in embedded systems, where hardware information is described through a device tree. When generating a DTB file, the system writes the partition information into a unified DTB partition. The bootloader hard-coding scheme directly writes partition parameters into the bootloader code, suitable for scenarios with high boot speed requirements. When generating MTD partition parameters, the system writes the partition information into a header file for loading at startup. These different processing methods ensure that the partition table file can adapt to different hardware and system requirements.

[0035] Preferably, some key steps in the process of generating the partition table file can be further refined. For example, when generating a GPT partition file, the system first parses the partition information in the unified partition table, including partition size, offset address, encryption attributes, etc. Then, based on this information, it generates the GPT partition table file and packages it into a separate partition image. This process can be automated by scripts, ensuring the accuracy and consistency of the partition table file. For the DTB partition scheme, the system writes the partition information into a unified DTB partition, including the partition size, offset address, and file system type. When generating MTD partition parameters, the system writes the partition information into a header file, which is read by the bootloader and used in the boot process. Through these detailed processing steps, the system can ensure that the generated partition table file meets the specific requirements of the embedded device, while improving the system's reliability and security.

[0036] In some embodiments, during the process of parsing and generating the partition table file, the read / write attributes of the partitions are determined, specifically including: When a partition's read / write attribute is hidden, writing the partition's information to the partition table file is prohibited, and the partition's offset address is hardcoded to a specified module, making the partition directly accessible via its physical address and invisible to the system.

[0037] It's important to note that during the compilation phase, when processing partition read / write attributes, if a partition's read / write attribute is set to hidden, its information will not be written to the partition table file. Instead, the partition's offset address will be hard-coded into a designated module, making the partition directly accessible via its physical address while remaining invisible to the rest of the system. This approach aims to protect the data within the partition, preventing unauthorized access and modification. In this way, hidden partitions can be used to store sensitive information, such as encryption keys or system configuration files, thereby enhancing system security.

[0038] Specifically, a partition's read / write attributes refer to its access permission settings, typically including read-only, read-write, and hidden types. The hidden attribute is a special type of read / write attribute that makes the partition invisible to the system and accessible only through a specific physical address. The partition offset address refers to the starting position of the partition in the storage medium; it is a physical address used to determine the partition's specific location within the storage medium. When a partition is set to hidden, its offset address is hard-coded into a designated module, typically a specific driver or firmware module in an embedded system. Hard-coding means writing the offset address directly into the code, rather than accessing it through a partition table file. This method ensures that the access path to the hidden partition is fixed, thereby increasing data security.

[0039] Preferably, some key steps can be further refined when handling hidden partitions. For example, during the compilation phase, the system first checks the read / write attributes of the partitions. If a partition's read / write attribute is found to be set to hidden, the system skips the step of writing the partition's information to the partition table file. Then, the system hardcodes the partition's offset address into a designated module. This process can be automated by scripts, ensuring the accuracy of the hidden partition settings. In practical applications, hidden partitions are often used to store sensitive information, such as encryption keys or system configuration files. This information needs to be loaded at system startup but cannot be accessed by ordinary users or applications. By hardcoding the offset address, the system can directly access these hidden partitions at startup without exposing the partition's specific information. This approach not only improves data security but also simplifies the complexity of partition management.

[0040] In some embodiments, when compiling the image file for each partition, the encryption attributes of the partition are read and used to determine whether the image of the partition should be encrypted, specifically including: When compiling the image file for each partition, the partition encryption attribute of that partition is detected; If the partition encryption attribute is enabled, then the image file of that partition will be encrypted.

[0041] It's important to note that when compiling the image file for each partition, the partition's encryption attribute is checked. If the partition encryption attribute is set to enabled, encryption is performed on the image file for that partition. This process ensures the security of partition data during storage and transmission, preventing unauthorized access and data leakage. Partition encryption attributes are a security mechanism that allows developers to choose whether to enable encryption based on the partition's content and use case. Encryption typically involves selecting an appropriate encryption algorithm, such as the AES Advanced Encryption Standard, and encrypting the data using a key. In this way, sensitive data can be better protected without affecting the normal operation of the system.

[0042] Specifically, the partition encryption attribute refers to the setting of whether partition data needs to be encrypted. When encryption is enabled, the system uses an encryption algorithm to encrypt the partition data. An encryption algorithm is a mathematical function used to convert data into a form that cannot be understood by unauthorized users. Common encryption algorithms include AES and DES data encryption standards. In this invention, AES is a commonly used encryption algorithm with high security and efficiency. The key is a parameter used in the encryption and decryption process, which determines the specific method of encrypting the data. When encryption is enabled, the system generates a key and uses this key to encrypt the partition data. The encryption process is usually completed during the compilation phase to ensure that the generated image file is encrypted during storage and transmission. The decryption process occurs when the device boots up; the system uses the same key to decrypt the encrypted data for normal use.

[0043] Preferably, some key steps can be further refined when processing partition encryption attributes. For example, during the compilation phase, the system first checks the encryption attributes of the partitions. If a partition's encryption attribute is found to be enabled, the system generates a key and uses this key to encrypt the partition data. This process can be automated through scripts, ensuring the accuracy and consistency of the encryption operation. When selecting an encryption algorithm, a suitable algorithm can be chosen based on the sensitivity of the partition data and performance requirements. For example, for highly sensitive data, AES-256, a highly secure encryption algorithm, can be selected. For scenarios with high performance requirements, AES-128 can be selected, which offers high encryption speed while maintaining security. Upon device startup, the system uses the same key to decrypt the encrypted data, ensuring data integrity and availability. Through these detailed processing steps, the system can ensure the security of partition data while meeting performance requirements in different scenarios.

[0044] In some embodiments, generating a full flashing image file based on the flashing configuration file and all firmware partitions includes: The flashing image creation tool is invoked to package all firmware partitions into a single full flashing image file according to the flashing configuration file.

[0045] It's important to note that generating a full flashing image involves using a flashing image creation tool to package all firmware partitions into a single full flashing image file based on the flashing configuration file. The flashing configuration file is parsed from a unified partition table and contains detailed information about all firmware partitions, such as partition size, offset address, and file path. The full flashing image file is a complete image used to flash the firmware to the embedded device's storage medium, ensuring that the device can correctly load and run all firmware partitions during the production phase. In this way, developers can ensure the accuracy and consistency of the flashing process, reducing errors caused by manual configuration.

[0046] Specifically, the flashing configuration file is parsed from a unified partition table, which records detailed information about each firmware partition. This information includes the partition size, offset address, file path, read / write attributes, and encryption attributes. The partition size determines the space occupied by each partition on the storage medium; the offset address specifies the starting position of the partition on the storage medium; the file path is the storage location of the partition data in the development environment; the read / write attributes define the access permissions of the partition; and the encryption attributes determine whether the partition data needs to be encrypted. The flashing image creation tool is an automated tool that, based on the information in the flashing configuration file, packages the data of all firmware partitions into a complete flashing full image file using a flashing packaging program. This process ensures the integrity and accuracy of the flashing full image file, enabling smooth production flashing.

[0047] Preferably, some key steps can be further refined during the generation of the full flashing image. For example, when parsing the unified partition table to generate the flashing configuration file, the system will carefully check the parameters of each partition to ensure the accuracy and completeness of all information. Then, the flashing image creation tool will read the data of each firmware partition one by one according to the information in the flashing configuration file and write this data into the full flashing image file according to the specified offset address. During the packaging process, the tool will perform verification and validation to ensure that the data of each partition is complete and error-free. In addition, if a partition has encryption enabled, the flashing image creation tool will encrypt the data of these partitions during the packaging process to ensure that the data in the full flashing image file is secure during storage and transmission. Through these detailed processing steps, the system can ensure that the generated full flashing image file meets the production flashing requirements of embedded devices, while improving the security and reliability of the system.

[0048] In some embodiments, generating a firmware upgrade package based on the upgrade configuration file and the partition table image to be upgraded includes: The upgrade image creation tool is invoked to package the partition image to be upgraded and the partition configuration information into a firmware upgrade package according to the upgrade configuration file.

[0049] It's important to note that generating a firmware upgrade package involves using an upgrade image creation tool to package the partition image to be upgraded along with its configuration information into a firmware upgrade package based on the upgrade configuration file. The upgrade configuration file is parsed from a unified partition table and contains detailed information about the partitions to be upgraded, such as partition offset address, partition size, and file path. The firmware upgrade package is a file used for device firmware updates, ensuring that the device can correctly load and apply the new firmware partitions during the upgrade process. In this way, developers can ensure the accuracy and consistency of the firmware upgrade process and reduce errors caused by manual configuration.

[0050] Specifically, the upgrade configuration file is parsed from a unified partition table, and it records detailed information about each partition that needs to be upgraded. This information includes the partition's offset address, size, file path, read / write attributes, and encryption attributes. The partition offset address specifies the starting position of the partition in the storage medium; the partition size determines the space occupied by each partition in the storage medium; the file path is the storage location of the partition data in the development environment; the read / write attributes define the access permissions of the partition; and the encryption attributes determine whether the partition data needs to be encrypted. The upgrade image creation tool is an automated tool that, based on the information in the upgrade configuration file, packages the partition images and partition configuration information to be upgraded into a complete firmware upgrade package using an upgrade packaging program. This process ensures the integrity and accuracy of the firmware upgrade package, enabling a smooth firmware update process.

[0051] Preferably, some key steps can be further refined during the firmware upgrade package generation process. For example, when parsing the unified partition table to generate the upgrade configuration file, the system will thoroughly check the parameters of each partition to ensure the accuracy and completeness of all information. Then, the upgrade image creation tool will read the image data of the partitions to be upgraded one by one according to the information in the upgrade configuration file, and write this data into the firmware upgrade package according to the specified offset address. During the packaging process, the tool will perform verification and validation to ensure that the data of each partition is complete and error-free. In addition, if a partition has encryption enabled, the upgrade image creation tool will encrypt the data of these partitions during the packaging process to ensure that the data in the firmware upgrade package is secure during storage and transmission. Through these detailed processing steps, the system can ensure that the generated firmware upgrade package can meet the firmware update requirements of embedded devices, while improving the security and reliability of the system.

[0052] In some embodiments, the method further includes S5: during the device startup phase, the embedded device loads the partition table file and loads partitions according to partition attributes.

[0053] Specifically, if the partition has encryption attributes, the decryption module is called to decrypt the partition; if the partition has read-only attributes, the partition is set to read-only access mode that prohibits writing.

[0054] It's important to note that during the device startup phase, the embedded system loads the partition table file and loads partitions based on their attributes. If a partition has encryption attributes, the decryption module is invoked to decrypt it; if the partition's read / write attributes are read-only, it is set to a read-only access mode with write restrictions. This process ensures that the device can correctly load and use each partition during startup, while protecting the security and integrity of the partition data. The partition table file is a configuration file used to identify and manage each partition during device startup. It contains information such as the partition's offset address, size, file path, read / write attributes, and encryption attributes. The decryption module is a dedicated software module for handling encrypted partitions. It uses the same key and algorithm as during encryption to decrypt the partition data, ensuring that the data can be correctly read during loading.

[0055] Specifically, the partition table file is generated by parsing from a unified partition table. It records detailed information such as the offset address, size, file path, read / write attributes, and encryption attributes of each partition. The offset address refers to the starting position of the partition in the storage medium; it is a physical address used to determine the partition's specific location within the storage medium. The partition size determines the space occupied by each partition in the storage medium. The file path is the storage location of the partition data in the development environment. Read / write attributes define the access permissions of the partition, such as read-only, read-write, or hidden. Encryption attributes determine whether the partition data needs to be encrypted. During device startup, the embedded system reads the partition table file and loads each partition according to its attributes. If a partition has encryption attributes, the system calls the decryption module, using the same key and algorithm as during encryption to decrypt the partition data. If a partition's read / write attribute is read-only, the system sets the partition to a read-only access mode to prevent write access and protect the partition data from modification.

[0056] Preferably, some key steps can be further refined during the device startup phase. For example, when loading the partition table file, the system first verifies the file's integrity and accuracy, ensuring all necessary information is present and correct. Then, the system loads each partition one by one according to the partition attributes in the partition table file. For partitions with encryption attributes, the system calls the decryption module, using the same key and algorithm as during encryption to decrypt the partition data. During decryption, the system performs real-time verification to ensure data integrity and accuracy. For partitions set to read-only attributes, the system sets them to a read-only access mode with write restrictions during loading to prevent unauthorized modification. Through these detailed processing steps, the system ensures that the device can correctly load and use each partition during startup, while protecting the security and integrity of the partition data.

[0057] like Figure 4 The firmware upgrade flowchart shown, in some embodiments, further includes the following steps: S6. During the firmware update phase, the upgrade program parses the upgrade configuration file in the firmware upgrade package and writes the partition image to be upgraded to the specified address of the storage medium according to the partition offset address in the configuration file.

[0058] It should be noted that during the firmware update phase, the upgrade program parses the upgrade configuration file in the firmware upgrade package and writes the partition images to be upgraded to the specified address on the storage medium according to the partition offset address in the configuration file. This process ensures the accuracy and reliability of the firmware update and avoids errors caused by manual operation. The firmware upgrade package is a file containing all the partition images and configuration information that need to be updated, and it plays a crucial role in the device's firmware update process. The upgrade configuration file records detailed information such as the offset address, size, and file path of each partition, which guides the upgrade program to correctly write the partition images to the specified location on the storage medium.

[0059] Specifically, the firmware upgrade package is generated by the upgrade image creation tool based on the upgrade configuration file. It contains images of all partitions that need to be upgraded and related configuration information. The upgrade configuration file is parsed from a unified partition table and records detailed information such as the offset address, size, file path, read / write attributes, and encryption attributes of each partition to be upgraded. The partition offset address refers to the starting position of the partition in the storage medium; it is a physical address used to determine the specific location of the partition in the storage medium. The partition size determines the space occupied by each partition in the storage medium. The file path is the storage location of the partition data in the development environment. Read / write attributes define the access permissions of the partition, such as read-only, read-write, or hidden. Encryption attributes determine whether the partition data needs to be encrypted. During the firmware update phase, the upgrade program reads the upgrade configuration file in the firmware upgrade package and writes the images of the partitions to be upgraded to the specified addresses in the storage medium according to the partition offset addresses within it.

[0060] Preferably, during the firmware update phase, some key steps can be further refined. For example, when parsing the upgrade configuration file in the firmware upgrade package, the upgrade program first verifies the integrity and accuracy of the file, ensuring that all necessary information exists and is correct. Then, based on the partition offset address in the upgrade configuration file, the upgrade program reads the partition image data to be upgraded one by one and writes this data to the designated address on the storage medium. During the writing process, the upgrade program performs real-time verification to ensure the integrity and accuracy of the data. In addition, if a partition has encryption enabled, the upgrade program decrypts the data in these partitions during the writing process to ensure that the data can be loaded correctly. Through these detailed processing steps, the system can ensure the accuracy and reliability of the firmware update process, while improving the system's security and stability.

[0061] In some embodiments, the unified partition table supports the addition of new partition scheme types, and the new partition scheme types generate partition table files of corresponding formats through scripts.

[0062] It should be noted that the unified partition table of this invention supports the addition of new partition scheme types. New partition scheme types generate corresponding partition table files via scripts. This means that the unified partition table is not only compatible with existing partition schemes but also can be flexibly extended with new partition scheme types via scripts. This extensibility allows the unified partition table to adapt to future new technologies and requirements, enhancing the system's flexibility and maintainability. The script is an automated tool used to generate corresponding partition table files based on the parameters of the new partition scheme, ensuring seamless integration of the new partition scheme into the existing system.

[0063] Specifically, the unified partition table is a configuration file that centrally manages all partition information. It supports various partition scheme types, such as GPT, DTB, and Bootloader hard-coded schemes. Adding a new partition scheme type refers to generating the required configuration file for a new partition scheme based on an existing one using a script. A script is an automation tool that generates a partition table file in a specific format based on input parameters. These parameters include partition scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type. Through scripts, developers can easily add new partition schemes without manually modifying the partition table file, thus reducing development and maintenance complexity.

[0064] Preferably, when expanding to include new partition scheme types, some key steps can be further refined. For example, developers can define new partition scheme types using scripts and input necessary parameters such as partition size, offset address, and file path. The script will generate the corresponding partition table file based on these parameters and integrate it into a unified partition table. During the generation process, the script will perform verification and validation to ensure the correctness of the parameters of the new partition scheme. Furthermore, the script can support the generation of multiple partition schemes. For example, for the GPT partition scheme, the script will generate a GPT partition file and package it into a separate partition image; for the DTB partition scheme, the script will generate a DTB file and write it to a unified DTB partition. Through these detailed processing steps, the system can ensure that new partition schemes can be seamlessly integrated into the existing system, while improving the system's flexibility and maintainability.

[0065] The above embodiments of the present invention have the following beneficial effects: 1. By using a unified partition table, compatibility with multiple partitioning schemes is achieved, which solves the problem that traditional embedded devices need to maintain multiple partitioning schemes due to hardware differences, reduces development complexity and maintenance costs, and supports flexible expansion to new partitioning types.

[0066] 2. The system automatically processes the read / write and encryption attributes of partitions during the compilation phase, ensuring the security of sensitive partition data. This solves the problems of scattered, easily overlooked, or conflicting partition attribute configurations in traditional solutions, thus improving the stability and security of the system.

[0067] 3. Based on a unified partition table, the system automatically generates a full flashing image and firmware upgrade package, ensuring consistency in partition configuration between production flashing and OTA upgrades. This avoids flashing errors or upgrade failures caused by the inconsistency of multiple partition description files in traditional methods, thereby improving production efficiency and upgrade reliability.

[0068] Furthermore, the storage medium in the embodiments of this application stores program instructions capable of implementing all the above methods. These program instructions can be stored in the storage medium in the form of a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, or terminal devices such as computers, servers, mobile phones, and tablets.

[0069] The above description is merely an explanation of some preferred embodiments of the present invention and the technical principles employed. Those skilled in the art should understand that the scope of the invention as described in the embodiments of the present invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of the present invention.

Claims

1. A partitioning method for a partition table in an embedded device, characterized in that, Includes the following steps: S1: During the development phase, the partitioning information required by the embedded device is deployed in a unified partitioning table, wherein the unified partitioning table is compatible with multiple partitioning table schemes; S2: During the compilation phase, the unified partition table is parsed based on the partition information to generate the partition table file, burning configuration file and upgrade configuration file required for the embedded device to boot; S3: During the image generation stage, a full image file for burning is generated based on the burning configuration file and all firmware partitions, and a firmware upgrade package is generated based on the upgrade configuration file and the partition table image to be upgraded. S4: During the production burning stage, the full image file is burned to the storage medium of the embedded device to complete the program burning.

2. The method according to claim 1, characterized in that, The partition information mentioned in step S1 includes any one or more of the following: Partition scheme type, storage media information, partition backup scheme type, partition file path, partition offset address, partition size, partition read / write attributes, partition encryption attributes, and partition file system type.

3. The method according to claim 2, characterized in that, Step S2, which involves parsing the unified partition table based on the partition information to generate the partition table file required for the embedded device to boot, includes: Generate a partition table file in the corresponding format based on the partition scheme type; If the partition scheme type is GPT partition table, then a GPT partition file is generated and packaged into a separate partition image; If the partition scheme type is DTB partition scheme, then a DTB file is generated and written to the unified DTB partition; If the partition scheme type is Bootloader hard-coded scheme, then MTD partition parameters are generated and written to the header file.

4. The method according to claim 2, characterized in that, The compilation phase also includes: during the parsing and generation of the partition table file, the read / write attributes of the partitions will be judged and processed; specifically including: When a partition's read / write attribute is hidden, writing the partition's information to the partition table file is prohibited, and the partition's offset address is hardcoded to a specified module, making the partition directly accessible via its physical address and invisible to the system.

5. The method according to claim 2, characterized in that, The compilation phase also includes: when compiling the image file for each partition, reading the encryption attributes of the partition and using this to determine whether to encrypt the image of the partition.

6. The method according to claim 1, characterized in that, Based on the burning configuration file and all firmware partitions, a full burning image file is generated, including: The flashing image creation tool is invoked to package all firmware partitions into a single full flashing image file according to the flashing configuration file.

7. The method according to claim 1, characterized in that, The firmware upgrade package generated based on the upgrade configuration file and the partition table image to be upgraded includes: The upgrade image creation tool is invoked to package the partition image to be upgraded and the partition configuration information into a firmware upgrade package according to the upgrade configuration file.

8. The method according to claim 1, characterized in that, It also includes the following steps: S5: During the device startup phase, the embedded device loads the partition table file and loads partitions according to the partition attributes.

9. The method according to claim 1, characterized in that, It also includes the following steps: S6: During the firmware update phase, the upgrade program parses the upgrade configuration file in the firmware upgrade package and writes the partition image to be upgraded to the specified address of the storage medium according to the partition offset address in the configuration file.

10. The method according to claim 8, characterized in that, The embedded device loads the partition table file and loads partitions according to partition attributes, including: If the partition has encryption attributes, the decryption module is called to decrypt the partition. If the partition's read / write attribute is read-only, then the partition is set to read-only access mode with write access prohibited.

Images