linux-kernel - AOSP内核调试

Question

我们正在构建一个基于 imx6 SoC 的自定义 android 板。使用的android版本很旧(KitKat 4.4.2)，内核(3.0.35)也是如此。我们正在处理一个我们尚未弄清楚的问题。

通常，当一切正常时，板子的重启需要 5-6 秒的时间。但有时，板子的重启需要很长的时间，从 1.30 分钟到 2.30 分钟不等。

我们想知道的是，首先，内核卡在了哪个模块/函数中。

我们怀疑这可能是 eMMC 问题，但这是一个不太可能的猜测，我们真的不知道此时发生了什么。

你们知道让内核更加冗长的方法吗？喜欢打印每个函数调用？此时 kgdb 或类似的调试工具可以帮助我们吗？

谢谢，

问候，

沃特克

编辑:因此，我们在寻找问题方面取得了进展。结果内核卡在了 arch/arm/kernel/process.c 的 arm_machine_restart() 函数中。具体来说，它在调用 cpu_proc_fin() 函数后卡住，对于我们的板子，它在 arch/arm/mm/proc-v7.S 中定义为 cpu_v7_proc_init。该函数的代码在汇编中:

mrc p15, 0, r0, c1, c0, 0       @ ctrl register
bic r0, r0, #0x1000         @ ...i............
bic r0, r0, #0x0006         @ .............ca.
mcr p15, 0, r0, c1, c0, 0       @ disable caches
mov pc, lr

我们不是唯一遇到此问题的人。 ( thread on NXP forum here )我们尝试注释掉该行

// bic  r0, r0, #0x0006         @ .............ca.

现在该功能永远不会阻塞，但有时开发板仍然不会立即重新启动。目前，我们仍在寻找见解和建议。感谢大家阅读。

Answer 1

如果您在内核中启用CONFIG_PRINTK_TIME，dmesg 将在日志之前打印时间(以秒为单位)。这使您能够搜索行之间的时间间隔，也许您能够找到导致此问题的原因。

如果您发现问题确实存在于内核中，则可能您可以启用一些CONFIG_DEBUG_*配置项或在驱动程序中定义CONFIG_DEBUG来获取更多信息。否则，printk 将是您拥有的最好的。

此外，查看以下内核配置:

CONFIG_DEBUG_LL
CONFIG_DEBUG_IMX_UART
CONFIG_DEBUG_IMX6Q_UART
CONFIG_EARLY_PRINTK
CONFIG_EARLY_PRINTK_DIRECT

要完整:您可以使用 logcat 查看某些初始化是否延迟了启动。如果您的公司构建硬件，我认为查看芯片在示波器上的作用是值得的(因为我不会立即认为 Linux 正在延迟启动)，但在您确定多个板具有同样的问题。

我对您会发现什么很感兴趣。让我(我们)更新 ;-)