Baseband firmware updating method and system based on offline boot loader and medium

Abstract

The invention discloses a baseband firmware updating method and system based on an off-line boot loader and a medium. Relates to the technical field of firmware updating. The upper computer performs serial port communication with the boot read-only memory of the baseband chip, and stores the boot loader data packet and the boot loader authentication ID in the baseband chip; the baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key and the boot loader data packet together; the boot read-only memory generates a second security key, and loads and executes a boot loader after the first security key is successfully matched with the second security key; according to the scheme, under the condition that storage of the boot loader is not solidified, communication is carried out through the high-speed SPI in the running process of the boot read-only memory based on the upper computer software and the baseband chip, so that the boot loader is transmitted into the baseband chip and is loaded and run, and updating of the baseband firmware is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware updating, and in particular to a baseband firmware updating method, system and medium based on an offline boot loader. Background Art

[0002] BootROM (Boot Read-Only Memory) is an unmodifiable code stored within an embedded chip. It assists in the initialization and boot process after the device is powered on. Its main functions include: hardware initialization (clock configuration, memory controller, and basic peripheral initialization); program detection and loading (detecting and selecting the next program to load from storage media such as Flash and SD cards); and a bootloader (boot loader), a small program in an embedded system responsible for initializing the hardware environment and loading the baseband chip firmware. Its core functions include: running the first step after the device is powered on, verifying and jumping to the legitimate firmware; receiving the new firmware through the communication interface, erasing and writing the storage media; and performing firmware integrity verification and identity authentication.

[0003] There are two traditional methods for updating baseband chip firmware: one is to download the Bootloader online to the baseband chip's RAM via JTAG, and then run the Bootloader to update the firmware; the other is to execute the BootROM after the baseband chip is powered on, load the Bootloader from the storage medium through the BootROM, and update the baseband chip online through the Bootloader program.

[0004] Traditional baseband chip firmware update methods have the following limitations: While downloading the bootloader online via JTAG shortens download times, its use is very limited. It's generally only useful for single-board debugging when JTAG pins are exposed, making full system debugging virtually impossible. While loading the bootloader stored in Flash via BootROM is simple and widely applicable, it requires the bootloader to be pre-burned to storage media. This method is difficult to implement without a pre-burned bootloader. Summary of the Invention

[0005] The technical problem to be solved by the present invention is that the traditional baseband chip firmware update method has the disadvantages of difficult whole-machine debugging, high operational complexity, and the requirement of pre-burning a boot loader to a storage medium. In view of the limitations of the traditional baseband chip firmware update, the present invention aims to provide a baseband firmware update method, system and medium based on an offline boot loader. When the boot loader is not solidified and stored, the host computer software communicates with the boot read-only memory of the baseband chip through a high-speed SPI port during operation, thereby transferring the boot loader to the baseband chip and loading it for operation, thereby realizing the update of the baseband firmware.

[0006] The present invention is achieved through the following technical solutions: This solution provides a baseband firmware update method based on an offline bootloader, including: The host computer communicates with the boot ROM of the baseband chip through a serial port, and stores the boot loader data packet and the boot loader authentication ID in the baseband chip; The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; The host computer generates a second security key based on the boot loader authentication ID and sends the second security key to the boot ROM. The boot ROM loads and executes the boot loader after the first security key successfully matches the second security key.

[0007] A further optimization scheme is that the host computer communicates with the boot read-only memory of the baseband chip through a serial port, and stores the boot loader program data packet and the boot loader program authentication ID in the baseband chip; including the method: H1, the baseband chip waits for the handshake signal sent by the host computer; H2, determine whether the waiting time of the baseband chip has timed out. If so, the baseband chip reads the backup firmware valid identifier in the storage space and loads the firmware according to the backup firmware valid identifier; otherwise, the baseband chip generates an authentication ID for the boot loader and sends it to the host computer, and then enters step H3; H3, the host computer uploads the boot loader program data packet to the baseband chip through the high-speed SPI serial port; the baseband chip parses the boot loader program data packet and stores the parsed boot loader program data packet and the boot loader program authentication ID in the designated memory.

[0008] A further optimization solution is to perform data frame verification before the baseband chip parses the boot loader data packet: The integrity check is performed on the frame header and frame footer of the boot loader data packet. If the integrity check passes, the baseband chip parses the boot loader data packet; if the integrity check fails, the baseband chip returns a data frame failure data packet to the host computer.

