Vehicle-mounted communication terminal upgrading method and terminal

Abstract

The application relates to a vehicle-mounted communication terminal upgrading method and a terminal. After receiving an upgrading software package issued by a cloud, the method respectively burns the modem firmware images of different types of communication modules into mutually independent image partitions, and burns the matching partition resources into a plurality of mutually independent hardware resource partitions corresponding to the module types. In the system starting stage, the module type currently accessed is determined by reading the level signal of a hardware pin, and then the matching modem firmware image and partition resource are called to complete the adaptation and initialization of the corresponding communication module. In actual application, only one software package needs to be maintained and a plurality of drive firmwares corresponding to different types of communication modules and the matching resources are integrated in advance. By pushing a uniform upgrading software package, all vehicle-mounted communication terminals carrying different communication modules can be covered, the management and distribution process of the upgrading package is greatly simplified, and the cost and complexity of upgrading and maintenance are significantly reduced.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a method for upgrading an in-vehicle communication terminal and the terminal itself. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, in-vehicle communication terminals, as core devices for information interaction between vehicles and between vehicles and infrastructure, have been widely deployed in various types of vehicles. To meet the communication needs of different scenarios, in-vehicle communication terminals typically need to be compatible with multiple communication modules such as 4G and 5G to provide flexible network access capabilities. In practical applications, the software of in-vehicle communication terminals needs to be continuously upgraded according to the evolution of communication technologies or changes in functional requirements to ensure the reliability of communication performance and functions.

[0003] However, existing technologies for software upgrades to in-vehicle communication terminals typically employ a hardware-bound approach. Due to significant differences in hardware architecture between 4G and 5G communication modules, the required upgrade software packages must be compiled and adapted separately for each module. This means that during upgrades and maintenance, a dedicated software package corresponding to the specific communication module of each in-vehicle communication terminal must be precisely matched. This results in a massive workload for upgrades and maintenance, and the software packages cannot be reused between different modules, exhibiting extremely poor versatility and significantly increasing the cost and complexity of upgrades and maintenance. Summary of the Invention

[0004] Based on this, the purpose of this application is to provide a method and terminal for upgrading an in-vehicle communication terminal, which enables a single software package to be compatible with the upgrade requirements of different types of communication modules, thereby reducing upgrade and maintenance costs.

[0005] The vehicle-mounted communication terminal upgrade method described in this application embodiment is applied to a vehicle-mounted communication terminal, which includes a communication module; the method includes the following steps: Receive a pre-compiled upgrade package from the cloud; the upgrade package includes modem firmware images adapted to different types of communication modules and corresponding partition resources; The modem firmware images of different types of communication modules are burned to independent image partitions, and the corresponding partition resources are burned to hardware resource partitions that correspond one-to-one with the module type. After the vehicle-mounted communication terminal is powered on, the voltage signal data of the hardware identification pin of the communication module is collected; Based on the voltage signal data, determine the type information of the communication module; Based on the type information, the corresponding modem firmware image is read from the matching image partition. After the operating system of the vehicle communication terminal starts up, the matching hardware resource partition is mounted so that the operating system can read the partition resources in the hardware resource partition, adapt and initialize the communication module corresponding to the modem firmware image.

[0006] This application embodiment packages the firmware and resources required for multiple types of communication modules into a single upgrade software package. The terminal's local partition stores the corresponding operating resources for each type of module. The module model is automatically identified and the corresponding resources are loaded based on the hardware pin voltage. This breaks the binding relationship between the upgrade software package and a single communication module. One upgrade package can cover multiple communication module hardware, greatly improving the versatility of the upgrade software package. Specifically, when upgrading numerous vehicle communication terminals, only one universal upgrade software package needs to be distributed. The upgrade software package includes modem firmware images adapted to different types of communication modules and corresponding partition resources. After receiving the upgrade software package from the cloud, each vehicle communication terminal burns the modem firmware images of different types of communication modules to independent image partitions and burns the corresponding partition resources to several independent hardware resource partitions that correspond one-to-one with the module type. This enables the terminal to have the basic capability of being compatible with multiple hardware at the physical storage level and ensures the physical isolation and integrity of the software environments of different modules, avoiding file conflicts or overwrite errors during the upgrade process. Based on this, by immediately acquiring voltage signal data from the hardware identification pins of the communication module after the vehicle-mounted communication terminal is powered on, the type information of the currently accessed communication module can be quickly and accurately determined without relying on the operating system and application layer software. Based on this accurate identification of type information, the terminal can accurately read the corresponding modem firmware image from the matching image partition, thus avoiding boot failure caused by loading incorrect firmware. Subsequently, after the operating system boots up, it mounts the matching hardware resource partition according to the determined type information, enabling the operating system to directly read the partition resources within that specific partition to complete initialization. This application eliminates the strong binding relationship between software packages and specific hardware modules in the prior art. In actual upgrades, multiple communication firmwares corresponding to different types of modules can be pre-integrated into a single upgrade software package. Regardless of whether the terminal is equipped with a 4G or 5G module, it is not necessary to compile their own dedicated software packages separately, nor is it necessary to match specific software packages for each terminal individually; only the same upgrade software package containing multiple communication firmwares needs to be used. In practical applications, when a large number of vehicles equipped with different communication modules need to be upgraded with software, only one unified upgrade software package needs to be pushed. After the terminal is powered on, it can automatically determine its own module type and load the corresponding firmware by reading the hardware pin voltage signal. Thus, the upgrade of all vehicles can be completed without manual intervention and without maintaining multiple software packages. This greatly simplifies the OTA upgrade management process, reduces the complexity of interaction between the cloud and the vehicle, and significantly reduces the workload and cost of upgrade and maintenance.

[0007] In one embodiment, the vehicle-mounted communication terminal includes an analog-to-digital conversion sampling circuit; the analog-to-digital conversion sampling circuit is connected to the hardware identification pin of the communication module; The steps for acquiring voltage signal data from the hardware identification pin of the communication module include: The analog voltage of the hardware identification pin of the communication module is acquired by the analog-to-digital conversion sampling circuit, and the acquired analog voltage is converted into a digital signal to obtain the voltage signal data.

