AOSP内核调试

Question

我们正在构建一个基于imx6 SoC的定制安卓板。所使用的android版本相当古老(KitKat 4.4.2)，内核也是如此(3.0.35)。我们正在处理一个尚未解决的问题。

通常情况下，当一切正常时，重新启动板需要5-6秒的时间。但有时，重新启动董事会需要一个长的时间，从1.30分钟到2.3分钟不等。

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

我们怀疑这可能是一个eMMC问题，但这是一个长远的猜测，我们真的不知道在这一点上发生了什么。

你们知道如何使内核变得更详细吗？比如打印每个函数调用？在这一点上，kgdb或类似的调试工具能帮助我们吗？

谢谢,

致以敬意，

沃特克

编辑:所以我们在搜索问题方面取得了进展。结果，内核被卡在arch/arm/内核/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.

现在，该函数从不阻塞，但有时董事会仍然没有立即重新启动。在这一点上，我们仍在寻找见解和建议。谢谢你的读书人。

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正在延迟引导)，但在你确定多个板都有相同的问题之前，你不会知道。

我对你会发现什么感兴趣。随时通知我(我们) ;-)