在ATF的架构下，我使用ATF Github上提供的Test Secure Payload(TSP)当做是BL32，然后使用Test Secure Payload Dispatcher(TSPD)当做是BL31 runtime service。
但是在移植TSP时遇到了些问题，我的平台是ARMv8架构的。
在整个ATF流程中，每个阶段皆可正常的初始化，其中BL32我没有做额外的初始，如MMU、timer、GICv3，只有使用ATF的默认值去设定中断处理interrupt handler(vector table)
目前我只是想把TSP移植至ATF，然后跳至BL33完整的开机完成。
目前的状况是，如果没有加BL32(TSP)进去，当然TSPD也就没有启动，那BL31可正常的带起BL33，并且linux kernel也可正常的开完。
但是如果将TSP移植进BL32，并且ATF的流程也将BL32初始完成回至BL31再开始进入BL33开机流程的话，会开到一半卡住，有点像卡在一个loop，trace的结果可能是卡在generic_handle_irq、gic_handle_irq
我现在不太确定GIC的设定是否会影响至BL33开机？
且目前有观查到AArch32 GIC system register的值有些异常，但因为BL31、BL32、BL33皆是64bits的，所以不确定是否有直接的影响？
Ref : github.com/.../arm-trusted-firmware
Hi R.W.
你用的什么平台，建议你检查下GICv3的初始化配置，看看把Secure Timer interrupt配置到哪个group，如果你使用的GICv3 programming mode的话，建议你把Secure Timer interrupt配置到Secure Group 1.
我是拿mtk的平台，GICv3当初是在BL31配置的，但那一块我没有很熟，之后再来研读一下。因为曾经有想这个timer应该是secure timer，理论上不会把interrupt导至linux这边才对，但不是很确定。
gic_cpuif_init{
......
/* set all SGI/PPI as non-secure GROUP1 by default. rdist_base + 64K == SGI_base */ mmio_write_32(rdist_base+SZ_64K+GICE_V3_IGROUP0, 0xffffffff); mmio_write_32(rdist_base+SZ_64K+GICE_V3_IGRPMOD0, 0x0);
}
如果是MTK ，那比较直接，我这有的是X20代码为例子，所有PPI 终端配置到NS-G1（这里是KERNEL）,
包含SECURITY TIMER,不知道你那边具体哪个平台。
你可以查看下PLAT_ARM_G1S_IRQS里面是否包含Secure Timer interrupt，Secure timer是给Secure world来用的，但是需要配置到Secure Group 1，如果配置到Non-secure Group 1的话，可能会存在问题，
刚刚看了一下PLAT_ARM_G1S_IRQS中没有把ARM_IRQ_SEC_PHY_TIMER加进去，把ARM_IRQ_SEC_PHY_TIMER补进去后，也把BL32 Secure Timer Start起来，能正常的开机。
因为是和别的团队一起开发的，实际的平台不是很清楚，因为我这是跑模拟的。
然后，KERNEL的部份是接别人，KERNEL中的配置知道的有限。