ARM TrustZone技术和安全启动流程涉及到一些特点，首先分区结构可大致如左图所示：

一般而言，在NAND闪存上，分区表是由字符串定义的(mtdparts)​，fsbl1, fsbl2: (First Stage Boot Loader) 包含了ARM可信固件(TF-A)​，metadata1, metadata2分区则包含了从哪个FIP镜像启动的信息（A或B）; 而固件镜像包fip-a, fip-b则包含了OP-TEE和U-Boot。​UBI分区中有不同的UBI卷，包含有U-Boot环境参数和系统镜。​

以下是一个简化的CCMP启动流程：

1、上电或复位：处理器开始执行内置的ROM代码，加载tf-a固件，初始化TrustZone

2、tf-a根据metadata分区中的信息加载FIP固件，它加载OP-TEE(BL32)，设置安全环境，然后加载并启动非安全世界的引导加载程序U-Boot(BL33)

3、U-Boot：加载Linux内核和设备树，启动操作系统。

其中tf-a和op-tee都会包含设备树，这个流程确保了系统的每个阶段都是经过验证的，并且能够在TrustZone的保护下安全地执行。因此，对于U-Boot的修改，最终生成的可刷写的固件是ta-a和op-tee固件，其中op-tee固件中打包有uboot二进制文件。

Trusted Firmware ARM (TF-A)​是开源项目，它包含有内存的配置，以及平台所用的基础设备树信息，比如锁相环和时钟设备树节点，以及启动所需的接口（内存，闪存，console等）。OP-TEE也是开源项目，它也会包含设备树信息，像电源控制器和管理配置，安全和非安全接口。

验证这两个固件主要有什么，可以用binwalk和fiptool，如：

binwalk tf-a-ccmp25-dvk-emmc.stm32
fiptool unpack fip-ccmp25-dvk-optee.bin

其中解包op-tee镜像出来的得到的nt-fw.bin是uboot不带设备树的文件。

对U-Boot的修改，和内核的修改一样，需要在git目录中，以ccmp25为例，是tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/下的git目录。其中包括：

tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/git/configs/ccmp25-dvk_defconfig  定义了内核加载的默认设备树
tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/git/arch/arm/dts/ccmp25-plc.dts  自定义的设备树可放这里，但要注意同时改相同目录下的Makefile
tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/git/arch/arm/dts/Makefile  添加要编译的自定义设备树

如果您使用bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey并没有什么不同

其备树在：tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/build/ccmp25-dvk_defconfig/arch/arm/dts/
U-Boot在：tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/image
U-Boot也在：tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/deploy-u-boot-dey/ 
并且启动脚本也是在tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/deploy-u-boot-dey/

如果想要确保部署：bitbake u-boot-dey -f -c do_deploy

事实上，如果深究uboot的配方，会发现deploy阶段，是把设备树和不带设备树的uboot拷到deploy-u-boot-dey/uboot目录下。所以，这两个文件才是启动的关键文件：

tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/deploy-u-boot-dey/u-boot-ccmp25-dvk.dtb  
tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/deploy-u-boot-dey/u-boot-nodtb.bin

所以，用自己的设备树替代，注意，我们用回默认的uboot的设备树名：

cp tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/build/ccmp25-dvk_defconfig/arch/arm/dts/ccmp25-dvk.dtb tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/deploy-u-boot-dey/u-boot/u-boot-ccmp25-dvk.dtb

linux也同样改好ccmp25-plc.dts和相关的makefile，然后

bitbake core-image-base

修改源代码，在添加不同设备树的场景并不适用。并且git目录在bitbake -c cleansstate或cleanall时，都会被清空。因此，直正的修改需要发生在DEY的源码区，也就是sources里。

在deyaio目录里，sources下的各个layer是来自git源码项目，在本地它是一个分离头指针。用git log可以查看当前的版本。