[0008] This embodiment incorporates an analog-to-digital conversion sampling circuit in the vehicle-mounted communication terminal, connecting it to the hardware identification pin of the communication module. Upon power-on, this circuit automatically acquires the analog voltage on the hardware identification pin and converts it into a digital signal, thus obtaining voltage signal data. Because an analog-to-digital conversion sampling circuit is used to convert analog voltage to digital signal, the voltage state of the hardware identification pin can be accurately represented by a digital value. This eliminates the need for the processor to perform additional software-level voltage reading and conversion operations, reducing processing overhead.

[0009] In one embodiment, the step of determining the type information of the communication module based on the voltage signal data includes: When the voltage signal data is within a preset voltage range corresponding to any communication module type, the type information of the communication module is determined to be that communication module type.

[0010] This embodiment compares the voltage signal data with the preset voltage range corresponding to each communication module type. When the voltage signal data falls within a preset voltage range, the type information of the communication module is determined to be that communication module type.

[0011] In one embodiment, the step of reading the corresponding modem firmware image from the matching image partition based on the type information includes: Based on the type information, locate the matching mirror partition in the local storage; The modem firmware image stored in the image partition is read into the memory of the vehicle communication terminal and loaded into the communication module for operation.

[0012] This embodiment, through dynamic positioning of the image partition based on type information, can automatically index to the firmware storage location that perfectly matches the current hardware without relying on manual intervention. Subsequently, the firmware image is read from the non-volatile image partition into high-speed memory and further loaded into the communication module for operation.

[0013] In one embodiment, the vehicle-mounted communication terminal has a built-in application processor and a modem mounted on the communication module. The vehicle-mounted communication terminal has a pre-stored device tree, and the device tree has a one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition. Based on the type information, before the step of reading the corresponding modem firmware image from the matching image partition, a modem loading pre-step is also performed: Read the modem startup parameters in the device tree to obtain the one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition, and establish a mirror partition addressing index accordingly; A cross-core dedicated communication interface is initialized between the application processor and the modem to establish a transmission channel between the application processor and the modem, so that the type information of the currently determined communication module is sent to the modem through the transmission channel; wherein, the modem configures the operating environment in response to the type information of the currently determined communication module, and provides dual-core instruction interaction support for performing the operation of reading the corresponding modem firmware image from the matching image partition.

[0014] This embodiment utilizes a device tree as a unified description carrier for hardware configuration, decoupling the addressing logic of the image partition from the hardware environment and enhancing the system's portability and configuration flexibility. The memory addressing index built based on the device tree transforms address lookup operations into an efficient table lookup process, significantly shortening the preparation time before firmware loading. More importantly, by pre-initializing the cross-core dedicated communication interface and sending type information to the modem, the modem can learn its own hardware identity in advance and configure its operating environment accordingly, providing a reliable underlying channel for accurate firmware image transmission.

[0015] In one embodiment, the step of acquiring voltage signal data of the hardware identification pin of the communication module after the vehicle-mounted communication terminal is powered on includes: When the vehicle-mounted communication terminal enters the pre-loading boot process, it collects the voltage signal data of the hardware identification pin of the communication module.

[0016] This embodiment sets the timing of voltage signal data acquisition when the vehicle-mounted communication terminal enters the pre-loading boot process, enabling the identification of the communication module type at the earliest stage before the operating system and various software modules are running. Since the acquisition occurs during the pre-loading boot process, it is unaffected by the operating system's startup progress and does not conflict with the loading and initialization process of the communication firmware, ensuring that the type information is accurately obtained before the communication firmware needs to be loaded.

[0017] In one embodiment, the step of mounting a matching hardware resource partition after the operating system of the vehicle-mounted communication terminal has started includes: Based on the type information, determine the matching hardware resource partition; Establish a mapping relationship between the hardware resource partition and the operating system's preset access directory, so that the operating system can read the partition resources stored in the hardware resource partition through the preset access directory.

[0018] This embodiment determines the matching hardware resource partition based on the type information, and then establishes a mapping relationship between this partition and the operating system's preset access directory. This enables the operating system to accurately access the dedicated partition resources that match the current communication module type. This allows the operating system to complete the initialization of the communication firmware based on the correct partition resources, ensuring that the communication function of the vehicle-mounted communication terminal operates normally according to the parameters matching the current module.

[0019] In one embodiment, after determining the type information of the communication module based on the voltage signal data, the method further includes: The type information is written to a designated storage partition for persistent storage, so that the vehicle communication terminal can retrieve the type information from the designated storage partition and perform a modem firmware image loading operation; after the operating system of the vehicle communication terminal has started, the operating system retrieves the type information from the designated storage partition again and performs a hardware resource partition mounting operation based on the retrieved type information.

[0020] This embodiment persistently stores the type information of the communication module in a designated storage partition after determination. This allows the vehicle-mounted communication terminal to read the type information from this partition during subsequent operations such as loading the modem firmware image and mounting the hardware resource partition. This provides a stable and reliable source of type information for the entire boot process. Because the type information is persistently stored, there is no need to re-identify the module type by collecting the hardware identification pin voltage signal after the terminal restarts. Instead, the saved type information is quickly read directly from the designated storage partition, allowing for accurate loading of the corresponding modem firmware image from the unified upgrade software package and mounting of the hardware resource partition matching the type information to the operating system.

[0021] This application also provides a vehicle-mounted communication terminal, including a processor, a memory, and a computer-readable program stored in the memory. When executed by the processor, the computer-readable program implements the steps of the method described in any one of the embodiments of this application.

[0022] To better understand and implement this application, the following detailed description is provided in conjunction with the accompanying drawings. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the vehicle-mounted communication terminal upgrade method according to an embodiment of this application; Figure 2This is a schematic diagram of the structure of the vehicle-mounted communication terminal according to an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. Wherein, when the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements.

