[参考译文] AM3359：PRU 器件树配置

admin

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/671247/am3359-pru-device-tree-configuration

器件型号：AM3359

您好！

尝试在 BeagleBone Black 上启动用于 PRU 的 Remoteproc 时遇到问题。我可以使用它、但只能使用 debian (4.4.8.88-ti-r125)、我需要使用自己的 Yocto Build (PROCESSOR-SDK-Linux-04.02.00提交： a75d8e93056181d512f6c818e8627bd4554aaf92)设置它。

debian 上的器件树(工作示例)是使用 capemanager 创建的、因此在启动后、我使用 DTC 从目录中使用"-in -format FS"选项反编译器件树以获得最终形式。

设备树：

此节点位于/OCP 中：

普劳斯@4a300000｛
REG =<0x4a300000 0x2000 0x4a302000 0x2000 0x4a310000 0x3000 0x4a326000 0x2000 0x4a32e000 0x31c 0x4a332000 0x58>；
reg-names ="dram0"、"dram1"、"shrdram2"、"cfg"、"IEP"、 "MII_RT"；
兼容="ti、am3352-pruss"；
范围；
状态="正常"；
#address-cells =<0x1>；
ti、hwmods ="pruss"；
相位=<0x23d>；
大小单元格=<0x1>；
linux、phandle =<0x23d>；

MDIO@4a332400｛
  REG =<0x4a332400 0x90>；
  兼容="ti、davinci_mdio"；
  时钟名称="Fck"；
  时钟=<0x12>；
  STATUS ="禁用"；
  #address-cells =<0x1>；
  bus_freq =<0xf4240>；
  phandle =<0xd5>；
  大小单元格=<0x0>；
  linux、phandle =<0xd5>；
}；

INTC@4a320000｛
  reg =<0x4a320000 0x2000>；
  中断=<0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1b>；
  reg-names ="intc"；
  兼容="ti、am3352-pruss-intc"；
  interrupt-names ="host2"、"host3"、"host4"、"host5"、"host6"、 "host7"、"host8"、"host9"；
  #interrupt-cells =<0x1>；
  相位=<0xD1>；
  中断控制器；
  Linux、phandle =<0xD1>；
}；

pru0@4a334000｛
  REG =<0x4a334000 0x2000 0x4a322000 0x400 0x4a322400 0x100>；
  中断=<0x10 0x11>；
  reg-names ="IRAM"、"control"、"debug"；
  兼容="ti、am3352-PRU"；
  中断名称="vring (振铃)"、"kick (启动)"；
  phandle =<0xd3>；
  linux、phandle =<0xd3>；
  中断父级=<0xD1>；
}；

pru1@4a338000｛
  REG =<0x4a338000 0x2000 0x4a324000 0x400 0x4a324400 0x100>；
  中断=<0x12 0x13>；
  reg-names ="IRAM"、"control"、"debug"；
  兼容="ti、am3352-PRU"；
  中断名称="vring (振铃)"、"kick (启动)"；
  phandle =<0xd4>；
  linux、phandle =<0xd4>；
  中断父级=<0xD1>；
}；
}；

另一方面、我从编译中获取的器件树如下所示(解编译的 DTB 文件)：

pruss_SoC_bus@4a326000｛
兼容="ti、am3356-pruss-so-bus"；
REG =<0x4a326000 0x2000>；
ti、hwmods ="pruss"；
#address-cells =<0x1>；
大小单元格=<0x1>；
范围；
状态="正常"；

