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.

[参考译文] AM5728:未处理故障:异步外部中止(0x1211)

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1200431/am5728-unhandled-fault-asynchronous-external-abort-0x1211

器件型号:AM5728

您好!

我的客户报告了 CPU 执行 strexd 指令时的"Unhandled FAULT:异步外部中止(0x1211)"。
出现问题;
-在任何板上。
-只要函数 SYS_Atomic_compare_and_SWAP64 (pSrc、OLD_VALUE、OLD_VALUE、RESULT)、就会执行;
-上述函数对映射在 0x1600_0000到0x161F_4FFF (物理地址)的 MRAM 的访问。
-使用其他功能的 MRAM 访问工作正常。  
-使用 RT-Linux SDK (内核版本为4.19 )。

这是 DBG 日志。

Thread 17 "BlkDrvUdp" received signal SIGBUS, Bus error.
[Switching to Thread 0xb04fe460 (LWP 507)]
0x002fc384 in SysCpuReadInt64 (pResult=<optimized out>, pSrc=<optimized out>) at ../../../Components/SysCpuHandling/SysCpuHandling.c:340
340     ../../../Components/SysCpuHandling/SysCpuHandling.c: No such file or directory.
(gdb) bt
#0  0x002fc384 in SysCpuReadInt64 (pResult=<optimized out>, pSrc=<optimized out>) at ../../../Components/SysCpuHandling/SysCpuHandling.c:340
#1  SysCpuReadInt64 (pResult=<synthetic pointer>, pSrc=0xb1eb4018) at ../../../Components/SysCpuHandling/SysCpuHandling.c:309
#2  SysCpuReadValueAtomic (pSrc=pSrc@entry=0xb1eb4018, pDest=0xb04fcf98, nLen=<optimized out>) at ../../../Components/SysCpuHandling/SysCpuHandling.c:634
#3  0x0018d1a6 in ReadValueAtomic (pDst=pDst@entry=0xb04fcf98, pSrc=pSrc@entry=0xb1eb4018, nLen=8) at ../../../Components/CmpMonitor2/CmpMonitor2.c:640
#4  0x0018d29e in WriteReadValue (pData=0xb1eb4018 <error: Cannot access memory at address 0xb1eb4018>, pReadExp=0x0, pWriter=0xb04fd18c) at ../../../Components/CmpMonitor2/CmpMonitor2.c:702
#5  ExecuteReadExp (pApp=pApp@entry=0x420678 <s_StaticAppList+60>, pReadExp=pReadExp@entry=0xb04fd030, pWriter=pWriter@entry=0xb04fd18c) at ../../../Components/CmpMonitor2/CmpMonitor2.c:967
#6  0x0018d7e8 in ProcessReadExpList2 (pApp=<optimized out>, pWriter=0xb04fd18c, pReader=0xb04fd044) at ../../../Components/CmpMonitor2/CmpMonitor2.c:1030
#7  ProcessService (pduSendBuffer=..., pWriter=0xb04fd18c, pReader=0xb04fd044, pHeader=<optimized out>) at ../../../Components/CmpMonitor2/CmpMonitor2.c:1733
#8  Monitoring2ServiceHandler (ulChannelId=<optimized out>, pHeader=<optimized out>, pduData=..., pduSendBuffer=...) at ../../../Components/CmpMonitor2/CmpMonitor2.c:363
#9  0x002dba96 in ServerAppHandleRequest3 (ulChannelId=ulChannelId@entry=31296, pduRequest=..., pduReply=..., bFirstCall=1, bFirstCall@entry=1212875) at ../../../Components/CmpSrv/CmpSrv.c:612
#10 0x002d5682 in SecChServerHandleRequest (ui32ChannelHandle=ui32ChannelHandle@entry=31296, pduRequest=..., pduReply=..., bFirstCall=bFirstCall@entry=1) at ../../../Components/CmpSecureChannel/CmpSecureChannelServer.c:440
#11 0x001281ca in NetServerMessageReceived3 (pChBuffer=pChBuffer@entry=0xb490b010, pduData=..., bFirstCall=bFirstCall@entry=1) at ../../../Components/CmpChannelServer/CmpChannelServer.c:971
#12 0x0012736a in HandleL4DataPackage (pChBuffer=0xb490b010, nSize=256, pDataPkg=<optimized out>, addrSender=...) at ../../../Components/CmpChannelMgr/CmpChannelMgr.c:839
#13 HandleL4Data (byPkgType=<optimized out>, pduData=..., addrSender=...) at ../../../Components/CmpChannelMgr/CmpChannelMgr.c:937
#14 ChannelMgrHandleData (hRouter=hRouter@entry=0xb4a01718, hNetworkInterface=hNetworkInterface@entry=0xffff, byServiceId=<optimized out>, byMessageId=<optimized out>, addrSender=..., addrReceiver=..., pduData=..., nRouterError=0)
    at ../../../Components/CmpChannelMgr/CmpChannelMgr.c:1690