[0025] It should be understood that the embodiments described below do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0026] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application are also intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, in the description of this application, unless otherwise stated, “a plurality” means two or more. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items, for example, A and / or B, which can represent: A alone, A and B together, and B alone; the character “ / ” generally indicates that the preceding and following objects are in an “or” relationship.

[0027] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, this information should not be limited to these terms, and these terms are only used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Depending on the context, the word "if" as used in this application can be interpreted as "when," "when," or "in response to determination."

[0028] With the rapid development of vehicle-to-everything (V2X) technology, in-vehicle communication terminals, as core devices for information interaction between vehicles and between vehicles and infrastructure, have been widely deployed in various types of vehicles. To meet the communication needs of different scenarios, in-vehicle communication terminals typically need to be compatible with multiple communication modules such as 4G and 5G to provide flexible network access capabilities. In practical applications, the software of in-vehicle communication terminals needs to be continuously upgraded according to the evolution of communication technologies or changes in functional requirements to ensure the reliability of communication performance and functions.

[0029] However, existing technologies for software upgrades to in-vehicle communication terminals typically employ a hardware-bound approach. Due to significant differences in hardware architecture between 4G and 5G communication modules, the required upgrade software packages must be compiled and adapted separately for each module. This means that during upgrades and maintenance, a dedicated software package corresponding to the specific communication module of each in-vehicle communication terminal must be precisely matched. This results in a massive workload for upgrades and maintenance, and the software packages cannot be reused between different modules, exhibiting extremely poor versatility and significantly increasing the cost and complexity of upgrades and maintenance.

[0030] In response, this application provides a method for upgrading a vehicle-mounted communication terminal. By utilizing the characteristic that different types of communication modules have distinguishable hardware identification pins, the voltage signal of the pin is actively collected when the vehicle-mounted communication terminal is powered on. The type of the currently installed communication module is automatically identified through the voltage signal data, and then the communication firmware matching the type is automatically loaded and run from the upgrade software package, so that the operating system can adaptively complete the adaptation and initialization.

[0031] Please refer to Figure 1 The vehicle-mounted communication terminal upgrade method described in this application embodiment is applied to a vehicle-mounted communication terminal, which includes a communication module; the method includes the following steps: S101: Receive a pre-compiled upgrade package sent from the cloud; the upgrade package includes modem firmware images adapted to different types of communication modules and corresponding partition resources; S102: Burn the modem firmware images of different types of communication modules to independent image partitions, and burn the corresponding partition resources to the hardware resource partitions that correspond one-to-one with the module type. S103: After the vehicle-mounted communication terminal is powered on, the voltage signal data of the hardware identification pin of the communication module is collected; S104: Determine the type information of the communication module based on the voltage signal data; S105: Based on the type information, read the corresponding modem firmware image from the matching image partition. After the operating system of the vehicle communication terminal starts up, mount the matching hardware resource partition so that the operating system can read the partition resources in the hardware resource partition, adapt and initialize the communication module corresponding to the modem firmware image.

[0032] This application embodiment packages the firmware and resources required for multiple types of communication modules into a single upgrade software package. The terminal's local partition stores the corresponding operating resources for each type of module. The module model is automatically identified and the corresponding resources are loaded based on the hardware pin voltage. This breaks the binding relationship between the upgrade software package and a single communication module. One upgrade package can cover multiple communication module hardware, greatly improving the versatility of the upgrade software package. Specifically, when upgrading numerous vehicle communication terminals, only one universal upgrade software package needs to be distributed. The upgrade software package includes modem firmware images adapted to different types of communication modules and corresponding partition resources. After receiving the upgrade software package from the cloud, each vehicle communication terminal burns the modem firmware images of different types of communication modules to independent image partitions and burns the corresponding partition resources to several independent hardware resource partitions that correspond one-to-one with the module type. This enables the terminal to have the basic capability of being compatible with multiple hardware at the physical storage level and ensures the physical isolation and integrity of the software environments of different modules, avoiding file conflicts or overwrite errors during the upgrade process. Based on this, by immediately acquiring voltage signal data from the hardware identification pins of the communication module after the vehicle-mounted communication terminal is powered on, the type information of the currently accessed communication module can be quickly and accurately determined without relying on the operating system and application layer software. Based on this accurate identification of type information, the terminal can accurately read the corresponding modem firmware image from the matching image partition, thus avoiding boot failure caused by loading incorrect firmware. Subsequently, after the operating system boots up, it mounts the matching hardware resource partition according to the determined type information, enabling the operating system to directly read the partition resources within that specific partition to complete initialization. This application eliminates the strong binding relationship between software packages and specific hardware modules in the prior art. In actual upgrades, multiple communication firmwares corresponding to different types of modules can be pre-integrated into a single upgrade software package. Regardless of whether the terminal is equipped with a 4G or 5G module, it is not necessary to compile their own dedicated software packages separately, nor is it necessary to match specific software packages for each terminal individually; only the same upgrade software package containing multiple communication firmwares needs to be used. In practical applications, when a large number of vehicles equipped with different communication modules need to be upgraded with software, only one unified upgrade software package needs to be pushed. After the terminal is powered on, it can automatically determine its own module type and load the corresponding firmware by reading the hardware pin voltage signal. Thus, the upgrade of all vehicles can be completed without manual intervention and without maintaining multiple software packages. This greatly simplifies the OTA upgrade management process, reduces the complexity of interaction between the cloud and the vehicle, and significantly reduces the workload and cost of upgrade and maintenance.

[0033] The following provides a detailed explanation of each step.

[0034] Step S101: Receive the pre-compiled upgrade package sent from the cloud; the upgrade package includes modem firmware images adapted to different types of communication modules and corresponding partition resources.

[0035] The upgrade package refers to a comprehensive software image file that is uniformly compiled, packaged, and distributed by a cloud server. This file employs a structured encapsulation, containing modem firmware images adapted to various types of communication modules (such as 4G, 5G, or modules from different manufacturers), along with corresponding partition resources. This package breaks the traditional limitation of single hardware adaptation, enabling a single upgrade file to cover vehicle terminals with multiple hardware configurations.

