其实之前都用过DeepSeek来解决问题，虽然有或多或少的帮助，但是始终没有解决问题，直到这一次。这就好比一个新型飞机的驾驶员，虽然已经击伤了一些目标，但是真正击落的第一个目标，还是值得大书特书的。

  这次需要解决的问题是在一台类似于树莓派的ARM主机上（其实就是ADLAM PLUTO），为Linux系统编译一个驱动模块，以驱动CH341串口芯片。

  Pluto的Linux系统没有这个驱动，因此无法识别CH341芯片，导致系统看不到串口，用不起来。

  查阅baidu、bing以及google后发现，虽然有编译linux驱动ko的介绍，例如https://zhuanlan.zhihu.com/p/653610030，但由于Pluto是比较小众的设备，搜索引擎都很难找到类似的案例，即使有https://blog.csdn.net/youhui_2020/article/details/145327058，也难以如法炮制，于是我想到了DeepSeek。

  1. 摸底发问
  我问的是“如何在ADALM pluto的linux系统中编译ko？”，DS给了两套方案，分别是交叉编译和本机编译。我倾向于用本机编译，于是修正了问题。

  2. 正式发问
  “用ADLAM PLUTO本机编译Linux驱动ko，kernel版本为5.15.36”
    
   DS给出了很清晰、完整的操作步骤，分别是：
  1. 安装依赖和内核头文件
  2. 获取驱动源码
  3. 配置驱动Makefile
  4. 编译驱动
  5. 加载并测试模块
  6. 其他建议

   我依葫芦画瓢，按照这个步骤，成功完成了编译。期间还遇到依赖不完备的问题，只要把错误提示发给DS，马上就能给出该安装的依赖，效率很高。

  附带说一下，PC机上的Linux系统编译驱动模块是比较简单的，因为编译需要的环境已经具备。但是嵌入式Linux系统的编译环境不完善，需要安装内核头文件。这是编译工作的最大难点，DS识别出来并给出了很好的解决方案。

      根据DS的分析，需要检查当前运行的内核版本和模块编译时使用的内核版本，果然略有差别，尽管版本号一致，但内核编译时的配置（如 SMP、CONFIG_MODULE_SIG 等）不同。

     根据DS的建议，从从 /proc/config.gz 提取了配置文件，重新进行了编译，最后驱动模块也安装成功了，串口也出现了。

  4. 总结
    通过这次经历，我感觉DS已经是很好的工作助手了，能够从我提供的信息中获取关键的信息，给的操作步骤越来越具体。比如一开始我没有说是啥驱动，DS的步骤也没有写明是啥驱动。可是当我发的提示信息中含有驱动名称后（“insmod: ERROR: could not insert module ch341.ko: Invalid module format”），DS后续的步骤都写成了ch341.ko，提取信息的能力超强。

   另外，我也没有说驱动编译的路径，只是发了
     root@analog:~/CH341SER_LINUX/driver# modinfo ch341.ko | grep vermagic
vermagic:       5.15.36 SMP mod_unload ARMv7 p2v8 
root@analog:~/CH341SER_LINUX/driver# uname -r
5.15.36

   DS就分析出驱动编译的路径是:~/CH341SER_LINUX/driver，操作步骤中居然有“cd ~/CH341SER_LINUX/driver”了，这分析能力真是绝了。