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.

[参考译文] AM5726:帮助解码与 C66 DSP 使用计时器 5 相关的 Linux 跟踪转储

Guru**** 2422790 points
Other Parts Discussed in Thread: AM5726

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1538329/am5726-help-decoding-linux-trace-dump-related-to-c66-dsp-use-of-timer-5

器件型号:AM5726


工具/软件:

大家好!

我正在将我们基于 AM5726 的产品从 VxWorks 迁移到 Linux (6.15)、一切进展顺利、但我遇到了一个问题、我突然发现我希望有人能提供一些线索。  我将 Yocto (scarthgap) 用于 Linux、所有内容都可以正常使用。  我们的产品使用一个 C66 DSP 器件、所有这些器件都能正常工作、但有一个例外。  我遇到的问题是 C66 应用程序(SYS/BIOS 应用程序)使用其中一个系统计时器(计时器 5)、但当我在 C66 应用程序中启用该计时器时、即使我实际上没有启动计时器、Linux 也会中断。  例如、 仅仅执行 SYS/BIOS Timer_create() 就会导致该问题。  下面粘贴了 Linux 系统控制台上显示的内容。  在这次移植冒险中,我已经多次看到这种事情和其他事情,它似乎总是与两件事之一有关。  要么未启用从 DSP 访问的模块、但通常通过将正确的信息输入 DTS 来修复此问题。  或者、该问题是由于 DSP 资源表中没有 DSP 处理器试图访问的范围的条目、而通过向资源表中添加条目可以轻松解决该问题。  我对 Linux 显示的信息的主要问题是如何解释显示的内容。  具体来说、是否有方法可以确定 DSP 试图访问导致打印信息的地址。  下面的信息显示了 DSP 尝试读取 L4_PER3_P3 上的某些内容、但 L4_PER3_P3 上有许多模块。  我想知道的是、所显示的信息中是否有任何内容可用于确定正在访问的该互连上的实际模块?  此外、是否有办法可以知道中断的原因是 DSP 资源表中缺少条目导致的、还是模块未启用的结果?  下面蓝色突出显示的文本表明 DSP 尝试通过其 MDMA 器件(通过 IOMMU0)从 L4_PER3_P3 互连上的内容读取。  以绿色突出显示的部分通常是我在尝试访问未启用的模块时看到的部分。  这是对该案文的正确解释吗?  任何人都可以提供的指导的 TIA。

[829.434143]----- 【在这里剪切】------
[829.438781]警告:CPU:0 PID:0、位于/drivers/bus/omap_l3_noc.c:138 L3_INTERRUPT_HANDLER+0x348/0x394
[ 829.448059] 44000000.L3-NOC:L3 自定义错误:主设备 DSP1_MDMA 目标 L4_PER3_P3(读取)功能访问期间用户模式下的数据访问
[829.460449]模块链接于:
[829.463531] CPU: 0 PID: 0 Comm: swapper/0 tainted: g W 6.1.80-ti #1.
[829.471221]硬件名称:通用 DRA74X(平展设备树)
[ 829.477355]从 show_stack+0x18/0x1c 展开 funy_backtrace
[ 829.482635]从 dump_stack_lvl+0x40/0x4c 的 show_stack
[829.487701] dump_stack_lvl(来自__warn+0x80/0x150)
[829.492553]来自 WARN_SLOWPATH_fmt+0x1f8/0x200 的__warn
[ 829.497711]来自 L3_INTERRUPT_HANDLER+0x348/0x394 的 WARN_SLOWPATH_Fmt
[ 829.504119]来自__handle_irq_event_percentpu+0x5c/0x204 的 L3_interrupt_handler
[ 829.511108]来自 handle_IRQ_EVENC+0x40/0x88 的__handle_IRQ_EVENT_percpu
[829.517700] handle_fasteoi_irq+0xbc/0x224 中的 handle_irq_event
[829.523742] generic_handle_domain_IRQ+0x30/0x40 中的 handle_fasteoi_irq
[829.530487] generic_handle_domain_irq from GIC_Handle_IRQ+0x6c/0x80
[829.536895] generic_handle_arch_IRQ+0x58/0x78 中的 GIC_HANDLE_IRQ
[829.543121] generic_handle_arch_IRQ 来自__IRQ_svc+0x88/0xc8
[ 829.548889]异常堆栈 (0xc1701ef0 至 0xc1701f38)
[829.553985] 1ee0:00000000 00000000 fe600000 00000000
[829.562194] 1f00:c170fa00 c170fa00 c170b090 c170b0f0 00000000 c16c7ee8 00000000 c1407bb4
[829.570434] 1f20:FFFFFFFF c1701f40 c012714c c0109214 600f0013 ffffffff
[829.577056]来自 arch_cpu_idle+0x28/0x44 的__irq_svc
[ 829.582000]从 default_idle_call+0x34/0x11c 中设置 arch_cpu_idle
[829.587677] do_idle+0x218/0x2ac 中的 default_idle_call
[ 829.592956]从 CPU_STARTUP_ENTRY+0x30/0x34 执行 DO_IDLE
[ 829.598022]来自 REST_INIT_+0xd8/0xdc 的 CPU_startup_entry
[829.603302]来自 arch_post_acpi_Subsys_init+0x0/0x18 的 REST_init
[829.609252]--[结束跟踪 000000000000 ]-----
[829.613922] L3_Handle_target (c3b95dc0、f0500000、c1803a64、1b)
[829.619781] L3_Handle_target:base=f0500e00、tm=f0500e68、th = f0500e6c、ti=f0500e64
[829.627410] 【在这里剪切】------

Mike Lynch

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

    您好 Mike:

    我会看一下。 您说过在尝试使用计时器 5 时会发生这种情况吗? 这可能已经被 Linux 使用了吗? 您是否检查过是否存在任何冲突?

    -Josue