[0036] The cloud refers to a remote server deployed on the Internet. In this embodiment, all in-vehicle communication terminals are centrally managed through the server, including operations such as sending upgrade software packages and pushing configuration commands to the in-vehicle communication terminals.

[0037] In this step, the vehicle-mounted communication terminal receives a pre-compiled upgrade package from the cloud server via a remote wireless communication link. This upgrade package has already undergone compatibility adaptation for different communication modules (such as 4G and 5G modules) during the cloud-based construction phase. It internally encapsulates modem firmware images and corresponding partition resources adapted to different types of communication modules. For example, the upgrade package includes not only 5G modem firmware for Qualcomm platforms but also 4G modem firmware for Unisoc platforms, and each firmware comes with corresponding RF calibration parameters and network configuration files. The receiving process typically occurs within the operating system environment of the vehicle-mounted communication terminal. The terminal downloads the package from the cloud via HTTP or MQTT protocols and performs integrity checks such as CRC checks or digital signature verification to ensure accurate data transmission.

[0038] Step S102: Burn the modem firmware images of different types of communication modules to independent image partitions, and burn the corresponding partition resources to the hardware resource partitions that correspond one-to-one with the module type.

[0039] The vehicle-mounted communication terminal unpacks the verified upgrade package and, based on a predefined storage mapping relationship, burns the modem firmware images of different types of communication modules to independent image partitions. Simultaneously, it burns the corresponding partition resources to hardware resource partitions that correspond one-to-one with the module type. Specifically, the terminal's upgrade program parses the header information of the upgrade package, identifying the various firmware images and resource files contained within. Then, according to the image-partition mapping table, the upgrade program writes the firmware image of the 5G module to the image partition identified as "Modem_Image_5G" and the firmware image of the 4G module to the image partition identified as "Modem_Image_4G". At the same time, the upgrade program writes the RF calibration parameters (NV item) and IMEI information specific to the 5G module to the hardware resource partition identified as "Modem_Res_5G" and the corresponding resources for the 4G module to the hardware resource partition identified as "Modem_Res_4G". This writing process typically uses an overwrite burning method to ensure that each partition stores the latest version of the software resources. After the programming is complete, the terminal will usually set a restart flag and wait for the next power-on to start.

[0040] For step S103, after the vehicle-mounted communication terminal is powered on, the voltage signal data of the hardware identification pin of the communication module is collected.

[0041] The vehicle-mounted communication terminal (TBOX) is an electronic device installed in a vehicle to enable data communication between the vehicle and external networks. It is also known as a TBOX and is the core hardware unit responsible for network access and data transmission in the vehicle networking system.

[0042] A communication module is a hardware module in an in-vehicle communication terminal that is responsible for performing specific wireless communication functions, such as a 4G communication module or a 5G communication module. Different types of communication modules differ in hardware architecture and communication protocols.

[0043] The hardware identification pin is a physical pin on the communication module used to characterize its own type. Different types of communication modules output different voltage signals on the hardware identification pin, so the module type can be distinguished by reading the voltage value of the pin.

[0044] Voltage signal data is obtained by acquiring voltage values ​​or voltage status information through the hardware identification pins. This data can reflect the type characteristics of the current communication module.

[0045] This step involves actively acquiring voltage signals from the hardware identification pins of the communication module after the vehicle-mounted communication terminal powers on. Specifically, after completing its own initialization, the main control chip or processor of the vehicle-mounted communication terminal reads the voltage value of the hardware identification pins on the communication module via GPIO pins or an ADC analog-to-digital converter interface. For example, when the communication module is a 4G module, its hardware identification pin may be pulled high to 3.3V or pulled low to 0V; when the communication module is a 5G module, its hardware identification pin may output a different voltage value, such as 1.8V. By reading the voltage value of this pin and converting it into a digital signal, the voltage signal data is obtained. The acquisition can be performed after power-on, before the operating system is fully loaded, or during the loading process to ensure that the module type is known before the communication firmware is loaded.

[0046] In one embodiment, step S103, after the vehicle-mounted communication terminal is powered on, involves collecting voltage signal data from the hardware identification pin of the communication module, including: Step S1031: When the vehicle-mounted communication terminal enters the pre-loading guidance process, the voltage signal data of the hardware identification pin of the communication module is collected.

[0047] The pre-loading boot process is an initialization boot process that the vehicle communication terminal undergoes after power-on and before the formal operating system is loaded and run; it is also known as the bootloader stage. In this process, the underlying bootloader of the vehicle communication terminal detects and configures key hardware, preparing for the normal loading of the subsequent operating system. In this embodiment, the pre-loading boot process is the underlying startup boot stage executed by the bootloader after the vehicle communication terminal powers on, specifically corresponding to the Preloader / LK bootloader BL2 execution stage in the embedded boot architecture. The BL2 stage runs first after the entire device powers on and the basic chip resets, undertaking core hardware initialization, system resource configuration, device tree resolution, and secondary boot jump functions; it belongs to the pre-low-level runtime environment before the application processor kernel runs the operating system. In this embodiment, after the vehicle-mounted communication terminal is powered on, it executes the boot programs at each level sequentially. Upon entering the BL2 stage, it first completes the overall initialization configuration of the system architecture (arch) and hardware platform (platform). This includes the hardware function initialization and register configuration of the power management chip (PMIC), analog-to-digital converter (ADC), and general-purpose flash memory (UFS), as well as the parsing and construction of the device tree (FDT). After the hardware resources are initialized, the application initialization module (app_init) completes the scheduling initialization of the underlying components, and the program jumps to the blxboot core execution flow. This solution triggers the voltage signal acquisition operation of the communication module hardware identification pins within the blxboot core flow, automatically identifying different types of communication modules. This provides a basis for subsequent targeted reading of the corresponding modem firmware image and mounting of the operating system to match the hardware resource partitions.

