AOSP内核调试

Question

AOSP内核调试

linux-kernelandroid-sourceimx6

3

我们正在基于imx6 SoC构建自定义的Android板。所使用的Android版本非常老旧（KitKat 4.4.2），内核也是如此（3.0.35）。我们遇到了一个问题，但尚未解决。

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

我们想知道的第一件事是，内核卡在哪个模块/函数中。

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

您是否知道如何使内核额外详细？例如打印每个函数调用？kgdb或类似的调试工具能否帮助我们解决问题？

谢谢，

问候，

Vauteck

编辑：我们在解决问题的过程中取得了进展。事实证明，内核被卡在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

我们不是唯一遇到这个问题的人。(NXP论坛上的帖子在这里) 我们尝试注释掉这行代码。

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

现在该函数不会再阻塞，但有时候板子仍然不能立即重启。我们目前仍在寻找见解和建议。感谢大家的阅读。

- Vauteck

1:30分钟的时间提醒了一个未运行systemd服务的程序，在超时后退出。 - 0andriy

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bayou · Accepted Answer

如果您在内核中启用了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会延迟启动），但在确定多个板子存在相同问题之前不要这样做。

我很想知道您会发现什么。保持联系，更新我们的进展；-）