一、主频问题

在初学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内核中运行，所以如果确实想用新版本开发驱动，可以暂时尝试一下此方法，之后再等待各大厂商教程的跟进。