[0009] A further optimization solution is to perform packet reception verification after the baseband chip parses the boot loader data packet: Determine whether the bootloader program data packet is received. If so, the baseband chip returns a data frame success data packet to the host computer; otherwise, the baseband chip returns a data frame completion data packet to the host computer.

[0010] A further optimized solution is that the method for generating the first security key or the second security key includes: Obtaining policy information based on the boot loader authentication ID; the policy information includes: compilation date and program size length; After preprocessing the policy information, a policy ID is calculated; the policy ID includes an algorithm combination y consisting of n encryption algorithms; the host computer and the baseband chip store m encryption algorithms; where n ≥ 2, m ≥ n; Based on the policy ID, the corresponding algorithm combination is loaded and the program authentication ID is used as a seed to generate the first security key or the second security key.

[0011] A further optimized solution is that the method for matching the first security key with the second security key includes: calculating the policy ID after preprocessing the policy information, including the method: Based on the policy information, we construct the compilation date vector S=[S0,S1,S2,S3,S4,S5] and the program size vector W=[W0,W1, W2, W3, W4, W5]; where S0=year / 100; S1=year%100; S2=month; S3=day; S4=week; sum = (S1+S2+S3); S5=sum%10; W0=length / 1000; W1=length%1000; W2=length / 100; W3=length%100; W4=length / 10; W5=length%10; length represents the program size; The strategy ID is calculated based on the following formula: Policy ID=(S*W)% 4=(S0*W0+S1*W1+ S2*W2+S3*W3+ S4*W4+S5*W5)%4.

[0012] A further optimized solution is that the loading and executing the boot loader includes the following method: Guide the read-only memory to request the host computer to update the data packet; The host computer uploads the update data package to the boot ROM; After the update packet is successfully received, the boot ROM executes the boot loader according to the type and content of the update packet.

[0013] A further optimized solution is that the boot read-only memory executes the boot loader according to the type and content of the update data packet, including the method: Get the type of update data packet; For the control data packet, first decrypt the baud rate information and write it into the partition type wrflashtype. Then, based on the baud rate information, change the working baud rate of the high-speed SPI serial port in real time, and store the decrypted data according to the partition type wrflashtype. For the firmware data packet, it is first decrypted, and then the decrypted data is placed in the designated memory of the baseband chip according to the CurPage page number and PageBytes page byte number.

[0014] This solution also provides a baseband firmware update system based on an offline boot loader, which is used to implement the above-mentioned baseband firmware update method based on an offline boot loader; the system includes: a host computer, a boot read-only memory and a baseband chip; The host computer is used to communicate with the boot read-only memory of the baseband chip through a serial port, and store the boot loader program data packet and the boot loader program authentication ID in the baseband chip; The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; The host computer generates a second security key based on the boot loader authentication ID and sends the second security key to the boot read-only memory; The present solution also provides a computer-readable medium having a computer program stored thereon. The computer program is executed by a processor to implement the above-mentioned baseband firmware update method based on the offline boot loader.

[0015] Compared with the prior art, the present invention has the following advantages and beneficial effects: 1. The present invention provides a baseband firmware update method, system, and medium based on an offline boot loader. When the boot loader is not permanently stored, the host computer software communicates with the boot read-only memory of the baseband chip through a high-speed SPI port during operation, thereby transferring the boot loader to the baseband chip and loading it for operation, thereby achieving the update of the baseband firmware.

[0016] 2. The present invention provides a method, system, and medium for updating baseband firmware based on an offline boot loader. This method uses a high-speed SPI serial port for upgrades, adding integrity checking and adaptive SPI serial port baud rate dynamic adjustment functions to the traditional XMODEM protocol. The traditional XMODEM protocol relies on a fixed baud rate. If the baud rate does not match or environmental interference causes signal instability, it will lead to frequent transmission failures. This solution can solve hardware compatibility issues and adapt to the performance differences of different SPI interfaces. In scenarios with severe electromagnetic interference, the speed can be automatically reduced to improve transmission stability. In ideal environments, the speed can be automatically increased to shorten the firmware update time and achieve dynamic updates of the baseband firmware. 3. The present invention provides a baseband firmware update method, system, and medium based on an offline boot loader; the boot loader and the boot read-only memory implement bidirectional encryption authentication based on the chip's unique ID to block supply chain attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the following briefly introduces the drawings required for use in the examples. It should be understood that the following drawings only illustrate certain embodiments of the present invention and should not be considered as limiting the scope. A person of ordinary skill in the art can also derive other relevant drawings based on these drawings without inventive effort. In the drawings: Figure 1 Schematic diagram of the baseband firmware update method based on offline boot loader; Figure 2 This is a schematic diagram of the communication process between the host computer and the baseband chip; Figure 3 Flowchart for loading and executing the bootloader. DETAILED DESCRIPTION

