[参考译文] 编译器/AM3358：错误的TI-CGT-PRU_JAL 2.1 ........4 (和JMP 2)：2.1 和JAL转发引用的标签或寄存器参数时出错

此问题是否与不正确的链接程序命令文件有关？ 只是一个想法。 我正在使用提供的AM3359_PRU.cmd文件。

此外，请准确描述您如何知道跳转指令操作不当。  您在看什么？  您到底是怎么做的？

谢谢，此致，

-George

我花了一整天时间观察JMP和JAL两个说明的变化操作。 下面是.lst文件的一个片段，演示了这些指令的几种变体的编码。 一些初始内嵌汇编程序代码功能充分，因此我可以将数据写入PRU共享RAM并从ARM访问这些数据，然后直观地访问stdio测试套件。 我能够在分支地址验证代码执行情况。 JMP和JAL说明的任何版本都不能正确执行。 我可以使用QBA在JMP/JAL测试使用的相同标签上成功分行。 使用PASM组装时，原始汇编代码将正确执行。

    292.
    293;**************************************                                
    294                               ；调用.macro dst
    295;                                     JAL    callReg．w2，DST
    296                               ；      .endm
    297；                                
    298                               ；其中，'callReg’被定义为'r3.w2'，即
    299；                                
    300                               ；#define callReg      R3
    301                               ；      %｝
    302                               ；**************************************
    303.
    304       ；QBA           IET_CMR0_ISR +8.
    305                               ；--
    3.06亿 000001b80000002100BC00         JMP            0x2f0
    307                               ；--
    3.08亿bc 00000021000000！         JMP            IET_CMR0_ISR
    309                               ;--高于IET_CMR0_ISR =0x2f0
    3.1亿 000001c000000020 00000020E9万         JMP            regVal
#                                         JMP            R9.
    311                               ;--高于regVal = 0x20c
    3.12亿c4                        致电   IET_CMR0_ISR
100.0001万       000001c400万 00000023万C3！         日航            callReg．w2，美国夏令时
#                                         JAL            R3.w2，IET_CMR0_ISR
PRU汇编器Unix v 2.1 42017年1月21日21：36：25星期六

工具版权所有(c) 2012-2015 Texas2015 Texas Instruments Incorporated
/home/brendan/ti-CGT-PRU_ASM.4/example/PRU_hardI2C_IET_Interrupt.asm 2.1 第  13页

    313                               ;--高于IET_CMR0_ISR =0x2f0
    3.14亿c8                        呼叫   0x2f0
100.0001万       000001c80000002300BCC3         JAL            callReG.w2，美国夏令时
#                                         JAL            R3.w2，0x2f0
    315                                 
    3.16亿cc 0万230000C3！23万！         JAL            R3.w2，IET_CMR0_ISR
    317                               ;--高于IET_CMR0_ISR =0x2f0
    3.18亿 000001d00000002300BCC3         JAL            R3.w2，0x2f0
    319                               ;------------------

。

。

。

    3.29亿f0                ISR_JMP64_TABLE：
    3.3亿 000001f0万 0000002100万！         JMP            core_loop
    3.31亿 000001f400万 0000002100万！         JMP            core_loop
    3.32亿 000001f800万 0000002100万！         JMP            core_loop
    3.33亿fc 00000021000000！         JMP            core_loop
    3.34亿 0000020万 0000002100万！         JMP            core_loop
    3.35亿 000002400万 0000002100万！         JMP            core_loop
    3.36亿 000002800万 0000002100万！         JMP            core_loop
    3.37亿0c 00000021000000！         JMP            IET_CMR0_ISR   ；ISR
    3.38亿 0000021000万 0000002100万！         JMP            core_loop
    3.39亿 0000021400万 0000002100万！         JMP            core_loop

广泛的验证活动表明，日航指令的标签参数中减去了0x40 (64字节)的偏移量。

例如，说明：

JAL   R3.w2，my_label

实际表现为：

JAL   R3.w2，my_label - 0x40

