• 状态 Resolved
  • 已锁定 已锁定
  • 回复 16 回复
  • 订户 0 订户
  • 视图 748 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] Linux/AM3358：将 I2C 线路拉至 GND 后 Linux 内核冻结

admin
Guru**** 2562340 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/602588/linux-am3358-linux-kernel-freeze-after-pulling-i2c-lines-to-gnd

器件型号：AM3358

工具/软件：Linux

您好！  

我们希望获得有关如何解决此问题的帮助、因为我们不知道规格中是否需要此类行为。

我们首先注意到在连接一些 i2c GPIO 扩展器后出现硬冻结、然后移至删除器件树中的内核驱动程序映射、并开始使用 i2cdetect -y -r 进行探测 。

一个器件。

我们设法通过在 i2cdetect 探针期间不断地随机短接地 sda/scl 来重现问题、因此我们可能会遇到恼人的情况  

减少时钟似乎有助于减少冻结事件的数量。

我们想了解是否存在这种情况

a)这是预期的结果、我们应在外部电路上提供保护、以防这些事件发生。

b)是内核错误

c)是一些硬件错误

d)其他内容。

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    将 I2C 信号拉至 GND 绝对超出规格。 应避免这种情况。 您使用的是哪种 Linux 版本？
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我们使用4.4-bone-RT。 我们还在4.9 ti 和 bone 上对此进行了测试。
    我不太清楚 ARM 和 i2c 外设之间的工作原理。 这种事件是否会产生停止 CPU 的不可恢复硬件故障(或者更好地说只能通过复位恢复)？
    或者内核可能仍在运行？

    谢谢、

    Leo

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您能否尝试使用 TI 提供的 Processor SDK： www.ti.com/.../PROCESSOR-SDK-AM335X ？ 我们不支持您使用的版本。
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我安装了最新的 LTS TI 内核。 它确实改变了一些东西、例如：

    usr0 LED 仍在跳动。

    我无法再通过以太网进行连接、但通过电路板顶部的串行接口、我可以获得：

    [532.175272] NMI 看门狗：错误：软锁定- CPU#0持续22秒！ [IRQ/160-4819c00：77]

    那么、我想仍然希望这个错误可以通过软件解决吗？

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我已要求软件团队查看这一点。 他们将在这里作出回应。
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    在硬件方面、我们的一位专家认为您可能会进入时钟拉伸的状态。 有关详细信息、请参阅 AM335x TRM 修订版 P 的第21.3.8节。
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Leonardo、

    发生这种情况时、您能否提供示波器跟踪？ 这听起来像是硬件问题。 I2C 非常基本、并且由于 cpufreq 驱动器在不断变化的负载条件下更改 CPU 频率时调整 PMIC 电压、I2C 变得越来越普遍。 如果 I2C 有错误，我们会看到更多的问题，但任何事情都是可能的：)

    您能否提供一些有关 IO 扩展器以及如何将其连接到 BeagleBone 的信息？


    此致、
    Mike

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Mike：

    示波器跟踪的问题是、有时很难获得准确的时刻(我们必须确定是否有具有良好缓冲的数字示波器)。  我们设法通过数字分析仪保存信号聊天。 或者您是否还需要张力值？

    i2c 器件是 http://www.horter.de/doku/i2c-hs-output_db.pdf。

    关于时钟拉伸、这似乎是一个可能的原因。 降低 i2c 时钟速度似乎无法实现这种冻结。

    我们认为器件的 i2c 问题与将 sda/scl 引至地面时的问题相同、这只是因为结果(内核冻结)。  

    我们使用多个 Beaglebones 对其进行了测试。  我们非常希望找到一个不会冻结 Linux 内核的解决方案。  

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    通过使用更多 i2c 调试消息编译内核来生成更多日志。

    [680.885766] systemd-journald[118]：/dev/kmsg 缓冲区溢出，一些消息丢失。
    [680.917773] systemd-journald[118]：/dev/kmsg 缓冲区溢出，一些消息丢失。
    [683.490351] i2c i2c-2：SCL 卡在低电平、退出恢复
    [685.014028]已启动：RT 节流已激活

    然后：


    [984.154020] NMI 安全装置：错误：软锁定- CPU#0卡在22秒！ [IRQ/160-4819c00：83]
    [984.161973]链接的模块：PRU_rproc pruss_intc omap_ae_driver omap_sham pruss_rng rng_core evdev uio_pdrv_genirq uio 8021q GARP MRP STP LLC bnep usb_f_nDIS u_serial USB_f_ECM USB_f_rab_ru 蓝牙复合材料
    [984.183002] CPU：0 PID：83 Comm：IRQ/160-4819c00被污染：G L 4.4.6.68-ti-r108 #9
    [984.191473]硬件名称：通用 AM33XX (平展器件树)
    [984.197591]任务：dc3b8680 ti：dc514000 task.ti：dc514000
    [984.203015] PC 位于 IRQ_finaling_OneShot.part.1+0xa4/0x110
    [984.208611] LR 位于 IRQ_GC_UNMASK_ENABLE_REG+0x7c/0x8c
    [984.213858]电脑:[ ] LR：[ ] PSR：600f0113
    [984.213858] sp：dc515ed0 IP：dc515e98 FP：dc515eec
    [984.225383] R10：c00a9508 R9：dc4acfc0 R8：dc209cc0
    [984.230628] r7：dc209cd0 r6：dc209d28 r5：dc4acfc0 r4：dc209cc0
    [984.237181] r3：dc00d074 r2：dc209cc0 r1：fa200000 r0：dc00d024
    [984.243735]标志：模式 SVC_32 ISA ARM 段无时 FIQ 上的 nZCv IRQ
    [984.250900]控制：10c5387d 表：9c728019 DAC：00000051
    [984.256670] CPU：0 PID：83 Comm：IRQ/160-4819c00被污染：G L 4.4.6.68-ti-r108 #9
    [984.265141]硬件名称：通用 AM33XX (平展器件树)
    [984.271265][ ](展开回扫)从[ ](show_stack+0x20/0x24)
    [984.279045][ ](show_stack)从[ ](dump_stack+0x8c/0xa0)
    [984.286303][ ](dump_stack)从[ ](show_regs+0x1c/0x20)
    [984.293475][ ](show_regs)从[ ](安全装置定时器_fn+0x244/0x2ac)
    [984.301431][ ](watchdog_timer_fn)、来自[ ](_hrtimer_run_queues+0x1b8/0x398)
    [984.310345][ ](_hrtimer_run_queue)、来自[ ](hrtimer_interrupt+0xd4/0x23c)
    [984.319174][ ](hrtimer_interrupt)、来自[ ](OMAP2_gp_timer_interrupt+0x38/0x40)
    [984.328263][ ](OMAP2_gp_timer_interrupt)、来自[ ](handle_irq_event_perpu + 0xac/0x2b0)
    [984.337963][ ](handle_irq_event_perpu)、来自[ ](handle_IRQ_EVENT+0x54/0x78)
    [984.346877][ ](handle_irq_event)从[ ](handle_level_IRQ+b8/0x150)
    [984.355268][ ](handle_level_IRQ)、来自[ ](generic_handle_IRQ+0x34/0x44)
    [984.363745][ ](generic_handle_IRQ)、来自[ ](_handle_domain_IRQ+0x6c/0xc4)
    [984.372484][ ](_handle_domain_IRQ)、来自[ ](OMAP-INTC_Handle_IRQ+0x44/0xa0)
    [984.381396][ ](OMAP-INTC_Handle_IRQ)、来自[ ](_IRQ_Svc+0x54/0x70)
    [984.389431]异常堆栈(0xdc515e80至0xdc515ec8)
    [984.394507] 5e80：dc00d024 fa200000 dc209cc0 dc00d074 dc209cc0 dc4acfc0 dc209d28 dc209cd0
    [984.402722] 5ea0：dc209cc0 dc4acfc0 c00a9508 dc515eec dc515e98 dc515ed0 c00adf80 c00a949c
    [984.410933] 5ec0：600f0113 ffff
    [984.414439][ ](_IRQ_Svc)从[ ](IRQ_finaling_OneShot.part.1+0xa4/0x110)
    [984.423180][ ](IRQ_finaling_OneShot.part.1)、来自[ ](IRQ_THREAD_Fn+0x5c/0x64)
    [984.432181][ ](IRQ_THREAD_Fn)、来自[ ](IRQ_THREAD+0x170/0x234)
    [984.439875][ ](IRQ_THread)、来自[ ](kthread+0x118/0x130)
    [984.447044][ ](kthread)、来自[ ](RET_FANK_F叉+0x14/0x34)

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    更新：

    即使放置示波器也会产生类似的问题。 因此、我考虑了将一个小电容电路连接到 SCL。 现在发生的只是冻结。 总是一样的。 控制器超时、内核会尝试恢复。 在恢复过程中(我仍在使用 printk)启用 RT 节流、然后无延迟调用(看起来是死锁的来源) omap_i2c_xfer。

    我不知道我是否给了你足够的信息。 我们将向您发送范围跟踪、并尝试使用另一种类似方案的架构、以查看是否需要此行为。

    我们肯定会更好地设计 i2c 总线、尽管我们发现 Linux 内核的运行方式有点奇怪。

    感谢您的工作、

    莱昂纳多

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！  

    我要发布一些跟踪。

    标题：SCL、100kHz 示波器1x、i2c2。 没有外部上拉电阻器、仅在内部。  

    标题：SDA/SCL 400kHz、无外部上拉

    注释：在这种情况下、内核对总线中发生的情况非常敏感。 如果由于上升时间或在总线上放置一个60pF 电容器而使其拉伸过大、 则会在轮询 i2c 总线时立即导致冻结。

    标题：SDA (绿色)/SCL (黄色)、4K 欧姆外部上拉、100kHz  

    注释： 上升时间现在是"固定的"、甚至放置一个电容器来施加电压 i2c 使波形稳定。 轮询时无死锁。

    结论：
    似乎确实存在一个通信问题。 说过、我仍然不知道内核是否会因"不良通信"而完全冻结。  


    你怎么看？

    谢谢、


    莱昂纳多

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Leonardo、

    根据规范(http://www.nxp.com/documents/user_manual/UM10204.pdf)、I2C 线路上需要强大的外部上拉电阻。  在我们的 EVM 上、我们通常具有2K 欧姆的值。  内核驱动程序可能会根据正确的总线行为做出一些假设、但听起来您的问题现在已经解决了。

    TI 提供了一份应用手册、可帮助您计算系统的值：  

    在编写 Linux 内核驱动程序时、可能假设这些电阻器已就位、否则为 i

    此致、
    Mike

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    我对非 RT 内核 linux-image-4.4.68-ti-r115有完全相同的问题。 我的 i2c 网络有噪声、总线扩展器有时会触发此问题。

    我成功地在实验中复制了问题、并在代码中添加了一些调试消息。 发生这种情况时、OMAP 似乎会生成 OMAP_I2C_STAT_XRDY。 由于 OMAP 处于接收器模式、因此永远不会正确处理中断。 然后、它领导中断环路。

    在中断处理程序中注释掉接收器模式检查时、我不再能够在实验中重现问题。

    diff --git a/drivers/i2c/Bus/i2c-omap.c b/drivers/i2c/Bus/i2c-omap.c
    索引 ab1279b.65496c1 100644
    -- a/drivers/i2c/bis/i2c-omap.c
    ++ b/drivers/i2c/Bus/i2c-omap.c
    @@-1017、10 +1017、12 @@ OMAP-i2c_ISR_thread (int this_IRQ、void * dev_id)
    STAT &=位；

    /*如果我们处于接收器模式，请忽略 XDR/XRDY */
    + /*
    IF (OMAP->接收器)
    STAT &=~(OMAP-I2C_STAT_XDR | OMAP-I2C_STAT_XRDY)；
    其他
    STAT &=~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY)；
    + *

    如果(！stat)｛
    /*我在这里的工作已经完成了*/
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    感谢您的回答和工作！ 我将尽快尝试测试此补丁。

    此修补程序是否会添加到内核中？

    -l

  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    我不是来自 TI。 TI 的一些人可能会评论为什么5年前添加了此代码。
    github.com/.../079d8af24b948261e1dae5d7df6b31b7bf205cb4

    这以前也有过注意、但 Linux 内核树中从未有过修补程序
    patchwork.kernel.org/.../

    Oskari
  • 0
    TI__Guru**** 2562340 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Oskari、

    感谢您深入了解这些补丁。

    根据提交日志、可能添加了代码以防止不必要的中断实际中断活动的 RX 或 TX。 如果您只需要删除代码、并且没有受到任何副作用、则可能会添加该代码来解决特定的临界情况。

    也就是说、您引用的第二个补丁可能更好/更正确。 我将在内部向我们的 Linux 团队提出这个问题。

    再次感谢、
    Mike