[0018] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with examples and drawings. The exemplary embodiments of the present invention and their descriptions are only used to explain the present invention and are not intended to limit the present invention.

[0019] Baseband firmware updates have low storage efficiency (the Bootloader itself occupies storage space), high operational complexity (manual JTAG connection and pre-burning of the Bootloader are required), slow upgrade time, poor environmental adaptability (dependence on JTAG), insufficient defense (the solidified Bootloader is vulnerable to physical extraction and reverse engineering attacks), the Bootloader cannot update itself, and the risk of bricking is high. In view of this, this solution provides the following embodiments to solve the above technical problems.

[0020] Example 1 This embodiment provides a baseband firmware update method based on an offline boot loader, such as Figure 1 Shown, including: Step 1: The host computer communicates with the boot ROM of the baseband chip through a serial port, and stores the boot loader program data packet and the boot loader program authentication ID in the baseband chip; this step specifically includes the following method: H1, the baseband chip waits for the handshake signal sent by the host computer; H2: Determine whether the waiting time of the baseband chip has timed out. If so, the baseband chip reads the backup firmware valid identifier in the storage space and loads the firmware according to the backup firmware valid identifier; otherwise, the baseband chip generates an authentication ID for the boot loader and sends it to the host computer, and then proceeds to step H3; H 3, the host computer uploads the boot loader program data packet to the baseband chip through the high-speed SPI serial port; the baseband chip parses the boot loader program data packet and stores the parsed boot loader program data packet and the boot loader program authentication ID in the designated memory.

[0021] In step 1, before the baseband chip parses the bootloader data packet, it also performs data frame verification: The integrity check is performed on the frame header and frame footer of the boot loader data packet. If the integrity check passes, the baseband chip parses the boot loader data packet; if the integrity check fails, the baseband chip returns a data frame failure data packet to the host computer.

[0022] After the baseband chip parses the bootloader data packet, it also performs data packet reception verification: Determine whether the bootloader program data packet is received. If so, the baseband chip returns a data frame success data packet to the host computer; otherwise, the baseband chip returns a data frame completion data packet to the host computer.

[0023] Step 2: The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; In this step, a further optimized solution is that the method for generating the first security key or the second security key includes: Obtaining policy information based on the boot loader authentication ID; the policy information includes: compilation date and program size length; After preprocessing the policy information, a policy ID is calculated; the policy ID includes an algorithm combination y consisting of n encryption algorithms; the host computer and the baseband chip store m encryption algorithms; where n ≥ 2, m ≥ n; Based on the policy ID, the corresponding algorithm combination is loaded and the program authentication ID is used as a seed to generate the first security key or the second security key.

[0024] A further optimized solution is that the method for matching the first security key with the second security key includes: calculating the policy ID after preprocessing the policy information, including the method: Based on the policy information, construct the compilation date vector S=[S0, S1, S2, S3, S4, S5] and the program size vector W=[W0, W1, W2, W3, W4, W5]; where S0=year / 100; S1=year%100; S2=month; S3=day; S4=week; sum= (S1+S2+S3); S5=sum%10; W0=length / 1000; W1=length%1000; W2=length / 100; W3=length%100; W4=length / 10; W5=length%10; length represents the program size; The strategy ID is calculated based on the following formula: Policy ID=(S*W)% 4=(S0*W0+S1*W1+ S2*W2+S3*W3+ S4*W4+S5*W5)%4.

[0025] Step 3: The host computer generates a second security key based on the boot loader authentication ID and sends it to the boot ROM. The boot ROM loads and executes the boot loader after the first security key successfully matches the second security key.

[0026] The method of loading and executing the boot loader includes: Guide the read-only memory to request the host computer to update the data packet; The host computer uploads the update data package to the boot ROM; After the update packet is successfully received, the boot ROM executes the boot loader according to the type and content of the update packet.

