一种适配多款屏幕升级方法与流程

1.本发明属于车载娱乐系统领域，具体涉及一种适配多款屏幕升级方法。


背景技术：

2.随着汽车技术的发展，对车载娱乐系统的娱乐屏要求也越来越复杂，可能存在对车载娱乐系统需要适配多款娱乐屏的需求，每种屏幕都可能有不同的升级方案。现有的技术方案，是为每一种屏幕提供一套车载娱乐系统软件，以满足娱乐屏的升级需求，需要替换屏幕时，需要重新提供车载娱乐系统软件，对车载娱乐系统软件版本维护要求成本要求很高，不利于汽车技术的发展。


技术实现要素：

3.为达到上述目的，为了解决现有技术弊端，降低车载娱乐系统软件版本维护成本，发明一款可以根据娱乐屏的厂家信息、背光开关状态、升级协议编号等信息，自动选择娱乐屏的升级协议，达到同一车载娱乐系统软件版本，可以适配多款娱乐屏升级协议。一种适配多款屏幕升级方法，所述方法包括以下步骤：1) 车载娱乐系统开机后，车载soc处理器启动进入bootloader程序并获取娱乐屏信息；2) 车载soc处理器获取到娱乐屏的信号后，根据获取的信息对内核设备树的屏幕驱动节点进行修改；3) 屏幕驱动根据设备树的节点数据选择娱乐屏的升级协议进行升级；4) 选择了合适的娱乐屏升级协议后，娱乐屏软件正常升级。
4.基于上述方案，本方案中车载系统将娱乐屏的厂家信息、背光开关状态及升级协议编号等信息，保存在eeprom中，eeprom由车载mcu处理器端控制，eeprom的掉电数据不丢失的特性，可以很好的保存娱乐屏的信息，本发明车载mcu处理器控制eeprom，在车载娱乐系统下线生产的过程中，一次写入。
5.作为本发明的一种改进，所述1）中，车载soc处理器与车载mcu处理器端的通信协议过程采用spi总线的物理层，bootloader程序ipcl协议与车载mcu处理器进行通信，ipcl协议的物理层通过spi总线进行通信。
6.作为本发明的一种改进，所述1）中车载mcu处理器在收到bootloader程序ipcl协议请求后，车载mcu处理器将boardinfo信息按应答帧格式，将boardinfo信息返回到车载soc处理器bootloader程序。
7.基于上述方案，ipcl通信协议帧格式包含：数据帧dataframe，应答帧（非应答）ack/nackframe和无效帧dummyframe。dataframe：用来封装ipclmessage，包括请求和数据等信息，dummyframe：用于保持mtk2712和rh850之间的连接，定时发送的心跳数据包，ack/nackframe：用于mt2712或者rh850返回上次通信的结果，成功或失败。
8.作为本发明的一种改进，所述2）中，车载娱乐系统的设备树的二进制dtb文件，保
存着娱乐屏驱动的设备信息，车载soc处理器bootloader程序根据boardinfo信息，对dtb文件娱乐屏驱动的设备信息进行修改。
9.作为本发明的一种改进，所述3）中，车载娱乐系统的娱乐屏驱动被系统加载后，根据设备树二进制dtb文件中保存娱乐屏设备信息，选择对应的娱乐屏升级协议。
10.作为本发明的一种改进，娱乐屏协议升级包括以下步骤：1）车载soc发送reset信号给娱乐屏；2）车载soc发送模式请求命令，娱乐屏返回当前模式为fbl；3）车载soc发送厂家id请求命令，娱乐屏返回厂家id；4）车载soc发送握手命令，娱乐屏返回握手成功；5）车载soc发送安全码命令，娱乐屏检验安全码合法性，并返回成功；6）车载soc发送娱乐屏镜像数据，娱乐屏接收到数据，并验证数据有效，返回成功；7）车载soc发送数据包校验和命令，娱乐屏匹配校验和，返回成功；8）车载soc发送更新完成命令，娱乐屏接收，并重启；9）车载soc再次发送模式请求命令，娱乐屏返回模式为app。
11.作为本发明的一种改进，所述boardinfo信息包括厂家信息、背光开关状态以及升级协议编号。
12.作为本发明的一种改进，厂家信息、背光开关状态以及升级协议编号保存在eeprom中，eeprom由车载mcu处理器端控制。
13.作为本发明的一种改进，车载soc处理器与车载mcu处理器端的通信协议过程双方采用spi总线的物理层的通信速率为1mhz。
14.相对于现有技术，本发明的有益效果为：本发明可以降低车载娱乐系统的版本维护成本，因为本发明的目的就是完成一个车载娱乐系统版本对所有娱乐屏的升级协议的适配，所以只需要维护一个车载娱乐系统版本即可，就可完成对升级协议的选择，提高整个车载娱乐系统的代码重用度，提高开发效率。
附图说明
15.图1为本发明中车载娱乐系统启动流程图。
16.图2为本发明中车载soc处理器与车载mcu处理器之间ipcl通信协议。
17.图3为本发明中屏幕升级协议流程图。
具体实施方式
18.下面结合附图和具体实施方式，进一步阐明本发明，应理解下述具体实施方式仅用于说明本发明而不用于限制本发明的范围。
19.实施例：如图1所示，一种适配多款屏幕升级方法，所述方法包括以下步骤：1) 车载娱乐系统开机后，车载soc处理器启动进入bootloader程序并获取娱乐屏信息；2) 车载soc处理器获取到娱乐屏的信号后，根据获取的信息对内核设备树的屏幕驱动节点进行修改；3) 屏幕驱动根据设备树的节点数据选择娱乐屏的升级协议进行升级；
4) 选择了合适的娱乐屏升级协议后，娱乐屏软件正常升级。
20.本方案中车载娱乐系统的车载soc处理器是mtk2712，车载mcu处理器是renesasrh850，车载系统将娱乐屏的厂家信息、背光开关状态及升级协议编号等信息，保存在eeprom中，eeprom由车载mcu处理器端控制，eeprom的掉电数据不丢失的特性，可以很好的保存娱乐屏的信息，本发明车载mcu处理器控制eeprom，在车载娱乐系统下线生产的过程中，一次写入。
21.车载soc处理器与车载mcu处理器端的通信协议过程采用spi总线的物理层，bootloader程序ipcl协议与车载mcu处理器进行通信，ipcl协议的物理层通过spi总线进行通信。
22.所述1）中车载mcu处理器在收到bootloader程序ipcl协议请求后，车载mcu处理器将boardinfo信息按应答帧格式，将boardinfo信息返回到车载soc处理器bootloader程序。
23.ipcl通信协议帧格式包含：数据帧data frame，应答帧（非应答）ack/nack frame和无效帧dummy frame。data frame：用来封装ipclmessage，包括请求和数据等信息，dummy frame：用于保持mtk2712和rh850之间的连接，定时发送的心跳数据包。ack/nack frame：用于mt2712或者rh850返回上次通信的结果，成功或失败。
24.如图2所示，车载soc处理器发送数据帧的同时，车载mcu处理器端发送一个dummy frame，表示车载mcu处理器有效；车载soc处理器发送应答帧ack frame，作为上一次车载mcu处理器dummy frame的应答，车载mcu处理器同时发送应答帧ack frame，作为上一次车载soc处理器发送数据帧的应答；车载soc处理器发送dummy frame，表示车载soc处理器有效。车载mcu处理器同时发送一个数据帧。车载soc处理器发送应答帧ack frame，作为上一次车载mcu处理器数据帧的应答。车载mcu处理器同时发送应答帧ack frame，作为上一次车载soc处理器发送dummy frame的应答。
25.进一步地，所述2）中，车载娱乐系统的设备树的二进制dtb文件，保存着娱乐屏驱动的设备信息，车载soc处理器bootloader程序根据boardinfo信息，对dtb文件娱乐屏驱动的设备信息进行修改。
26.表1包含boardinfo信息的帧内容
车载mcu处理器返回的包含boardinfo信息的帧内容如上表1所示。
27.车载soc处理器bootloader程序，收到boardinfo数据包后，对数据包进行解析，解析byte6~byte8的数据，screen_product_id=0x01，backlight=0x01，screen_update_id=0x01。使用fdt工具修改设备树二进制dtb文件，将dtb文件中娱乐屏驱动的设备信息修改为screen_product_id=0x01，backlight=0x01，screen_update_id=0x01；加载娱乐屏驱动程序，娱乐屏驱动程序根据娱乐屏驱动的设备信息screen_update_id=0x01，选择“升级协议0x01”。
28.如果升级协议需要使用“升级协议0x02”，车载soc处理器bootloader程序，收到boardinfo数据包后，对数据包进行解析，解析byte6~byte8的数据，screen_product_id=0x01，backlight=0x01，screen_update_id=0x02。使用fdt工具修改设备树二进制dtb文件，将dtb文件中娱乐屏驱动的设备信息修改为screen_product_id=0x01，backlight=0x01，screen_update_id=0x02；加载娱乐屏驱动程序，娱乐屏驱动程序根据娱乐屏驱动的设备信息screen_update_id=0x02，选择“升级协议0x02”。
29.如图3所示，所述3）中，屏幕升级协议包括以下步骤：步骤1：车载soc（host）发送reset信号给娱乐屏；步骤2：车载soc发送模式请求命令，娱乐屏返回当前模式为fbl(fbl表示屏幕处在升级模式)；步骤3：车载soc发送厂家id请求命令，娱乐屏返回厂家id（如长江0x11）；步骤4：车载soc发送握手（handshake）命令，娱乐屏返回握手成功；步骤5：车载soc发
送安全码命令，娱乐屏检验安全码合法性，并返回成功（合法性验证返回fd，错误返回fb）；步骤6：车载soc发送娱乐屏镜像数据，娱乐屏接收到数据，并验证数据有效，返回成功（host发送第一个数据包，等待数据接收响应，host收到数据接收响应fa，错误返回fb，host持续发送其余的数据包，每次发送128个字节数据，index为要发的次数）；步骤7：车载soc发送数据包校验和命令，娱乐屏匹配校验和，返回成功；步骤8：车载soc发送更新完成命令，娱乐屏接收，并重启；步骤9：车载soc再次发送模式请求命令，娱乐屏返回模式为app（app表示娱乐屏处在正常使用模式）；所述4）中，按照所述3）协议升级完成后，读取版本号信息，版本号更新表示升级成功。
30.需要说明的是，以上内容仅仅说明了本发明的技术思想，不能以此限定本发明的保护范围，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰均落入本发明权利要求书的保护范围之内。