Multi-hardware adaptation method based on Linux

[0017] The following will be combined with figure 1 to the attached Figure 4 The present invention will be further described, but it should not limit the protection scope of the present invention. For the convenience of description and understanding of the technical solutions of the present invention, the following descriptions are based on the accompanying drawings.

[0018] like figure 1 As shown, in the Bootloader stage, the in-vehicle entertainment SOC processor of the in-vehicle entertainment system can obtain the hardware information of the in-vehicle MCU processor, and the parameters in the kernel can be modified according to different hardware information to achieve the function of dynamically adapting the hardware. The in-vehicle entertainment SOC processor communicates with the in-vehicle MCU processor through IPCL in the Bootloader stage, obtains the hardware information of different models of the in-vehicle MCU processor, modifies the device tree FDT according to different models in the Bootloader stage, and finally drives the Linux Kernel. Set different hardware parameters to achieve dynamic hardware adaptation, the used car entertainment SOC processor chip is MTK MT2712, the car MCU processor is RenesasRH850, and LK is used as the Bootloader program. After the hardware information is loaded, use the relevant functions to dynamically modify the corresponding device tree node in the device tree FDT file before loading the Linux Kernel.

[0019] In order to obtain hardware information efficiently and stably in the in-vehicle entertainment SOC processor, the SPI rate of IPCL communication is set to 1MHz, and a fixed transmission frame format is used here. As the basic unit of data exchange, there are three types of IPCL frame formats: data frame Data Frame, acknowledgment frame (non-reply) ACK/NACK Frame and invalid frame Dummy Frame, where Data Frame: used to encapsulate IPCL message, this frame adopts the design idea of ​​"lumped frame", which can encapsulate multiple messages in one frame Inside, to improve communication efficiency, the maximum length of Data Frame is 550 bytes, FrameLen occupies 2 bytes, CS occupies 2 bytes, and a Data Frame can store up to 550-2-2=546 bytes of payload. If the Data Frame only encapsulates If a message is sent, the maximum length of the message is 546 bytes. Dummy Frame: When MT2712 and RH850 exchange data, if MT2712 or RH850 has no IPCL message to send, you can use Dummy Frame to complete data transmission, and the receiver can discard the Dummy Frame. , ACK/NACK Frame: MT2712 or RH850 will send ACK Frame in the ACK_SM state to notify the other party that the last data exchange was successful, if the data exchange was successful, a valid DataFrame or Dummy Frame was received. Before Linux starts, enter the Bootloader program, which is used to initialize and load the on-board chip and guide the Linux operating system. The Bootloader program obtains the configuration items in the on-board MCU processor through the IPCL communication protocol of SPI.

[0020] In the Bootloader stage, the in-vehicle entertainment SOC processor communicates with the in-vehicle MCU processor through the IPCL communication protocol to obtain the hardware information saved in the in-vehicle MCU processor, such as Figure 4As shown, after the first communication is established, the in-vehicle entertainment SOC processor sends a data frame Data Frame to the in-vehicle MCU processor, requesting the in-vehicle MCU processor to send hardware information, and if the in-vehicle MCU processor does not have data to be sent, it will send an invalid frame. Dummy Frame, if the in-vehicle entertainment SOC processor and the in-vehicle MCU processor reply with the response frame ACK Frame, indicating that the data has been successfully sent and received, the in-vehicle MCU processor starts to send the hardware data, and the in-vehicle entertainment SOC processor sends the invalid frame Dummy while receiving the data. Frame, the data is parsed after receiving. A complete communication process is over. Finally, the response frame ACK Frame is sent at the same time to indicate that the data transmission and reception have been completed. At this point, a complete communication to obtain hardware information has been completed, and the device tree is added to the dts file. Node information, device tree node information corresponds to the board-level information obtained from the IPCL communication protocol information from the on-board MCU processor, and then the device tree FDT file is modified according to the obtained board-level information, and the corresponding device tree node of the device tree FDT is modified. After the parameters, let the Linux Kernel load different hardware parameters in the driver according to the different information of the nodes in the device tree dtb file, so as to complete the Linux multi-hardware adaptation method. The configuration items include different on-board MCU processors. Software version information, camera model, lcd type and audio information. For different models and the same model, the high, middle and low configurations are different, and the hardware they carry is also different. Under the condition that the drivers are all perfect, in the Bootloader stage in-vehicle entertainment SOC processor The way to communicate with the on-board MCU processor is an IPCL communication protocol based on SPI, which is used to obtain the hardware information saved in the on-board MCU processor, such as figure 2 As shown, on the basis of the 4 signal lines of SPI (including MOSI signal line, MISO signal line, CLK signal line and CS signal line), 2 GPIO signal lines are added, and the GPIO signal line includes soc_srq signal line and vip_srq signal line The soc_srq signal line notifies the in-vehicle MCU processor of the data transmission request information from the in-vehicle entertainment SOC processor, the vip_srq signal line is a falling edge trigger interrupt, and the in-vehicle entertainment SOC processor starts the SPI in the second half of the interrupt processing Transmission, when the on-board MCU processor has data to transmit or receives a soc_srq request, it will send a vip_srq request. The purpose of introducing these two pins is to speed up the transmission of IPCL messages and improve communication efficiency.

[0021] for figure 1 Obtain VIP information through IPCL, combine with image 3 Figure 4 Description, start IPCL transmission in the Bootloader stage, firstly, the car entertainment SOC processor sends a frame Framelen of "0x00, 0x09", indicating that the total length of the frame is 9 bytes, and then the value of MsgLen in Msg0 is set to "0x00, 0x05", this Msg The length is 5Byte, and then the Group ID is "0x09", which means that the Msg is a service message, and then the Payload is "0x02, 0x04", which means that the message is sent from the in-vehicle entertainment SOC processor to the in-vehicle MCU processor. The board-level information of the on-board MCU processor obtained by the application, the last two bytes are CRC, and the parameter model of CRC-16/CCITT is used; after the ACK Frame, the on-board MCU processor replies with the same Group ID, and the first two bytes of the payload are "0x01, 0x85" means that the data is board-level information sent from the on-board MCU processor to the on-board entertainment SOC processor, and then each Byte behind represents each hardware information, including version information, front screen, audio, camera, etc. information, the last two bytes are CRC. After the vehicle entertainment SOC processor obtains the frame data, it will parse and verify the entire frame through the ipcl_handle_rx function. and front screen information, and then related functions modify the device tree FDT to complete the dynamic adaptation process.

[0022] Finally, it should be noted that the above-mentioned embodiments are only used to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that The technical solutions described in the foregoing embodiments can still be modified, or some or all of the technical features thereof can be equivalently replaced, and these modifications or replacements do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.