[0027] The boot read-only memory executes a boot loader according to the type and content of the update data packet, including a method: Get the type of update data packet; For the control data packet, first decrypt the baud rate information and write it into the partition type wrflashtype. Then, based on the baud rate information, change the working baud rate of the high-speed SPI serial port in real time, and store the decrypted data according to the partition type wrflashtype. For the firmware data packet, it is first decrypted, and then the decrypted data is placed in the designated memory of the baseband chip according to the CurPage page number and PageBytes page byte number.

[0028] Specifically, CurPage indicates that the current page number starts at 0 and increases incrementally. PageBytes indicates the number of bytes in the current page content. For the firmware package, the PageBytes size is fixed at 1024 bytes. The designated memory start address of the baseband chip is 0x00800000. The write address of each page of data is calculated by the formula targetadr = 0x00800000 + CurPage * PageBytes.

[0029] Example 2 This embodiment provides a baseband firmware update system based on an offline boot loader, which is used to implement the baseband firmware update method based on an offline boot loader described in Example 1; the system includes: a host computer, a boot read-only memory, and a baseband chip; The host computer is used to communicate with the boot read-only memory of the baseband chip through a serial port, and store the boot loader program data packet and the boot loader program authentication ID in the baseband chip; The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; The host computer generates a second security key based on the boot loader authentication ID and sends the second security key to the boot read-only memory; Example 3 This embodiment provides a computer-readable medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the baseband firmware update method based on the offline boot loader as described in Example 1; Figure 1 and Figure 2 As shown, perform the following steps: Step S1: The baseband chip waits for the handshake signal sent by the host computer through the high-speed SPI serial port, and then goes to step S1.1; Step S1.1: The baseband chip determines whether the handshake signal waiting timeout has occurred (the handshake signal timeout waiting timeout is 50-500ms); if not, go to step S1.3; otherwise, go to step S1.2; Step S1.2: Read the firmware valid identifier in the memory A / B, and load the baseband firmware in the memory according to the valid identifier; Go to step S1.3: the baseband chip determines whether it has received the correct handshake signal; if it has received the correct handshake signal, go to step S1.4; if it has not received the handshake signal, go to step S1.1; Step S1.4: The baseband chip sends the chip authentication ID to the host computer software, and then goes to step S1.5; Step S1.5: The baseband chip receives the data packet from the host computer via the SPI high-speed serial port, and then goes to step S1.6; Step S1.6: The baseband chip determines whether the data frame passes the integrity check (including the integrity of the frame header and frame footer and the correctness of the frame check). If so, the process proceeds to step S1.8; if not, the process proceeds to step S1.7. Step S1.7: The baseband chip returns a data packet indicating a failure to receive the data frame (including a header error, a tail error, a checksum error, etc.) to the host computer, and then goes to step S1.5. Step S1.8: The baseband chip parses the Bootloader data packet uploaded by the host computer, stores the parsed Bootloader data packet into the designated memory, and then goes to step S1.9; Step S1.9: The baseband chip determines whether the Bootloader data packet has been received. If so, the process goes to step S1.11; if not, the process goes to step S1.10. Step S1.10: The baseband chip returns a data packet indicating successful data frame reception to the host computer, and then goes to step S1.5; Step S1.11: The baseband chip returns the received data frame completion data packet to the host computer, and then goes to step S1.12; Step S1.12: The baseband chip uses the chip authentication ID to generate a key and stores it in the designated memory location RAMsec for bootloader program authentication. Then, go to step S1.13. Step S1.13: Load and execute the Bootloader program in the memory, and then go to step S2; Step S2: After the Bootloader program is loaded successfully, read the key written by the BootROM in the specified memory location RAMsec and go to step S2.1; Step S2.1: Verify the correctness of the key written into the BootROM. If correct, go to step S2.3; otherwise, go to step S2.2; Step S2.2: The baseband chip returns a message to the host computer indicating that the data key verification failed. Step S2.3: The baseband chip sends a Bootloader loading success data frame to the host computer, and then goes to step S2.4; Step S2.4: The baseband chip receives the update data packet from the host computer via the SPI high-speed serial port, and then goes to step S2.5; Step S2.5: Determine whether the update data packet passes the data frame integrity check (including the integrity check of the frame header and frame footer and the correctness of the frame check). If so, go to step S2.7; if not, go to step S2.6; Step S2.6: Return the data packet indicating the failure to receive the data frame (including frame header error, frame tail error, checksum error, data decryption verification error, etc.) to the host computer and go to step S2.4; Step S2.7: Extract the FramType field in the data frame of the update data packet and determine whether the FramType field is firmware data. If so, go to step S2.10; if not, go to step S2.8; Step S2.8: Parse the baud rate information in the data packet to change the current SPI serial port working baud rate, and extract the write partition type wrflashtype; then go to step S2.9; Step S2.9: Return the data packet indicating successful data frame reception to the host computer and go to step S2.4; Step S2.10: Decrypt the data frame content of the update data packet, and then go to step S2.11; Step S2.11: Determine whether the decryption verification is successful. If successful, go to step S2.12; if not, go to step S2.6; Step S2.12: Determine whether all firmware data has been received. If so, go to step S2.13; if not, go to step S2.9; Step S2.13: Return the data packet indicating that all the receiver firmware data frames have been received to the host computer, and go to step S2.14; Step S2.14: Write the received baseband firmware data packet to partition A or partition B in the memory according to wrflashtype; go to S2.15; in this step, after the firmware writing of partition A or partition B is completed, write the firmware valid identifier firmvalid to the specified location in the memory (here the first 4k of the storage device is selected as the location for firmware valid identification and verification); one of partitions A or B is used as a spare storage area.

