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不带设备树的文件。

内核设备树是从uboot启动进入系统时加载的设备树，它和uboot时的可以不一样。一般地，自定义的板子，linux也要同样改好ccmp25-plc.dts和相关的makefile，然后在local.conf里加上这句：

KERNEL_DEVICETREE += "ccmp25-plc.dtb"

在devshell里直接编译

bitbake -c devshell linux-dey

应用改动，然后make dtbs，编译出本地修改的相关的设备树ccmp25-plc.dtb

在工作区域修改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/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/ccmp25-dvk-u-boot.dtsi  如果修改发生在dtsi中，也要一并修改
tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/git/arch/arm/dts/Makefile  添加要编译的自定义设备树
修改uboot时，上面这些文件需要修改，最好是在目录外新建个git项目，把修改的文件以链接文件的形式链接进来，这样也方便检查是否被覆盖

如果不是Arm Trusted Fimware，一般是用bitbake -C compile u-boot-dey，这会生成uboot的二进制和相关的设备树，用bitbake u-boot-dey只会用缓存，所以不要用它，也无需用：bitbake u-boot-dey -f -c do_deploy , 以下是非安全功能的UBoot编译结果和部署的地方。

其设备树在：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/

但对于CCMP系列带安全功能支持的核心板来说，UBoot和设备树是被打包在FIP镜像中，事实上，如果深究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

如果在内核中使用自己的设备树名，比如ccmp25-plc.dtb，在uboot中大可没必要，其实uboot也有自己的设备树，它放在uboot源码目录下的arch/arm/dts下。我们虽然可以在这个目录下添加自定义的设备树名，但打包的配方是tf-a-stm32mp，不更改配方的情况下，最好用默认的uboot的设备树名。

以在~/mygit/github/ccmp25-plc项目为例，其目录结构如下：

其中，根目录下的是内核的设备树，而uboot的设备树在uboot-dts中，配置文件在uboot/configs/ccmp25-dvk_defconfig。假定我们这在个git目录上修改了设备树源码，进入到git目录，移除之前旧的，用链接到这个源码库的文件替代，如：

cd tmp/work/ccmp25_dvk-dey-linux/u-boot-dey/2022.10-r0/git
mv configs/ccmp25-dvk_defconfig ~/temp/
cp ~/mygit/github/ccmp25-plc/uboot/configs/ccmp25-dvk_defconfig configs/ccmp25-dvk_defconfig
mv arch/arm/dts/ccmp25-dvk-u-boot.dtsi ~/temp/
mv arch/arm/dts/ccmp25-dvk.dts ~/temp/
mv arch/arm/dts/Makefile ~/temp
ln -s ~/mygit/github/ccmp25_dt/uboot-dts/ccmp25-plc.dts arch/arm/dts/ccmp25-plc.dts
cp ~/mygit/github/ccmp25_dt/uboot-dts/ccmp25-plc.dts arch/arm/dts/ccmp25-dvk.dts
cp ~/mygit/github/ccmp25_dt/uboot-dts/ccmp25-dvk-u-boot.dtsi arch/arm/dts/ccmp25-dvk-u-boot.dtsi
cp ~/mygit/github/ccmp25_dt/uboot-dts/Makefile
在上面操作中，我们原本用链接文件（即修改版的uboot)替代了，并且ccmp25-dvk.dts也和新增加的ccmp25-plc.dts链接到同一个修改版的uboot所用的设备树。注意，默认的设备树dts和dtsi不可用链接文件，改为cp拷贝进去则可以。
复查一下，确保文件正确
ls -la arch/arm/dts/ccm*

编译前也可检查一下编译目录下的内容，以便知道更新情况

ls -la ../deploy-u-boot-dey
ls -la ../deploy-u-boot-dey/u-boot
ls -la ../build/ccmp25-dvk_defconfig/arch/arm/dts/cc*

注意，此时我们用bitbake -C compile u-boot-dey，会发现原来的build/ccmp25-dvk_defconfigs/arch/arm/dts/下的ccmp25-dvk.dtb日期没变，但新的ccmp25-plc.dtb倒也确实生成了。另外deploy-u-boot-dey目录下的文件也是新日期，我们反编译检查一下deploy-u-boot-dey/u-boot/u-boot-ccmp25-dvk.dtb

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

我们在自己修改的uboot的设备树中加入了dummy节点，而这里没有，说明修改版没有应用上。如果不想深究，可以用编译出来的ccmp25-plc.dtb来替代所有的ccmp25-dvk.dtb

cp build/ccmp25-dvk_defconfig/arch/arm/dts/ccmp25-plc.dtb build/ccmp25-dvk_defconfig/arch/arm/dts/ccmp25-dvk.dtb
cp build/ccmp25-dvk_defconfig/arch/arm/dts/ccmp25-plc.dtb deploy-u-boot-dey/u-boot/u-boot-ccmp25-dvk.dtb
bitbake tf-a-stm32mp

再测试一下：

cp tmp/deploy/images/ccmp25-dvk/fip/fip-ccmp25-dvk-optee.bin ~/test/
fiptool unpack ~/test/fip-ccmp25-dvk-optee.bin
dtc -I dtb -O dts -o uboot.dts hw-config.bin

验证无误后，再bitbake core-image-base编译出所有镜像，最后更新

update fip-a tftp fip-ccmp25-dvk-optee.bin

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

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