普劳斯@4a300000｛
  兼容="ti、am3356-pruss"；
   REG =<0x4a300000 0x2000 0x4a302000 0x2000 0x4a310000 0x3000 0x4a326000 0x2000 0x4a32e000 0x31c 0x4a332000 0x58>；
   reg-names ="dram0"、"dram1"、"shrdram2"、"cfg"、"IEP"、 "MII_RT"；
   #address-cells =<0x1>；
   大小单元格=<0x1>；
   范围；
   状态="正常"；
   pinctrl-names ="default"；
   pinctrl-0 =<0x4f>；
   ti、hwmods ="pruss"；

   INTC@4a320000｛
   兼容="ti、am3356-pruss-intc"；
    reg =<0x4a320000 0x2000>；
    reg-names ="intc"；
    中断=<0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1b>；
    interrupt-names ="host2"、"host3"、"host4"、"host5"、"host6"、 "host7"、"host8"、"host9"；
    中断控制器；
    #interrupt-cells =<0x1>；
    linux、phandle =<0x50>；
    相位=<0x50>；
  }；

  PRU@4a334000｛
    兼容="ti、am3356-PRU"；
    REG =<0x4a334000 0x2000 0x4a322000 0x400 0x4a322400 0x100>；
    reg-names ="IRAM"、"control"、"debug"；
    标签="pru0"；
    中断父级=<0x50>；
    中断=<0x10 0x11>；
    中断名称="vring (振铃)"、"kick (启动)"；
    状态="正常"；
  }；

  PRU@4a338000｛
    兼容="ti、am3356-PRU"；
    REG =<0x4a338000 0x2000 0x4a324000 0x400 0x4a324400 0x100>；
    reg-names ="IRAM"、"control"、"debug"；
    标签="pru1"；
    中断父级=<0x50>；
    中断=<0x12 0x13>；
    中断名称="vring (振铃)"、"kick (启动)"；
    状态="正常"；
  }；

  MDIO@4a332400｛
    兼容="ti、davinci_mdio"；
    REG =<0x4a332400 0x90>；
    时钟=<0x13>；
    时钟名称="Fck"；
    bus_freq =<0xf4240>；
    #address-cells =<0x1>；
    大小单元格=<0x0>；
    STATUS ="禁用"；
  }；
}；
}；

行为方式：

当我在 debian 上加载 PRU-rproc 内核模块时、器件将在/sys/class/remoteproc 中创建、dmesg 中会显示相应的消息、并且还有另外两个模块(pruss 和 pruss-intc)。在 lsmod 输出中、PRU_rproc 由2使用。

另一方面、在我加载此模块时、构建的 ma Yocto 唯一在 debian 上类似的是加载的两个模块- dmesg 和/sys/class/remoteproc.中都没有任何内容在中、"used for"为 PRU_rproc 显示0。

我的问题是：

1) 1)在我的版本中添加了"pruss_SoC_bus@4a326000"-我知道这只是较新内核版本随附的内容吗？

2) 2)我怀疑丢失了 phandle (和 linux、phandle)可能是问题所在。我如何才能找出未创建它们的原因？

3) 3)我只为 pinmux 定义了一个引脚-这是否会导致问题？

此致、

Marek Slomiany

6 年多前

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好 Marek、

PRUSS_SoC_BUS 已添加到4.9内核中。如果外部引脚多路复用影响了 Remoteproc、我会感到惊讶。

您是否了解过 ti-processor-sdk-linux-am335x-evm.../board-support/linux.../arch/arm/boot/dts 中的 am33xx.dtsi 和 am335x-bonebonebine.dts 文件？这些文件不会定义 phandles、因此我怀疑这不是您的问题。

当我使用 create-sdcard.sh 脚本从 Linux 处理器 SDK 4.2加载预编译文件时、ls /sys/class/remoteproc 返回 remoteproc0、remoteproc1和 remoteproc2。

此致、
Nick

0 admin 6 年多前

TI__Guru**** 1640390 points

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

查看这些文件(am33xx.dtsi 和 am335x-bonebblack.dts)是我开始的地方、因为所有这些节点都是定义的、我只是想打开它们。

正确的做法是、这些参数不是定义相德、而是不是对 wkup_m3@100000进行定义、其定义如下：

wkup_m3：wkup_m3@100000｛
兼容="ti、am3352-wkup-m3"；
REG =<0x100000 0x4000>、
0x180000 0x2000>；
reg-names ="umem"、"DMEM"；
ti、hwmds ="wkup_m3"；
TI、Pm-firmware ="AM335x-Pm-firmware.elf"；
}；

