差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
| digi:arm-embedded:uboot:ccmp-uboot [2024/11/03 23:05] – robin | digi:arm-embedded:uboot:ccmp-uboot [2024/11/05 23:18] (当前版本) – robin | ||
|---|---|---|---|
| 行 24: | 行 24: | ||
| </ | </ | ||
| 其中解包op-tee镜像出来的得到的nt-fw.bin是uboot不带设备树的文件。 | 其中解包op-tee镜像出来的得到的nt-fw.bin是uboot不带设备树的文件。 | ||
| + | ====修改内核设备树==== | ||
| + | 内核设备树是从uboot启动进入系统时加载的设备树，它和uboot时的可以不一样。一般地，自定义的板子，linux也要同样改好ccmp25-plc.dts和相关的makefile，然后在local.conf里加上这句： | ||
| + | < | ||
| + | KERNEL_DEVICETREE += " | ||
| + | </ | ||
| + | |||
| + | 在devshell里直接编译 | ||
| + | < | ||
| + | bitbake -c devshell linux-dey | ||
| + | </ | ||
| + | 应用改动，然后make dtbs，编译出本地修改的相关的设备树ccmp25-plc.dtb | ||
| =====修改U-Boot 源码===== | =====修改U-Boot 源码===== | ||
| + | 在工作区域修改U-Boot，首先要编译一个，以便拉取源码到工作区域。要清空之前的编译结果： | ||
| + | < | ||
| + | bitbake -c cleansstate tf-a-stm32mp | ||
| + | bitbake -c cleanall tf-a-stm32mp | ||
| + | bitbake -c cleansstate u-boot-dey | ||
| + | bitbake -c cleanall u-boot-dey | ||
| + | </ | ||
| + | 一般不需要对u-boot-dey清除工作，除非源码区乱了。如果清空后，要先用bitbake u-boot-dey编译出一个来。 | ||
| 对U-Boot的修改，和内核的修改一样，需要在git目录中，以ccmp25为例，是tmp/ | 对U-Boot的修改，和内核的修改一样，需要在git目录中，以ccmp25为例，是tmp/ | ||
| < | < | ||
| 行 31: | 行 50: | ||
| tmp/ | tmp/ | ||
| tmp/ | tmp/ | ||
| + | 修改uboot时，上面这些文件需要修改，最好是在目录外新建个git项目，把修改的文件以链接文件的形式链接进来，这样也方便检查是否被覆盖 | ||
| </ | </ | ||
| - | 如果您使用bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey并没有什么不同 | + | 如果不是Arm Trusted Fimware，一般是用bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey只会用缓存，所以不要用它，也无需用：bitbake u-boot-dey -f -c do_deploy |
| + | , 以下是非安全功能的UBoot编译结果和部署的地方。 | ||
| < | < | ||
| - | 其备树在：tmp/ | + | 其设备树在：tmp/ |
| U-Boot在：tmp/ | U-Boot在：tmp/ | ||
| U-Boot也在：tmp/ | U-Boot也在：tmp/ | ||
| 并且启动脚本也是在tmp/ | 并且启动脚本也是在tmp/ | ||
| </ | </ | ||
| - | 如果想要确保部署：bitbake u-boot-dey -f -c do_deploy | + | 但对于CCMP系列带安全功能支持的核心板来说，UBoot和设备树是被打包在FIP镜像中，事实上，如果深究uboot的配方，会发现deploy阶段，是把设备树和不带设备树的uboot拷到deploy-u-boot-dey/ |
| - | + | ||
| - | 事实上，如果深究uboot的配方，会发现deploy阶段，是把设备树和不带设备树的uboot拷到deploy-u-boot-dey/ | + | |
| < | < | ||
| tmp/ | tmp/ | ||
| tmp/ | tmp/ | ||
| </ | </ | ||
| - | 所以，用自己的设备树替代，注意，我们用回默认的uboot的设备树名： | + | 如果在内核中使用自己的设备树名，比如ccmp25-plc.dtb，在uboot中大可没必要，其实uboot也有自己的设备树，它放在uboot源码目录下的arch/ |
| - | < | + | |
| - | cp tmp/ | + | |
| + | 以在~/ | ||
| + | {{: | ||
| + | |||
| + | 其中，根目录下的是内核的设备树，而uboot的设备树在uboot-dts中，配置文件在uboot/ | ||
| + | < | ||
| + | cd tmp/ | ||
| + | mv configs/ | ||
| + | cp ~/ | ||
| + | mv arch/ | ||
| + | mv arch/ | ||
| + | mv arch/ | ||
| + | ln -s ~/ | ||
| + | cp ~/ | ||
| + | cp ~/ | ||
| + | cp ~/ | ||
| + | 在上面操作中，我们原本用链接文件（即修改版的uboot)替代了，并且ccmp25-dvk.dts也和新增加的ccmp25-plc.dts链接到同一个修改版的uboot所用的设备树。注意，默认的设备树dts和dtsi不可用链接文件，改为cp拷贝进去则可以。 | ||
| + | 复查一下，确保文件正确 | ||
| + | ls -la arch/ | ||
| + | </ | ||
| + | 编译前也可检查一下编译目录下的内容，以便知道更新情况 | ||
| + | < | ||
| + | ls -la ../ | ||
| + | ls -la ../ | ||
| + | ls -la ../ | ||
| + | </ | ||
| + | 注意，此时我们用bitbake -C compile u-boot-dey，会发现原来的build/ | ||
| + | < | ||
| + | cp deploy-u-boot-dey/ | ||
| + | cd ~/temp | ||
| + | dtc -I dtb -O dts -o uboot.dts u-boot-ccmp25-dvk.dtb | ||
| + | cat uboot.dts |grep dummy | ||
| + | </ | ||
| + | 我们在自己修改的uboot的设备树中加入了dummy节点，而这里没有，说明修改版没有应用上。如果不想深究，可以用编译出来的ccmp25-plc.dtb来替代所有的ccmp25-dvk.dtb | ||
| + | < | ||
| + | cp build/ | ||
| + | cp build/ | ||
| + | bitbake tf-a-stm32mp | ||
| + | </ | ||
| + | 再测试一下： | ||
| + | < | ||
| + | cp tmp/ | ||
| + | fiptool unpack ~/ | ||
| + | dtc -I dtb -O dts -o uboot.dts hw-config.bin | ||
| </ | </ | ||
| - | linux也同样改好ccmp25-plc.dts和相关的makefile，然后在local.conf里加上这句：KERNEL_DEVICETREE += " | ||
| - | 编译出相关的ccmp25-plc.dtb | ||
| - | 接着编译 | + | 验证无误后，再bitbake core-image-base编译出所有镜像，最后更新 |
| < | < | ||
| - | bitbake core-image-base | + | update fip-a tftp fip-ccmp25-dvk-optee.bin |
| </ | </ | ||
| + | |||
| + | |||
| =====修改U-Boot设备树===== | =====修改U-Boot设备树===== | ||
| 修改源代码，在添加不同设备树的场景并不适用。并且git目录在bitbake -c cleansstate或cleanall时，都会被清空。因此，直正的修改需要发生在DEY的源码区，也就是sources里。 | 修改源代码，在添加不同设备树的场景并不适用。并且git目录在bitbake -c cleansstate或cleanall时，都会被清空。因此，直正的修改需要发生在DEY的源码区，也就是sources里。 | ||