STM32MP157内核移植相关bug

一、主频问题

  在初学STM32MP157驱动开发时笔者曾对官方最新版的Linux内核进行了移植但是因为一些问题导致移植后的系统存在一些bug。最近笔者又重新对这部分做了一些了解发现了一些问题有兴趣的可以一起探讨。
  首先是主频问题按照相关教程对TF-A和U-Boot进行移植后在U-Boot中显示的芯片主频为650MHz。笔者使用了很多方法尝试修复比如在U-Boot的设备树中修改 PLL 倍频、去除U-Boot中的pmic电源芯片验证、ADC和DAC验证等但是并没有修复。最后笔者使用非验证方式的U-Boot进行烧写也就是将U-Boot编译产生的u-boot-spl.stm32作为fsbl直接作为引导将u-boot.stm32直接作为启动文件发现可以正确识别芯片并可以使用800MHz工作频率。然后将TF-A重新加到U-Boot的头部之后就又回到650MHz。(这里也使用了多种方式进行头部验证包括Makefile.sdk直接编译出fip和metadata、使用fiptool手动合成等等所以笔者猜测在TF-A中还是存在某些验证方式例如pmic芯片验证、ADC输入电压采样验证等导致芯片无法正确工作。
  后续笔者又采取了一些方式尝试修复

• 1.使用旧版本的TF-A编译出BL32作为新版本U-Boot的头部验证
  这种方式会出现BL32无法正确引导BL33(也就是U-Boot)的现象具体表现为开机进入BL32(SP_MIN方式)后一直重启无法正确加载U-Boot。
• 2.按照官方手册将新版U-Boot的xxxx-fw-config.dts编译出.dtb设备树文件作为TF-A的配置文件然后编译出头部信息添加。
  这种方式也没法修复主频bug。

最后将正点原子官方的出厂镜像进行烧录发现该镜像在启动时直接跳过了头部信息验证。

这里就要提一下V2.6版本的官方移植包问题此版本在官方的开发手册中原则上应该先对U-Boot进行编译得到u-boot-nodtb.bin文件和u-boot.dtb文件然后再生成u-boot-trusted.dtb作为TF-A的输入配置之后再编译TF-A得到fip-tf-a-trusted.bin文件和metadata.bin文件其中fip-tf-a-trusted.bin就是SP_MIN验证信息和U-Boot的结合metadata.bin则是对此文件的验证。

所以这里笔者猜测如果想要修复U-Boot中的主频bug应该使用以下方法
1.使用原子哥的方式直接跳过头部信息验证也就是将TF-A与U-Boot分离开来。
这种方式也存在一些问题其一TF-A无法再起到验证作用那么这部分的开发就失去了设计的意义。其二需要对TF-A内部进行修改目前对笔者来说难度较大。
2.修改TF-A内部的验证方式
笔者猜测在ST提供的源码中TF-A内部应该存在某种对外设的验证当外部没有此设备时就自动降频到安全一点的工作模式。比如前面提到的pmic芯片、ADC采样某个管脚的电压值验证等。仅是猜测还有待验证。
3.使用官方推荐的pmic电源芯片。注这部分仅为笔者猜测因为国产的一些第三方的开发板与官方的板子最大的差别就是在这里所以如果想自己做板子并移植最新版的内核目前来看还是复刻一下最好。之后有新版本的移植方式再替换。

二、驱动开发时的头文件缺失问题

  在基于Linux-5.15的源码包进行开发时会出现头文件缺失问题例如<linux/ide.h>、<linux/module.h>问题这里笔者在源码包下进行了查找并没有查询到相关的头文件也找不到能够兼容和替代的类似头文件。所以笔者猜测可能是在新版本的内核中相关的驱动开发方式有了新的变化。(也可能是官方还没移植完善就上架了哈哈)。
  不过笔者尝试将原子哥教程中的相关头文件拷贝到新版本的对应目录中编译出来的驱动也能够在5.15内核中运行所以如果确实想用新版本开发驱动可以暂时尝试一下此方法之后再等待各大厂商教程的跟进。

三、结语

  笔者原以为学习完了相关教程就能够对这些bug进行修复结果发现还是能力不足学海无涯诸君共勉。以上的bug原因也仅是笔者的猜测欢迎有兴趣的大佬们一起探讨。笔者对于Linux驱动开发的学习也到此告一段落之后也许会找一些新的方向进行学习。