#15 0x002cd300 in HandleLocally (pRouter=pRouter@entry=0xb4a01718, pniSender=pniSender@entry=0xb4a01718, pnaSender=pnaSender@entry=0xb04fd9a0, pHeader=pHeader@entry=0xb04fda58, pduContent=..., addrSender=..., addrReceiver=...)
    at ../../../Components/CmpRouter/CmpRouter.c:785
#16 0x002cee38 in RoutePackage (pRouter=0xb4a01718, pNetworkSender=pNetworkSender@entry=0xb4a01718, addrReceiver=..., addrSender=..., naSender=..., pduData=..., nDataOffset=2, bUseQueue=-1263770880) at ../../../Components/CmpRouter/CmpRouter.c:1409
#17 0x002cf530 in RouterHandleData (hNetwork=<optimized out>, naSender=..., pduData=..., bIsBroadcast=bIsBroadcast@entry=0) at ../../../Components/CmpRouter/CmpRouter.c:2156
#18 0x000b7eba in UdpReceiveBlock (iDev=<optimized out>, iDev@entry=0, iCount=iCount@entry=2, pfdDataAvailable=pfdDataAvailable@entry=0xb04fdd14) at ../../../Components/CmpBlkDrvUdp/CmpBlkDrvUdp.c:563
#19 0x000b7f4a in UdpReceiveBlocks (pfdDataAvailable=pfdDataAvailable@entry=0xb04fdd14) at ../../../Components/CmpBlkDrvUdp/CmpBlkDrvUdp.c:583
#20 0x000b88f4 in CommunicationThread (ptp=0x51751c <s_StaticTaskList+3204>) at ../../../Components/CmpBlkDrvUdp/CmpBlkDrvUdp.c:393
#21 0x003137f8 in SysTaskFrame (pTask=0x517510 <s_StaticTaskList+3192>) at ../Sys/SysTaskLinux.c:439
#22 0xb4d5fb00 in start_thread (arg=0xaeeece45) at pthread_create.c:486
#23 0xb4cd42fc in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


 SYS_Atomic_compare_and_SWAP64 ()位于 SysCpuHandling.c 的第340行
e2e.ti.com/.../SysCpuHandling.c

反汇编代码:
(gdb) disassemble/m
Dump of assembler code for function SysCpuReadValueAtomic:
309     RTS_I64 CDECL SysCpuReadInt64(RTS_I64 *pSrc, RTS_RESULT *pResult)

