在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
补充下,你可以看看KERNEL 里面arch timer设置最后部分,就是开启timer前有哪些特别设置,这些没走完,就有对应中断上来,是有问题的。
去trace code的想法是,因为在arch timer中才去setup_irq (Linux内核提供用来注册中断处理的函数),有可能如您所说的”软件配置好了到GIC的硬件上信息完成有时差”,那软件设置还没结束就收到了中断,而变成无法找到相对应的handler。
是的,你想法有道理。TIMER 是个特殊的硬件DEVICE,对应irq来的早而且频繁,硬件IRQ LINE和软件侧IRQ_DESC要设置完成且MAPPING,才能在后面执行处理时候找到。你可以按照你的思路往下试试。
谢谢!!