[0030] Step S2.15: Clear the Bootloader in the memory, read the firmware program valid flag in the memory, and load the firmware program according to the flag; This solution dynamically loads an offline bootloader through a high-speed SPI serial port and combines hardware-level security features to achieve secure updates of baseband firmware: the bootloader is not permanently stored; during updates, it is loaded into memory and executed through the high-speed SPI serial port, freeing up Flash resources. The improved XMODEM protocol supports encrypted transmission and breakpoint resume; it also supports dynamic baud rate configuration to increase transmission speed. The traditional XMODEM protocol frame format is compared with the improved frame format as follows: Traditional XMODEM frame format: SOH + Block Num + Block Num inverse + Data (128B to 1024B) + CRC16 (2B) checksum; Improved XMODEM frame format: ENH (0xEB + 0x90 + SOH) + FramType + TotalPage (4B) + CurPage (4B) + PageBytes (2B) + IV (12B) + Data (0B to 1024B) + CRC32 (4B) checksum + ECC (4B) + END (0xED + 0x03) Among them, SOH represents the start of frame; Block Num represents the block number (1 byte, 0x00~0xFF); Block Num inverse represents the complement of the block number, which is used for error detection; CRC16 represents the 16-bit cyclic redundancy check code; ENH represents the enhanced frame header identifier (0xEB+0x90+SOH); FramType represents the data frame type of this transmission (control data or firmware data); TotalPage represents the total number of pages of data transmitted this time; CurPage represents the current page number of data transmitted this time; PageBytes represents the number of bytes of data transmitted this time; IV represents the initialization vector, which is used for algorithm encryption; Data represents the data block; CRC32 represents the 32-bit cyclic redundancy check code; ECC represents the error correction code; END represents the end of the data frame identifier.

[0031] This solution uses high-speed SPI serial communication between the host computer and the BootROM to transfer the Bootloader to the internal RAM of the baseband chip during runtime, without burning it to a storage medium (such as Flash / SD card). It breaks through the traditional method's reliance on pre-stored Bootloaders and supports direct upgrades of "blank chips." It embeds a lightweight signature verification engine + chip unique ID in the BootROM to achieve two-way encryption verification with the Bootloader, building an end-to-end trust chain and blocking supply chain attacks. It also implements identity authentication and integrity verification during dynamic loading. It improves the XMODEM protocol to add frame headers, frame tails, and frame checksums to enhance the reliability of the protocol. It supports encrypted transmission and breakpoint resumption. It also supports dynamic baud rate configuration to increase transmission speed (1kbps~50Mbps). The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A baseband firmware update method based on an offline boot loader, characterized in that: include: The host computer communicates with the boot ROM of the baseband chip through a serial port, and stores the boot loader data packet and the boot loader authentication ID in the baseband chip; The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; The host computer generates a second security key based on the boot loader authentication ID and sends the second security key to the boot ROM. The boot ROM loads and executes the boot loader after the first security key successfully matches the second security key.