[0048] This embodiment, by timing the acquisition of voltage signal data when the vehicle-mounted communication terminal enters the pre-loading boot process, enables the identification of the communication module type at the earliest stage before the operating system and various software modules are running. Since the acquisition occurs within the pre-loading boot process, it is unaffected by the operating system's startup progress and does not conflict with the loading and initialization of the communication firmware, ensuring that the type information is accurately obtained before the communication firmware needs to be loaded. Furthermore, utilizing the existing hardware detection mechanism within the pre-loading boot process itself to acquire voltage signals makes the entire startup process more compact and orderly.

[0049] In one embodiment, the vehicle-mounted communication terminal includes an analog-to-digital conversion sampling circuit; the analog-to-digital conversion sampling circuit is connected to the hardware identification pin of the communication module; Step S103, which involves acquiring the voltage signal data of the hardware identification pin of the communication module, includes: Step S1032: The analog voltage of the hardware identification pin of the communication module is acquired through the analog-to-digital conversion sampling circuit, and the acquired analog voltage is converted into a digital signal to obtain the voltage signal data.

[0050] The analog-to-digital conversion sampling circuit is a hardware circuit in the vehicle communication terminal used to convert analog electrical signals into digital signals. It usually consists of an analog-to-digital converter and an external sampling circuit. It can sample the continuously changing analog voltage output on the hardware identification pin of the communication module and quantize it into a digital value that can be recognized and processed by the processor.

[0051] This embodiment incorporates an analog-to-digital conversion sampling circuit in the vehicle-mounted communication terminal, connecting it to the hardware identification pin of the communication module. Upon power-on, this circuit automatically acquires the analog voltage on the hardware identification pin and converts it into a digital signal, thus obtaining voltage signal data. Because an analog-to-digital conversion sampling circuit is used to convert analog voltage to digital signal, the voltage state of the hardware identification pin can be accurately represented by a digital value. This eliminates the need for the processor to perform additional software-level voltage reading and conversion operations, reducing processing overhead.

[0052] For step S104, the type information of the communication module is determined based on the voltage signal data.

[0053] Type information is information determined based on voltage signal data and used to identify the specific category of the communication module, such as identifying the module as a 4G module or a 5G module.

[0054] This step determines the communication module type information based on the collected voltage signal data. Specifically, the vehicle-mounted communication terminal pre-stores a mapping table between voltage values ​​or voltage ranges and module types. For example, a voltage value of 3.3V~3.5V corresponds to a 4G module, and a voltage value of 1.8V~2.0V corresponds to a 5G module. The collected voltage signal data is compared with this mapping table to determine the specific type of the current communication module, thus obtaining the type information. In one feasible implementation, multiple hardware identification pins can be set. Different voltage combinations of these pins can distinguish more types of communication modules. In this case, the mapping table stores the correspondence between voltage combinations and module types, and the type information is determined based on the combination of multiple voltage signal data.

[0055] In one embodiment, step S104, which involves determining the type information of the communication module based on the voltage signal data, includes: Step S1041: When the voltage signal data is within a preset voltage range corresponding to any communication module type, the type information of the communication module is determined to be that communication module type.

[0056] The preset voltage range is a range of voltage values ​​that is pre-defined for each type of communication module to identify its type. This range is defined by the lower voltage limit and the upper voltage limit. Different types of communication modules correspond to different preset voltage ranges, and the ranges do not overlap with each other to ensure that the module type can be uniquely determined by voltage signal data.

[0057] This embodiment compares voltage signal data with preset voltage ranges corresponding to each communication module type. When the voltage signal data falls within a preset voltage range, the communication module type is determined to be that type. Since different types of communication modules correspond to different and non-overlapping preset voltage ranges, the specific type of the current communication module can be accurately identified based on the collected voltage signal data.

[0058] In one embodiment, step S1041, when the voltage signal data is within a preset voltage range corresponding to any communication module type, determines that the type information of the communication module is that type of communication module, including: Step S10411: When the voltage signal data is within the preset voltage range corresponding to the 4G communication module, the type information of the communication module is determined to be a 4G communication module. Step S10412: When the voltage signal data is within the preset voltage range corresponding to the 5G communication module, the type information of the communication module is determined to be a 5G communication module.

[0059] In this embodiment, the 4G communication module and the 5G communication module are respectively set with non-overlapping preset voltage ranges. After collecting voltage signal data, it is determined whether the data falls within the corresponding preset voltage range, thereby determining whether the communication module is a 4G communication module or a 5G communication module.

[0060] In one embodiment, after step S104, which determines the type information of the communication module based on the voltage signal data, the method further includes: Step S1042: The type information is written to a designated storage partition for persistent storage, so that the vehicle communication terminal can retrieve the type information from the designated storage partition and perform a modem firmware image loading operation; after the operating system of the vehicle communication terminal has started, the operating system retrieves the type information from the designated storage partition again and performs a hardware resource partition mounting operation according to the retrieved type information.

[0061] The designated storage partition is a pre-allocated dedicated storage area within the vehicle-mounted communication terminal's storage space, used for persistently storing communication module type information. This area has the characteristic of not losing information even after power failure, ensuring that the type information can still be correctly read after the terminal restarts. In one feasible implementation, the designated storage partition can be a non-volatile storage area to ensure that the type information remains valid after multiple restarts.

[0062] This embodiment persistently stores the type information of the communication module in a designated storage partition after determination. When the vehicle-mounted communication terminal subsequently loads the modem firmware image and mounts the hardware resource partition, it reads the type information from this partition, providing a stable and reliable source of type information for the entire boot process. Because the type information is persistently stored, after a terminal restart, there is no need to re-identify the module type by collecting the hardware identification pin voltage signal. Instead, the saved type information is quickly read directly from the designated storage partition, accurately loading the corresponding modem firmware image from the unified upgrade software package and mounting the hardware resource partition matching the type information to the operating system. This approach not only simplifies the boot process after a restart and improves boot efficiency but also ensures the consistency and accuracy of the type information in multiple restart scenarios. This allows the operating system to complete the loading of the modem firmware image and the mounting of the hardware resource partition based on the correct type information each time, ensuring that the communication function of the vehicle-mounted communication terminal always operates normally in a manner matching the current communication module.