您向我们展示的是汇编程序为可重定位目标文件输出的列表文件，而不是可执行文件。  根据PRU汇编语言工具用户指南，! 操作码末尾的重定位指示符表示未定义的外部引用，这意味着这些零字段中的某些字段将在链接时填充。  请参阅上的PRU Assembly Language Tools User's Guide (PRU汇编语言工具用户指南)

http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals

例如，标记为ISR_JMP64_TABLE的表有一组具有完全相同操作码的指令，该操作码只是JMP IMM的操作码，没有实际目的地值。  至于列表第306行的说明，在组装时目的地是已知的，因此它出现在操作码中，并且没有重定位字符。

单凭商品信息文件不足以深入了解此问题。 我们还需要从ofdpru提供的目标文件转储重定位表。 但是，最好是查看可执行文件的反汇编。 如果您想确定，请发送给我们：

1. 链接程序映射文件(链接程序选项--map_file)
2. 可执行文件(通常命名为homething.out)

或

1. 链接程序映射文件(链接程序选项--map_file)
2. ofdpru -v something.out的完整输出
3. dispru simeting.out的完整输出

JMP指令不应在执行过程中减去任何内容。  JMP IMM指令中有一个16位字段，该值乘以4得到实际的绝对地址。

就我而言，我从未明确采取任何行动来迁移任何代码。 当使用PASM组装时，所有相关代码都能完美地工作。 TI clpru汇编器的使用在这里是唯一不同的，尝试转换的唯一原因是为了让我可以使用PRU C/C++编译器。

好吧，这是pasm和clpru之间的一个主要区别：使用clpru，您必须链接代码才能生成可执行文件。  链接执行重新安置和安置。

clpru命令行包含--run_linker命令，因此您正在链接程序。  您正在使用--output_file选项，因此您的可执行文件名为$build_root/ti-CGT-PRU_PRU.4/example/PRU_hardI2C_IET_Interrupti.bin 2.1 ；这就是我们需要检查的文件。

链接器输出文件的名称不相关；更改名称不会更改输出类型。  链接程序生成一个目标文件；通常是一个绝对的，可执行的目标文件。  PRU仅支持ELF，因此幻数应为(十六进制) 7f 45 4c 46或"^？ELF"。

请在.bin文件上运行ofdpru -v，并显示"对象文件信息"部分。  应如下所示：

对象文件信息

文件名： A.退出
格式： ELF版本1
文件类型： 可执行文件
机器： TI PRU
机器端数： 小Endian
入口点： 0x0.5538万
供应商： 德州仪器(TI)
生产商： 链接器
链接器版本： 2.2 .................0
章节数：28
文件长度： 24.6508万
ELF类： 32位对象
elf e_flags： 0x0万

   文件名：          PRU_hardI2C_IET_Interrupt.bin
   格式：             ELF版本1                
   文件类型：          可执行文件              
   机器：            TI PRU                       
   机器端心：     小端心                
   入口点：        0x0万                   
   供应商：             Texas Instruments，Inc.      
   Producer：           linker                       
   链接器版本：2.1     .................................4.                        
   章节数： 148                          
   文件长度：        2.0784万                        
   Elf类：          32位对象               
   elf e_flags：        0x0万          

Brendan Graham 说：

文本"File Offset: 0x0.0034万"

这是可执行文件中开始.text部分内容的字节位置。  请注意，这不是PRU内存中.text的地址。  这由运行地址表示，即0。

谢谢，此致，

-George

在.ofd文件中，不在初始.text节之前指定任何.align指令，也不等效于

对齐0x0

文本

如以下摘录所示，文件偏移为0x34

<2>".text"

加载地址：0x0万运行地址：0x0万

大小：0x134对齐：64

加载到设备：是地址单元大小：8位

文件偏移：0x0.0034万 # Relocs: 0

书帖类型：SHT_PROGBITS页面：0

elf sh_flags：0x0.0006万 ELF sh_flag：SHF_ALLOC

elf sh_flag：SHF_EXECINSTR TI ext_flags：0x0

在同一汇编代码.text部分中，进行了以下陈述

CLREN_INTS：

0.0068万 LDI R9.W0，0x0004；地址0xec处的SBCO指令长度

0.0006万c LDI R9.w2，0x55aa