310     {
311             if (pSrc == NULL)

312             {
313                     RTS_SETRESULT(pResult, ERR_PARAMETER);
314                     return 0;
315             }
316
317     #if SYSCPU_ALIGNMENT_CHECK_64 > 1
318             /* Check alignment, atomic assignment is only possible if pSrc is aligned to allowed boundary */
319             if (((RTS_UINTPTR)pSrc % SYSCPU_ALIGNMENT_CHECK_64) != 0)

320             {
321                     RTS_SETRESULT(pResult, ERR_ALIGNMENT);
322                     return 0;
323             }
324     #endif
325
326     #if defined(TRG_64BIT)
327             /* on 64bit targets, the atomic assignment is always assured */
328             RTS_SETRESULT(pResult, ERR_OK);
329             return *pSrc;
330     #else
331             #ifdef SYS_ATOMIC_COMPARE_AND_SWAP64
332             {
333                     /* use operating system function if available */
334                     RTS_RESULT result;
335                     RTS_I64 old_value = 0;
336
337                     do

338                     {
339                             old_value = *pSrc;
   0x002fc370 <+44>:    ldrd    r6, r7, [r0]

340                             SYS_ATOMIC_COMPARE_AND_SWAP64(pSrc, old_value, old_value, result);
   0x002fc374 <+48>:    dmb     ish
   0x002fc378 <+52>:    ldrexd  r4, r5, [r0]
   0x002fc37c <+56>:    cmp     r5, r7
   0x002fc37e <+58>:    it      eq
   0x002fc380 <+60>:    cmpeq   r4, r6
   0x002fc382 <+62>:    bne.n   0x2fc38c <SysCpuReadValueAtomic+72>
=> 0x002fc384 <+64>:    strexd  r1, r6, r7, [r0]
   0x002fc388 <+68>:    cmp     r1, #0
   0x002fc38a <+70>:    bne.n   0x2fc378 <SysCpuReadValueAtomic+52>
   0x002fc38c <+72>:    dmb     ish
   0x002fc390 <+76>:    bne.n   0x2fc370 <SysCpuReadValueAtomic+44>
   0x002fc392 <+78>:    mov     r4, sp
   0x002fc394 <+80>:    strd    r6, r7, [sp]


信息寄存器:
R0值为 0xb1eb4018。  
(gdb) info registers
r0             0xb1eb4018          2984984600
r1             0xb04fcf98          2958020504
r2             0x0                 0
r3             0xb04fcf98          2958020504
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x366fa8            3567528
r9             0xf095d44e          4036351054
r10            0xb04fd0d8          2958020824
r11            0x3a88              14984
r12            0x3f6178            4153720
sp             0xb04fcda0          0xb04fcda0
lr             0x18d1a7            1626535
pc             0x2fc384            0x2fc384 <SysCpuReadValueAtomic+64>
cpsr           0x60010030          1610678320
fpscr          0x0                 0


存储器映射:  
0xb1eb_4000映射到0x1600_1000 (物理地址)
root@HX-SDC:/proc/2030# cat maps | grep mem
b0e0c000-b0e0d000 rwxs 4a002000 00:06 8957       /dev/mem
b1eb4000-b20a8000 rwxs 16001000 00:06 8957       /dev/mem
b20c9000-b20ca000 rwxs 16000000 00:06 8957       /dev/mem
b20ca000-b20cb000 rwxs 16000000 00:06 8957       /dev/mem
b419a000-b421a000 rwxs 18100000 00:06 8957       /dev/mem
b4b07000-b4b08000 rwxs 17001000 00:06 8957       /dev/mem
b4b08000-b4b09000 r-xs 17001000 00:06 8957       /dev/mem
b4b09000-b4b0b000 r-xs 1801c000 00:06 8957       /dev/mem
b4b0b000-b4b0d000 r-xs 1800c000 00:06 8957       /dev/mem
b4b0d000-b4b0f000 rwxs 1801e000 00:06 8957       /dev/mem
b4b0f000-b4b11000 rwxs 1800e000 00:06 8957       /dev/mem
b4b11000-b4b13000 rwxs 18014000 00:06 8957       /dev/mem
b4b13000-b4b15000 rwxs 18004000 00:06 8957       /dev/mem
b6f22000-b6f24000 rwxs 18016000 00:06 8957       /dev/mem
b6f24000-b6f26000 rwxs 18006000 00:06 8957       /dev/mem


Question:
-"未处理故障:异步外部中止(0x1211)"是什么意思?
-问题的潜在原因是什么?

谢谢。此致、
田代浩一郎

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

    您好!

    是否有此项目的任何更新?

    供参考。 客户已测试是否因原子访问而导致问题。
    这是他们使用的测试代码。 它对 DDR 或 GPMC (MRAM 已连接)进行32位和64位原子访问。
    e2e.ti.com/.../debug-code.txt
    及其反汇编代码:
    e2e.ti.com/.../disassemble.txt

    测试结果如下所示:
    e2e.ti.com/.../8741.result.txt
    请注意、客户有非常类似的使用 AM437x 和 AM572x 的产品。
    在 result.txt 可以看到、AM437x 上的原子访问是可以接受的。
    在 AM572x 上、对 DDR 的原子访问没问题、但对 GPMC 的访问导致了总线错误。

    谢谢。此致、
    田代浩一郎  

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

    您好!

    ARM 专属操作、如  strex/ldrex/... (以及 VFP 和对齐修复等其他操作)仅在使用"正常"类型的 MMU 存储器属性定义的地址范围时定义。   如果客户尝试针对 "trongly ordered、device"的 MMU 属性执行用户级代码、则结果未定义。  这是 ARMv7架构标准的一部分。  对于这些"未定义"区域、不同的 ARM 内核实现具有不同的行为。  例如、使用 NEON 或 VFP 的 Cortex-A8 u-boot 通常只会返回错误的答案、其中 Cortex-A9或 A15会引发中止。

    在非正常存储器上使用排他性(和一些其他常见操作码/指令)是不安全的。

    在独占 运算的情况下、它们仅在与 "正常-非缓存-复制-回放"的归属 存储器配合使用时才会作为 ARM TRM 的行为。  这是执行 'SMP' Linux 代码时所需使用的存储器类型。  A15高速缓存实现了一个本地监视器 、可在2个 A15内部共享 CPU 之间提供安全锁定。   对于其他存储器类型、独占函数不会发生、而对于正常的非缓存类型、该函数会转换为正常的加载/存储。   对于器件或严格排序类型、结果不可预计(它可能是错误的操作或中止)。

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

    尊敬的伍德鲁夫先生:  

    感谢您的发帖。

     

    您的帖子有3个问题。

    请您回答以下问题吗?

    1.

    当对 MRAM 执行原子指令(strex)时、会发生异步外部中止。

    MRAM 是由 Everspin (MR4A16BCMA35 EverspinTechnologies | Mouser Japan)制造的 MR4A16BCMA35

    MRAM 通过 FPGA 连接至 GPMC。

    是否可以将"normal"设置为 MMU 内存属性?

    2.

    我们的以下理解是否正确?

    - MMU 内存属性由 Linux 设置。

    -为除 Linux 管理的 RAM 区域之外的存储器设备设置"严格排序"或"设备"。

    3.

    "'normal-non-cached-copy-back-shared' assigned memory"的含义是什么?

    我们假设 MMU 属性列在以下 URL 中。

    https://developer.arm.com/documentation/den0013/d/The-Memory-Management-Unit/Memory-attributes/Memory-types

    "normal-non-cached-copy-back-shared"与哪一个对应?

    此致、  
    SUDOH 正义

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

    您好!

    有问题时:

    -1-

    MMU 内存属性的设置在很大程度上与备用内存类型无关。  这些设置需要通过 Linux MM API 来完成。  通常、我使用属于 Lauterbach 调试器的 MMU 解码器来检查实际属性。  使用调试器命令"mmmu.info +扫描将完全解码已分配的 ARM 属性。

    对于任何要执行 ARM 指令的备用存储器(本例中为 GPMC + FPGA -> MRMAM)、它必须能够处理 ARM 可能发出的总线事务。  例如、为了使器件能够在 ARM 缓存访问时正常工作、但必须支持换行和递增突发类型。  如果 GPMC-FPGA 插接不允许这样、您需要限制从 ARM 使用的映射类型、另外您可能还需要限制与内存结合使用的某些 ARM 指令/操作码。  

    -2-

    正确,MMU 属性由 Linux 指派。  它的分配方式会因 BSP 的实施细节而异。

    严格排序或器件、由 Linux 用于 IO 区域。  这些区域有 ARM 通用使用约束、在 ARM Arch 手册中进行了定义。  CPU 通常可能会读取和写入大小固定的大小、但不会执行缓存的(指令或数据)操作。  其他常见的 ARM 方法、如重新排序、可被抑制到这些存储器类型。  它们不是通用的、也不像"正常"存储器提供的那样提供完全的用户指令用法。

    -3-

    您引用的表显示单个属性。  "Normal-on-cached-copy-back-shared"是这些属性的有效分组的串联。 您可以将程序员参考指南中提供的摘要和 ARM 架构参考指南中的详细信息展开。  理解 Linux 如何映射到这些指令(在不同的 API 级别上实现)可能很难理解、因为有许多(有时会更改)层的抽象、并且并不是所有的 ARM 选项都被导出。   如前所述、我使用 Lauterbach 的 TRACE32调试器作为一种方法、可以对终端状态进行可信的解码。  手动执行此操作可能需要很长时间、并且容易出错。  手动操作需要大量咨询 ARM Arch 参考手册。  此操作超出了 TI-E2E 的范围。

    此致、
    理查德·W·