[0063] For step S105, according to the type information, the corresponding modem firmware image is read from the matching image partition. After the operating system of the vehicle communication terminal starts up, the matching hardware resource partition is mounted so that the operating system reads the partition resources in the hardware resource partition, adapts and initializes the communication module corresponding to the modem firmware image.

[0064] A mirror partition refers to a logically partitioned, independent storage area within the local non-volatile storage medium of an in-vehicle communication terminal, used to store modem firmware images. Each mirror partition corresponds to a specific type of communication module and has an independent file system or raw data format. The physical or logical addresses of the partitions are isolated from each other to prevent different versions of firmware from overwriting or tampering with each other.

[0065] Modem firmware image refers to the low-level control program file running on the communication module processor, which includes radio frequency control logic, protocol stack and driver, and is the core software carrier for the communication module to realize data transmission and reception functions.

[0066] A hardware resource partition refers to an independent storage area within the local storage medium, separate from the image partition, used to store auxiliary data related to the communication module. This partition primarily stores hardware-dependent configuration parameters, including but not limited to RF calibration parameters (NV items), IMEI identification information, network access point (APN) configuration files, and operator-customized policy scripts. Unlike the firmware image, data within the hardware resource partition typically allows for updates or rewriting during device operation.

[0067] Partition resources are parameter information used to guide the operating system in initializing the communication firmware, such as driver parameters, communication protocol parameters, and frequency configurations. In this embodiment, partition resources are a set of auxiliary data required for the normal operation of the communication module, excluding the core firmware, including but not limited to Access Point (APN) configuration files, International Mobile Equipment Identity (IMEI) certificates, RF calibration parameter tables, and configuration scripts specific to certain operators. Different types of communication modules correspond to different partition resources to ensure that the operating system can complete the initialization of the communication firmware in a manner compatible with the current module.

[0068] Mounting is the process by which an operating system associates a storage partition with its own file system. Once mounted, the operating system can access the files and data within that partition and initialize and configure the relevant hardware based on its contents.

[0069] The operating system is the main system software running on the vehicle-mounted communication terminal. It is responsible for managing the terminal's various resources and coordinating the work of various hardware modules. The communication module controlled by the communication firmware can only be used normally after the loaded communication firmware has been adapted and initialized.

[0070] In this step, the vehicle-mounted communication terminal dynamically loads software resources based on the determined type information. First, the bootloader indexes the global partition table in local storage based on the type information to locate the image partition storing the corresponding modem firmware image. Since different image partitions store firmware adapted to different types of communication modules, the type information can be used as an index key to accurately read data from the corresponding independent image partition. For example, if the type information is "5G_Modem_B", the bootloader skips the image partition storing 4G firmware and directly accesses the starting address storing the 5G firmware image, loading the modem firmware image into the communication module's random access memory (RAM) for execution. After the vehicle-mounted communication terminal's main operating system completes kernel startup, it mounts the matching hardware resource partition based on the same type information. This hardware resource partition stores the partition resources corresponding to this type of communication module. The operating system accesses this mount point to read the RF calibration parameters and network configuration files stored in the partition, and uses these resources to configure and initialize the previously loaded modem firmware image. Ultimately, the communication module establishes the radio frequency link in the appropriate software environment, enabling normal communication functions.

[0071] In one embodiment, step S105, which involves reading the corresponding modem firmware image from the matching image partition based on the type information, includes: Step S1051: Locate the matching mirror partition in the local storage based on the type information.

[0072] Specifically, the bootloader queries a partition mapping table pre-stored in a specified storage partition or embedded in the bootloader. This table records the correspondence between type information and image partition identifiers (such as partition names or starting addresses). For example, when the type information is "5G_Modem_B", the partition mapping table indicates that the corresponding image partition is " / dev / mmcblk0p12".

[0073] Step S1052: Read the modem firmware image stored in the image partition and store it in the memory of the vehicle communication terminal, and load it into the communication module for operation.

[0074] In this step, the bootloader, based on the location result, reads the modem firmware image stored in the image partition and stores it in the memory of the vehicle communication terminal. This reading process typically involves file system parsing or raw data copying. The bootloader loads the firmware image completely into the reserved address space in memory. After the firmware image is loaded, the bootloader transmits the firmware image through the communication interface and loads it into the internal running memory of the communication module for execution. For example, for a 5G module, the bootloader writes the 5G firmware image in memory into the module's RAM through a high-speed serial interface and triggers the module's reset signal, causing the communication module to start executing the firmware code, thereby completing the startup of the modem firmware image. After the operating system of the vehicle communication terminal has started, it mounts the matching hardware resource partition according to the type information, reads the partition resources to configure and initialize the running firmware, and finally establishes a stable communication connection.

[0075] This embodiment achieves precise positioning and efficient loading of firmware resources at the underlying stage of system startup. By dynamically locating the image partition based on type information, it can automatically index the firmware storage location that perfectly matches the current hardware without manual intervention. Subsequently, the firmware image is read from the non-volatile image partition into high-speed memory and further loaded into the communication module for operation. This phased, on-demand loading mechanism, combined with the preceding unified cloud distribution and local multi-partition storage architecture, enables the vehicle communication terminal to quickly adapt to and start various types of communication modules with extremely low computing power overhead. This significantly improves the system's cold start performance and operational stability in multi-hardware environments, providing underlying technical support for the immediate response of vehicle networking services.

[0076] In one embodiment, the vehicle-mounted communication terminal has a built-in application processor and a modem mounted on the communication module. The vehicle-mounted communication terminal has a pre-stored device tree, and the device tree has a one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition.