0.007万 JAL R3.w2，CLREN_INTR + 0x20；正在测试的分支指令

;@呼叫地址+“测试偏移”(0x20)

0.0074万 SBCO &R9，C28，4*6，4；指令@呼叫地址+ 0x4

;“返回地址”(0x0.0074万)

。 。 .这里有一些代码

0万cc添加R9，R9，4

0万d0添加r9，r9，4

0万d4添加r9，r9，4

0万d8添加r9，r9，4

0万dc添加r9，r9，4；地址0x70处的分支指令跳到此处！！！

0万e0添加r9，r9，4

0万e4添加R9，R9，4

0万e8添加r9，r9，4

0万ec SBCO &R9，C28，4*7，4；R9 = 0x55aa0014写入PRU/ARM共享RAM

;我们将R9.W0中的字节计数称为“残留”

CLREN_INTR：

0万f0和R24，R3，R3

0万f4 SBCO &R3，C28，4*8，4；R3 = 0x002a0000写入PRU/ARM共享RAM

; r3 =“实际返回地址”=(呼叫地址+0x4)/0x4

0万f8和R9，R24，R24

0万fc和R9，R24，R24

0.01万和R9，R24，R24

0.0104万和R9，R24，R24

0.0108万和R9，R24，R24

0.001万c和R9，R24，R24

0.011万和R9，R24，R24；地址0x70处的分支指令应该跳到这里！！！

0.0114万和R9，R24，R24

0.0118万和R9，R24，R24

0.0011万c和R9，R24，R24

0.012万和R9，R24，R24

0.0124万和R9，R24，R24

0.0128万和R9，R24，R24

0.0012万c和R3，R24，R24

0.013万 JMP R3.w2

前面明显错误的示例代码的结果可以用以下参数解释。 地址0x70处的分支指令应该分支到地址0x110，而是分支到地址0xdc。 我们知道这是因为地址0xec处的SBCO指令写入字节计数0x14 (0x14/4=5指令)，在地址0x70处执行分支指令后，从PC的地址开始计算。 直到标签CLREN_INTR被写入ARM共享内存并输出到stdio，寄存器R3.w2中存储的实际返回地址0x2a被写入ARM共享内存并输出到stdio。 因此，以下计算必须为真：

文件偏移量=测试偏移量+残留物

0x34 = 0x20 + 0x14

例如，如果.text部分显式对齐到偏移0x40，则为

对齐0x40

文本

然后验证计算结果是否也为真。

返回地址=实际返回地址+文件偏移量

0x2D*4 (0xb4)= 0x74 + 0x40

函数"prussdrv_PRU_write_memory(PRU_ram_id，0, code, codelen)"总是从偏移'0'(即文件的开头)加载二进制可执行文件。 PASM必须写入始终不带偏移的二进制文件。 因此，问题仍然是为什么clpru不删除二进制文件中的已知偏移。 但这是链接程序的任务，它可以根据entry_symbol与二进制文件开头的偏移来正确解析符号。 因此，clpru链接器似乎有缺陷。

github.com/.../prussdrv.c

｛｝

}

Brendan，

prussdrv用户空间库(以及UIO pruss内核驱动程序)用于加载PASM工具输出的二进制格式。

RemoteProc内核驱动程序能够加载由TI C编译器/汇编器输出的ELF二进制文件 ：http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg#Remoteproc

请参阅此e2e答案，了解如何将resource_table头(RemoteProc所需)添加到程序集文件：https://e2e.ti.com/support/arm/sitara_arm/f/791/p/44.704万/1608294#1608294</s>160.8294万 160.8294万

 有关如何使用RemoteProc驱动程序将固件加载到PRU的介绍，请参阅此实验操作： http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_4:_Introduction_to_Linux_driver

Jason Reeder

附注：或者，也可以通过一系列步骤将ELF二进制文件(从TI编译器/汇编器/链接器)转换为prussdrv库可以使用的格式。 但是，任何对prussdrv或PASM的支持都需要来自BeagleBoard社区，网址为 ：http://beagleboard.org/

Brendan，

这是否纠正了您的日航时差问题？ 或者问题是否仍然存在？

Jason Reeder