在分解后、它看起来像：

wkup_m3@100000｛
兼容="ti、am3352-wkup-m3"；
REG =<0x100000 0x4000 0x180000 0x2000>；
reg-names ="umem"、"DMEM"；
ti、hwmds ="wkup_m3"；
TI、Pm-firmware ="AM335x-Pm-firmware.elf"；
Linux、phandle =<0x2b>；
相位=<0x2b>；
}；

如您所见、在编译期间添加了相移。更糟糕的是-我不打算设置此节点、它正在工作(当我加载内核模块 wkup_m3_rproc 时、它在/sys/class/remoteproc 中作为 remoteproc 0)。

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好 Marek、

我不清楚你的问题是什么。

在使用 ti-processor-sdk-linux-am335x-evm.../bin/create-sdcard.sh?加载的 TI 预构建软件上使用 remoteproc 命令时遇到问题了

在预构建的软件上、您是否在通过 sysfs 接口控制 remoteproc 时遇到问题、如 PRU 动手实验的实验5所示？

使用 Processor SDK 中的 BeagleBone 器件树文件构建 Linux 内核时是否遇到问题？

是否存在其他问题？

此致、

Nick

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好、Nick、

我将尝试简化此过程：

我有2个设置：

1) 1) BeagleBone Black、它使用具有 Capemanager 的 debian、dtbo 覆层以及 BBB 支持提供的所有内容。 (这里一切都很好)

2) 2) BeagleBone Black、使用 Yocto 和 TI 提供的 meta-ti 层。 (/sys/class/remoteproc 即使在加载所需的模块后仍保持为空)。

正如我在开始时所写的那样、我的目标系统是第二个系统、它使用 Yocto 和 meta-ti 层构建、使用 TI 内核、我从这里获取了名为"processor-SDK-Linux-04.02.00"的内容

git.ti.com/.../processor-sdk-linux

使用 commit a75d8e93056181d512f6c818e8627bd4554aaf92。

因此我没有 create-sdcard.sh 脚本、 capemanager 和 Cape 本身。我拥有的是具有诸如 am33xx.dtsi、 am335x-bone-common.dtsi 等 devicetrees 的内核源代码

正如我在第一篇帖子中在结尾处写下的这3个问题、您已经回答了第一个有关 devicetree 节点的问题-现在已经很清楚了。第三、您说 pinmux 不应该成为问题。这让我对问题2有了一个神秘的解决方案：在编译器件树之后、PRU 节点没有相位参数(这存在于 Debian 中)。如果我正确的话、没有 phandles 系统就无法与该硬件通信。 phandles 不是在任何其他节点中手动编写的、但它们会出现在已编译的 DTB 文件中、因此我想 DTC 编译器会添加它们。因为 phandles 不会出现=>我正在处理 PRU 节点的问题。

如果我的推理正确、问题应该是：如何修改 pruss_SoC_bus@4a326000节点 (来自 am33xx.dtsi)及其子节点以使 PRU 在我的构建上正常工作？

此致、

Marek

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好 Marek、

Debian 和 TI 的 Yocto 发行版之间存在未记录的差异-这是我们在这些论坛上不支持 Debian 的原因之一。因此、由于分布之间存在相位差、并不意味着以这些相位是 Remoteproc 无法正常工作的原因。

相反、我建议下载 TI Linux 处理器 SDK 4.02。在该平台上运行 PRU 后、您可以将其与 Yocto 编译进行比较并进行对比、以进行调试。

我们强烈建议您不要修改 am33xx.dtsi。相反、更改修改您感兴趣的字段的最后一个 DTS 文件(例如 AM335x-bone-common.dtsi 或 AM335x-bonebblack.dts)。

请参阅 PRU 动手实验中的"修改器件树文件以说明 PRU Cape " 以添加 Cape 的器件树信息、因为 TI 目前不支持器件树覆盖。请注意 ，PRU_SW_PATH 是 ti-processor-sdk-linux-.../example-applications/pru-icss-...。如果您需要重温通过 CCS 或 Linux 环境编程和运行 PRU 的过程、实验4-6可能会提供一些有用的信息。