[0077] An application processor (AP) is the central processing unit on the main circuit board of an in-vehicle communication terminal. It typically runs a complex operating system such as Linux or Android and is responsible for handling in-vehicle infotainment, navigation, vehicle networking application logic, and the system management of the entire terminal.

[0078] A modem is a dedicated processing unit integrated within a communication module. It typically has an independent microcontroller (MCU) or digital signal processor (DSP) and is specifically responsible for parsing the underlying communication protocol, processing radio frequency signals, and transmitting and receiving wireless data.

[0079] A device tree is a data structure used to describe hardware devices, typically stored in binary form (DTB) in a bootloader-accessible memory area. In embedded Linux systems, the device tree is independent of the kernel code and is used to pass hardware configuration information (such as CPU address, memory layout, peripheral register addresses, and interrupt numbers) to the operating system kernel, enabling the same kernel code to adapt to different hardware platforms. In this scheme, device tree nodes are used to carry the mapping relationship between communication module type information and image partition storage addresses.

[0080] A cross-core dedicated communication interface refers to a physical or logical data channel used to connect the application processor (AP) inside the vehicle communication terminal with the modem in the communication module. The mainstream implementation is shared memory; however, low-speed channels such as Serial Peripheral Interface (SPI), Secure Digital Input / Output Interface (SDIO), and Internal Integrated Circuit Bus (I2C) can also be used as auxiliary control links. This interface achieves low-latency, high-reliability data transmission between heterogeneous multi-core processors through a specific communication protocol.

[0081] Before step S105, which reads the corresponding modem firmware image from the matching image partition based on the type information, a modem loading pre-step is also performed: Step S1053: Read the modem startup parameters in the device tree to obtain the one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition, and establish a mirror partition addressing index accordingly.

[0082] The bootloader reads the device tree pre-stored in the local storage medium. This device tree not only contains traditional hardware description information but also extends it with a one-to-one mapping between the type information of each communication module and the storage address of each mirror partition. For example, the device tree defines the attribute "modem_5g_type=
" corresponding to "partition_addr=<0x12345678>". The bootloader parses the device tree nodes, extracts the mapping relationship, and builds a mirror partition addressing index table in memory accordingly. This index table serves as a fast lookup basis, allowing the physical storage address to be directly calculated from the type information in subsequent steps without having to parse the entire device tree each time, thus improving addressing efficiency.

[0083] Step S1054: Initialize the cross-core dedicated communication interface between the application processor and the modem to establish a transmission channel between the application processor and the modem, so that the type information of the currently determined communication module is sent to the modem through the transmission channel; wherein, the modem responds to the type information of the currently determined communication module to configure the operating environment, and provides dual-core instruction interaction support for performing the operation of reading the corresponding modem firmware image from the matching image partition.

[0084] The transmission channel refers to the logical link with data transmission and reception capabilities formed after the cross-core dedicated communication interface completes its initial configuration. This channel provides a standardized data exchange path between the application processor and the modem, ensuring that both parties can transmit instructions and data based on an agreed protocol format.

[0085] The currently determined communication module type information specifically refers to the data obtained in real time during the power-on startup phase of the vehicle communication terminal. This data is obtained by collecting and analyzing the voltage signal data of the hardware identification pins, reflecting the type of the currently connected communication module. This information differs from the pre-stored default configuration, possessing the highest real-time performance and accuracy, and is the sole basis for software resource matching during this startup cycle.

[0086] The bootloader initializes the cross-core dedicated communication interface between the application processor and the modem. Specifically, the system configures the physical layer communication bus (such as the SPI bus), sets the baud rate, data width, and clock polarity, and establishes a data buffer for cross-core communication on the application processor side. After initialization, this interface establishes a bidirectional transmission channel between the application processor and the modem for transmitting commands and data. Subsequently, the bootloader sends the communication module type information, determined by a hardware identification pin, to the modem through this cross-core dedicated communication interface. Upon receiving this type information, the modem configures its own operating environment in response, such as configuring the internal cache size, initializing specific hardware accelerators, or setting the expected firmware loading address. This step provides the necessary dual-core instruction interaction support for subsequent operations of reading the corresponding modem firmware image from the matching image partition, ensuring timing synchronization and logical coordination between the application processor and the modem in firmware loading.

[0087] This embodiment significantly improves the startup coordination and resource management efficiency of the vehicle communication terminal under a heterogeneous multi-core architecture by pre-setting the mapping relationship between type information and storage address in the device tree and establishing a dual-core interaction mechanism using a cross-core dedicated communication interface. Specifically, by using the device tree as a unified description carrier for hardware configuration, the addressing logic of the image partition is decoupled from the hardware environment, enhancing the system's portability and configuration flexibility. The memory addressing index established based on the device tree transforms the address lookup operation into an efficient table lookup process, greatly shortening the preparation time before firmware loading. More importantly, by pre-initializing the cross-core dedicated communication interface and sending the type information to the modem, the modem can know its own hardware identity in advance and configure the operating environment accordingly, providing a reliable underlying channel for the accurate transmission of the firmware image.

[0088] In one embodiment, step S105, which involves mounting a matching hardware resource partition after the operating system of the vehicle-mounted communication terminal has started, includes: Step S10551: Determine the matching hardware resource partition based on the type information.

[0089] Step S10552: Establish a mapping relationship between the hardware resource partition and the operating system's preset access directory, so that the operating system can read the partition resources stored in the hardware resource partition through the preset access directory.

[0090] The default access directory is a target path or folder pre-defined in the operating system's file system for mounting external storage partitions. The operating system can indirectly read data from the mounted hardware resource partitions by accessing this directory.

[0091] Mapping is an association record maintained internally by the operating system. It is used to bind the physical storage address of a hardware resource partition to a preset access directory in the operating system's file system, so that the operating system can automatically locate the corresponding hardware resource partition when accessing the directory.