2. The baseband firmware update method based on offline boot loader according to claim 1, characterized in that: The host computer communicates with the boot read-only memory of the baseband chip through a serial port, and stores the boot loader program data packet and the boot loader program authentication ID in the baseband chip; Includes methods: H1, the baseband chip waits for the handshake signal sent by the host computer; H2, determine whether the waiting time of the baseband chip has timed out. If so, the baseband chip reads the backup firmware valid identifier in the storage space and loads the firmware according to the backup firmware valid identifier; otherwise, the baseband chip generates an authentication ID for the boot loader and sends it to the host computer, and then enters step H3; H3, the host computer uploads the boot loader program data packet to the baseband chip through the high-speed SPI serial port; the baseband chip parses the boot loader program data packet and stores the parsed boot loader program data packet and the boot loader program authentication ID in the designated memory.

3. The baseband firmware update method based on offline boot loader according to claim 2, characterized in that: Before the baseband chip parses the bootloader data packet, it also performs data frame verification: The integrity check is performed on the frame header and frame footer of the boot loader data packet. If the integrity check passes, the baseband chip parses the boot loader data packet; if the integrity check fails, the baseband chip returns a data frame failure data packet to the host computer.

4. The baseband firmware update method based on offline boot loader according to claim 2, characterized in that: After the baseband chip parses the bootloader data packet, it also performs data packet reception verification: Determine whether the bootloader program data packet is received. If so, the baseband chip returns a data frame success data packet to the host computer; otherwise, the baseband chip returns a data frame completion data packet to the host computer.

5. The baseband firmware update method based on offline boot loader according to claim 1, characterized in that: The method for generating the first security key or the second security key includes: Obtaining policy information based on the boot loader authentication ID; the policy information includes: compilation date and program size length; After preprocessing the policy information, a policy ID is calculated; the policy ID includes an algorithm combination y consisting of n encryption algorithms; the host computer and the baseband chip store m encryption algorithms; where n ≥ 2, m ≥ n; Based on the policy ID, the corresponding algorithm combination is loaded and the program authentication ID is used as a seed to generate the first security key or the second security key.

6. The baseband firmware update method based on offline boot loader according to claim 5, characterized in that: The strategy ID is calculated after pre-processing the strategy information, including the following method: Based on the policy information, construct the compilation date vector S=[S0, S1, S2, S3, S4, S5] and the program size vector W=[W0, W1, W2, W3, W4, W5]; where S0=year / 100; S1=year%100; S2=month; S3=day; S4=week; sum =(S1+S2+S3); S5=sum%10; W0=length / 1000; W1=length%1000; W2=length / 100; W3=length%100; W4=length / 10; W5=length%10; length represents the program size; The strategy ID is calculated based on the following formula: Policy ID=(S*W)% 4=(S0*W0+S1*W1+ S2*W2+S3*W3+ S4*W4+S5*W5)%4.

7. The baseband firmware update method based on offline boot loader according to claim 2, characterized in that: The method of loading and executing the boot loader includes: Guide the read-only memory to request the host computer to update the data packet; The host computer uploads the update data package to the boot ROM; After the update packet is successfully received, the boot ROM executes the boot loader according to the type and content of the update packet.

8. The baseband firmware update method based on offline boot loader according to claim 7, characterized in that: The boot read-only memory executes a boot loader according to the type and content of the update data packet, including a method: Get the type of update data packet; For the control data packet, first decrypt the baud rate information and write it into the partition type wrflashtype. Then, based on the baud rate information, change the working baud rate of the high-speed SPI serial port in real time, and store the decrypted data according to the partition type wrflashtype. For the firmware data packet, it is first decrypted, and then the decrypted data is placed in the designated memory of the baseband chip according to the CurPage page number and PageBytes page byte number.

9. A baseband firmware update system based on an offline boot loader, characterized in that: Used to implement the baseband firmware update method based on the offline boot loader according to any one of claims 1 to 8; the system includes: a host computer, a boot read-only memory and a baseband chip; The host computer is used to communicate with the boot read-only memory of the baseband chip through a serial port, and store the boot loader program data packet and the boot loader program authentication ID in the baseband chip; The baseband chip generates a first security key based on the boot loader authentication ID, and stores the first security key together with the boot loader data packet; The host computer generates a second security key based on the boot loader authentication ID and sends the second security key to the boot read-only memory; The boot ROM loads and executes a boot loader after the first security key successfully matches the second security key.

10. A computer-readable medium having a computer program stored thereon, characterized in that: The computer program is executed by a processor to implement the baseband firmware update method based on an offline boot loader according to any one of claims 1 to 7.

Images