此致、

Nick

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好 Marek、

我将把这个标记为"已解决"。如果您需要其他支持、请进行评论。

此致、
Nick

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好、Nick、

您是否可以将此主题再开放几天？我生病了、没有取得太多进展... 我现在又回来了、现在尝试您的方法。

此致、

Marek

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好！

在尝试按照您的建议将我的编译与 PROCesor SDK 进行比较一段时间后、我尝试设置新的 Yocto 环境(在明天)并构建 boneback poky distro。这对我来说是更方便的方式。

在工作过程中、我发现了一些内核配置的差异并修复了这些差异、而我交换了器件树文件、这使我能够使用 PRU。唯一奇怪的是、现在断开 PRU 的节点似乎是我的 UART2节点。当我禁用它时、我的构建工作正常。为什么我认为这很奇怪？因为 dmesg 说存在 pinmux 冲突、而根本不应发生冲突。

UART2使用两个引脚：

pinctrl-single、pins =<0x150 0x31 0x154 0x1>；

而 PRU 使用这些功能：

pinctrl-single、pins =<b0 0x5 0x5 0xa0 0x5 0xa4 0x5 0xa8 0x5 0x4 0xe8 0x4 0x158 0x6 0x15c 0x6 0xe0 0x4 0xe4 0x4 0x38 0x2e 0xec 0x4>；

dmesg 的消息如下：

[4.754118] pinctrl-single 44e10800.pinmux：0-0070已请求引脚 PIN43；无法申请4a300000.pruss
[4.768417] pinctrl-single 44e10800.pinmux：pin-43 (4a300000.pruss) status -22 [4.775800] pinctrl-single 44etrl：
pintrl trl 4300.pruss：pintron pintron pintrl 43_pru.pru.pru.pru.pru.pintrl
应用设置时出错、反向返回
[4.795398] ti-pruss：4a300000.pruss 的探测器失败、错误-22

PIN43应该是 GPIO1_11 (因为它的43 = 1*32 + 11)、它在根据文档被命名为"uart0_TXD"的引脚上、并且它的偏移为 974h (TRM 修订版 P 第1458页)、所以在器件树中它应该显示为0x174。这是器件中禁用的 UART0引脚之一。

我缺少什么？为什么打开 UART2会导致这种奇怪的冲突？我对引脚进行计数是不是错误的？我已经对它进行了加倍的计算、这看起来是对它进行计数的正确方法...

0 admin 6 年多前

TI__Guru**** 1640390 points

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

您好 Marek、

如果 UART2导致了该问题、您肯定会为 PRU 和 UART 使用不同的引脚、我会感到惊讶。可能存在另一个引脚多路复用冲突？能否发布完整的器件树文件？ (可能是 PRU 工作时的器件树文件、以及 PRU 遇到 pinmux 冲突时的文件)

此致、
Nick

0 admin 6 年多前

TI__Guru**** 1640390 points

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

为了避免浪费您的时间并确保这是我的错误、我清除了所有环境、状态文件、tmp 文件等在使用此 UART 重建后问题消失... 必须是临时文件中的内容。

因此、我的第一个问题(如何启动 PRU /出现在/sys/class/remoteproc 中)的所有解决方案都是内核配置。目前、对于有问题的任何人、我的设置如下：

可加载内核模块：

模块
PRU_rproc 使用的大小 10520 0
pruss_intc 7163 1 PRU_rproc
高斯 9519 1 PRU_rproc
wkup_m3_IPC 7985 0
wkup_m3_rproc 3670 1
个远程处理器 28559 3 PRU_rproc、wkup_m3_rproc、wkup_m3_IPC
pruss_soc_bus 4105 0

当然、最重要的是首先包含适当的器件树 dtsi (在我的案例中为 AM335x-bonebblack-prucape .dtsi)。

非常感谢 Nick 的帮助！

此致、

Marek

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] AM3359：PRU 器件树配置

设备树：

行为方式：

我的问题是：