[0092] This embodiment determines the matching hardware resource partition based on the type information, and then establishes a mapping relationship between this partition and the operating system's preset access directory. This enables the operating system to accurately access the dedicated partition resources that match the current communication module type. This allows the operating system to complete the initialization of the communication firmware based on the correct partition resources, ensuring that the communication function of the vehicle-mounted communication terminal operates normally according to the parameters matching the current module.

[0093] Please refer to Figure 2This application also provides a vehicle-mounted communication terminal 301, including: a processor 302, a memory 303, and a computer program 304 stored in the memory 303 and executable on the processor 302. When the processor 302 executes the computer program 304, it implements the steps of the method as described in any one of the embodiments of this application.

[0094] The processor 302 may include one or more processing cores. The processor 302 connects to various parts within the vehicle communication terminal 301 via various interfaces and lines. It executes various functions and processes data of the vehicle communication terminal 301 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 303, and by calling data from the memory 303. Optionally, the processor 302 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 302 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required to be displayed on the touch screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 302 and may be implemented as a separate chip.

[0095] The memory 303 may include random access memory (RAM) or read-only memory. Optionally, the memory 303 may include a non-transitory computer-readable storage medium. The memory 303 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 303 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch instructions), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data involved in the various method embodiments described above, etc. Optionally, the memory 303 may also be at least one storage device located remotely from the aforementioned processor 302.

[0096] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of the method described in any one of the embodiments of this application. That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The computer program may include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The aforementioned storage medium includes: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in computer-readable media may be appropriately added to or subtracted from the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, computer-readable media may not include electrical carrier signals and telecommunication signals, in accordance with legislation and patent practice.

[0097] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of this application, and this application also intends to include these modifications and variations.

Claims

1. A method for upgrading a vehicle-mounted communication terminal, characterized in that, The method is applied to an in-vehicle communication terminal, wherein the in-vehicle communication terminal includes a communication module; the method includes the following steps: Receive a pre-compiled upgrade package from the cloud; the upgrade package includes modem firmware images adapted to different types of communication modules and corresponding partition resources; The modem firmware images of different types of communication modules are burned to independent image partitions, and the corresponding partition resources are burned to hardware resource partitions that correspond one-to-one with the module type. After the vehicle-mounted communication terminal is powered on, the voltage signal data of the hardware identification pin of the communication module is collected; Based on the voltage signal data, determine the type information of the communication module; Based on the type information, the corresponding modem firmware image is read from the matching image partition. After the operating system of the vehicle communication terminal starts up, the matching hardware resource partition is mounted so that the operating system can read the partition resources in the hardware resource partition, adapt and initialize the communication module corresponding to the modem firmware image.

2. The vehicle-mounted communication terminal upgrade method according to claim 1, characterized in that, The vehicle-mounted communication terminal includes an analog-to-digital conversion sampling circuit; the analog-to-digital conversion sampling circuit is connected to the hardware identification pin of the communication module. The steps for acquiring voltage signal data from the hardware identification pin of the communication module include: The analog voltage of the hardware identification pin of the communication module is acquired by the analog-to-digital conversion sampling circuit, and the acquired analog voltage is converted into a digital signal to obtain the voltage signal data.

3. The vehicle-mounted communication terminal upgrade method according to claim 1, characterized in that, The step of determining the type information of the communication module based on the voltage signal data includes: When the voltage signal data is within a preset voltage range corresponding to any communication module type, the type information of the communication module is determined to be that communication module type.

4. The vehicle-mounted communication terminal upgrade method according to claim 1, characterized in that, The step of reading the corresponding modem firmware image from the matching image partition based on the type information includes: Based on the type information, locate the matching mirror partition in the local storage; The modem firmware image stored in the image partition is read into the memory of the vehicle communication terminal and loaded into the communication module for operation.

5. The vehicle-mounted communication terminal upgrade method according to claim 1, characterized in that, The vehicle-mounted communication terminal has a built-in application processor and a modem mounted on the communication module. The vehicle-mounted communication terminal has a pre-stored device tree, and the device tree has a one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition. Based on the type information, before the step of reading the corresponding modem firmware image from the matching image partition, a modem loading pre-step is also performed: Read the modem startup parameters in the device tree to obtain the one-to-one mapping relationship between the type information of each communication module and the storage address of each mirror partition, and establish a mirror partition addressing index accordingly; A cross-core dedicated communication interface is initialized between the application processor and the modem to establish a transmission channel between the application processor and the modem, so that the type information of the currently determined communication module is sent to the modem through the transmission channel; wherein, the modem configures the operating environment in response to the type information of the currently determined communication module, and provides dual-core instruction interaction support for performing the operation of reading the corresponding modem firmware image from the matching image partition.

6. The vehicle-mounted communication terminal upgrade method according to claim 1, characterized in that, The step of collecting voltage signal data of the hardware identification pin of the communication module after the vehicle-mounted communication terminal is powered on includes: When the vehicle-mounted communication terminal enters the pre-loading boot process, it collects the voltage signal data of the hardware identification pin of the communication module.

7. The vehicle-mounted communication terminal upgrade method according to any one of claims 1 to 6, characterized in that, The steps for mounting the matching hardware resource partition after the operating system of the vehicle communication terminal has started include: Based on the type information, determine the matching hardware resource partition; Establish a mapping relationship between the hardware resource partition and the operating system's preset access directory, so that the operating system can read the partition resources stored in the hardware resource partition through the preset access directory.

8. The vehicle-mounted communication terminal upgrade method according to any one of claims 1 to 6, characterized in that, After determining the type information of the communication module based on the voltage signal data, the method further includes: The type information is written to a designated storage partition for persistent storage, so that the vehicle communication terminal can retrieve the type information from the designated storage partition and perform a modem firmware image loading operation; after the operating system of the vehicle communication terminal has started, the operating system retrieves the type information from the designated storage partition again and performs a hardware resource partition mounting operation based on the retrieved type information.

9. A vehicle-mounted communication terminal, characterized in that, The method includes a processor, a memory, and a computer-readable program stored in the memory, which, when executed by the processor, implements the steps of the method as described in any one of claims 1 to 8.

Images