TIMER_DebugSop
REVISION HISTORY¶
| Revision No. | Description |
Date |
|---|---|---|
| 1.0 | 12/10/2024 |
1. 问题一： Linux侧PM timer注册的中断处理函数没有被执行¶
1.1 Debug流程图¶
1.2 检查DTS中，Timer节点Status属性是否设置为OK¶
目前默认PM timer在riscv中使用，NO-PM timer在Linux侧使用。如果用户有需要在Linux侧使用PM timer，则建议不要在Riscv侧在使用PM timer。
1.3 检查PM timer对应的时钟是否Enable¶
PCUPID平台PM timer和其他SOC PM timer的不同之处在于其PM timer 4-7的clock是单独控制的，使用PM timer 4-7的时候，需要确保其对应的Clock是Enable的。
寄存器bank 0xe offset 0x33的0-3bit依次控制者PM timer4-7,可以通过/customer/riu_r 0xe 0x33获取的结果来判断。正常情况下，时钟在系统启动后，会默认开启，如果发现时钟没有开启，建议直接向FAE求助。
1.4 检查PM Timer运行时其对应的寄存器¶
用户可以通过PM timer对应的寄存器的值，来判断PM timer现在所处的状态。每个PM timer涉及的寄存器有好几个，此处不去细究每个寄存器的意义，我们核心是去判断PM timer是否在工作。如下图所示，PM timer对应的第一个寄存器如果是0x101，表示PM timer已经启动。
需要注意PM timer7的寄存器地址是在bank 0x32, 如下图所示
1.5 关闭Riscv重新测试¶
如果通过上面的检查都没有发现问题，建议先关闭Riscv，重新你的测试，关闭riscv的命令 echo 2 > /sys/class/sstar/riscv/reset
Timer的中断是同时往Riscv和Linux上报的，有时候Linux侧Timer注册的中断函数没被执行，大概率原因是Riscv那边干扰导致的，关闭Riscv重新实验，可以排除这方面的干扰。
1.6 求助FAE¶
求助FAE的时候，请先提供上诉几个步骤的结果。
2. 问题二： Riscv侧PM timer注册的中断处理函数没有被执行¶
Riscv侧PM timer注册中断函数没有被执行问题的Debug思路和Linux侧PM timer注册中断函数没有被执行问题思路类似。
2.2 检查DTS中，Timer节点Status属性是否设置为disable¶
目前默认PM timer在riscv中使用，NO-PM timer在Linux侧使用。如果用户有需要在Riscv侧使用PM timer，则建议不要在Linux侧在使用PM timer。
2.3 检查PM timer对应的时钟是否Enable¶
参考1.3 检查PM timer对应的时钟是否Enable
2.4 检查PM Timer运行时其对应的寄存器¶
参考1.4 检查PM Timer运行时其对应的寄存器
2.5 ARM侧只启动到uboot阶段重新测试¶
PCUPID平台方案中，arm侧uboot不会去使用PM timer，可以排除arm侧对于Riscv侧对PM timer使用的干扰。
2.6 求助FAE¶
求助FAE的时候，请先提供上述几个步骤的结果。