差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
| digi:arm-embedded:uboot:ccmp-uboot [2024/11/05 10:24] – 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，首先要编译一个，以便拉取源码到工作区域。要清空之前的编译结果： | 在工作区域修改U-Boot，首先要编译一个，以便拉取源码到工作区域。要清空之前的编译结果： | ||
| 行 41: | 行 52: | ||
| 修改uboot时，上面这些文件需要修改，最好是在目录外新建个git项目，把修改的文件以链接文件的形式链接进来，这样也方便检查是否被覆盖 | 修改uboot时，上面这些文件需要修改，最好是在目录外新建个git项目，把修改的文件以链接文件的形式链接进来，这样也方便检查是否被覆盖 | ||
| </ | </ | ||
| - | 如果不是Arm Trusted Fimware，一般是用如果bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey并没有什么不同，如果有问题想确保部署：bitbake u-boot-dey -f -c do_deploy | + | 如果不是Arm Trusted Fimware，一般是用bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey只会用缓存，所以不要用它，也无需用：bitbake u-boot-dey -f -c do_deploy |
| , 以下是非安全功能的UBoot编译结果和部署的地方。 | , 以下是非安全功能的UBoot编译结果和部署的地方。 | ||
| < | < | ||
| 行 58: | 行 69: | ||
| 以在~/ | 以在~/ | ||
| - | {{: | + | {{: |
| 其中，根目录下的是内核的设备树，而uboot的设备树在uboot-dts中，配置文件在uboot/ | 其中，根目录下的是内核的设备树，而uboot的设备树在uboot-dts中，配置文件在uboot/ | ||
| 行 64: | 行 75: | ||
| cd tmp/ | cd tmp/ | ||
| mv configs/ | mv configs/ | ||
| - | ln -s ~/ | + | 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/ | ||
| </ | </ | ||
| - | + | 编译前也可检查一下编译目录下的内容，以便知道更新情况 | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | 所以，用自己的设备树替代，注意，我们用回默认的uboot的设备树名： | + | |
| < | < | ||
| - | cp tmp/work/ | + | ls -la ../deploy-u-boot-dey |
| + | ls -la ../deploy-u-boot-dey/u-boot | ||
| + | ls -la ../ | ||
| + | </ | ||
| + | 注意，此时我们用bitbake -C compile u-boot-dey，会发现原来的build/ccmp25-dvk_defconfigs/ | ||
| + | < | ||
| + | cp deploy-u-boot-dey/u-boot/u-boot-ccmp25-dvk.dtb ~/temp | ||
| + | cd ~/temp | ||
| + | dtc -I dtb -O dts -o uboot.dts u-boot-ccmp25-dvk.dtb | ||
| + | cat uboot.dts |grep dummy | ||
| + | </code> | ||
| + | 我们在自己修改的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 |
| </ | </ | ||
| - | 注意：bitbake -c cleanall u-boot-dey也会删除tfa和fip目录，而deploy目录下也有u-boot，里面似乎是来自deploy-u-boot-dey/ | + | |
| =====修改U-Boot设备树===== | =====修改U-Boot设备树===== | ||
| 修改源代码，在添加不同设备树的场景并不适用。并且git目录在bitbake -c cleansstate或cleanall时，都会被清空。因此，直正的修改需要发生在DEY的源码区，也就是sources里。 | 修改源代码，在添加不同设备树的场景并不适用。并且git目录在bitbake -c cleansstate或cleanall时，都会被清空。因此，直正的修改需要发生在DEY的源码区，也就是sources里。 | ||