Linux kernel AOSP内核调试

我们正在构建一个基于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\u machine\u 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

我们不是唯一遇到这个问题的人。() 我们试着注释这句话

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

现在，该功能从未阻塞，但有时电路板仍不会立即重新启动。 目前，我们仍在寻求见解和建议。

---

感谢大家阅读。

如果在内核中启用

CONFIG\u PRINTK\u TIME

，

dmesg

将打印日志之前的时间（以秒为单位）。这使您能够搜索行之间的时间间隔，也许您能够找到导致此问题的原因

如果您发现内核中确实存在此问题，则很可能可以启用一些

CONFIG\u DEBUG\u*

配置项或在驱动程序中定义

CONFIG\u DEBUG

，以获取更多信息。否则，

printk

将是您最好的选择

另外，请查看以下内核配置：

CONFIG_DEBUG_LL
CONFIG_DEBUG_IMX_UART
CONFIG_DEBUG_IMX6Q_UART
CONFIG_EARLY_PRINTK
CONFIG_EARLY_PRINTK_DIRECT

完整：您可以使用

logcat

查看某些初始化是否会延迟引导。如果你的公司制造了硬件，我想看看芯片在示波器上做了什么是值得的（因为我不认为Linux会延迟启动），但是在你确定多个主板有相同的问题之前

---

我对你会发现什么感兴趣。让我（我们）随时更新；-）

1:30分钟为一个未运行的systemd服务敲响了警钟，该服务在超时时退出。感谢您的回答和建议。我们将检查您提到的内核选项，看看是否可以输出更多日志。在我最初的帖子中，我应该更精确一些，但这是需要很长时间才能关闭的主板，而不是重启后的实际启动。我会让您随时了解我们的发现：-）。连接uart并启用printk时间。内核日志被打印到uart，因此您将能够看到什么东西需要很长时间才能关闭，就像启动时一样：-）