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.
MCU+SDK 9.1
Linux+SDK 8.6
TMDS64EVM
您好:
在测试过程中、我们遇到了一个问题、即程序在 DDR 上的运行速度比在 MSRAM 上的运行速度慢。 上面的链接是我们先前提出的问题、也是我的问题的背景。
首先回答上一链接中提出的问题:
我使用的示例是 GPIO_LED_BLINK、它来自 MCU+SDK 9.1软件包。 该示例的工程名称为 GPIO_LED_BLINK _am64x_evm_r5fss0-0_nortos_ti-arm-clang。 我们可以看到、这是一个在 R5F0-0内核上运行的程序。 我以前看过该程序、只有外设的示例代码控制是 GPIO 的输出、而不是输入。 我的理解是、它不存在上述链接中提到的与输入中断相关的问题。
GPIO_LED_BLINK 示例成功配置为从 Linux 引导到 DDR、可以观察到 LED 指示灯闪烁。
我还看过 AM64x Academy 多核模块开发文档、其中似乎没有提到如何在 Linux 系统的器件树中分配 SRAM 节点。
https://dev.ti.com/tirex/explore/node?node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST
我要实现 在 MSRAM 上运行的 Linux 系统引导 R5F CPU 项目:
对于 CCS 工程、请参阅并比较在 DDR 和 MSRAM 程序上运行的 linker.cmd 和 example.syscfg 文件。 针对 example.syscfg 文件完成以下配置(可以在 example.syscfg 中修改 MCU+SDK 9.1 linker.cmd、并将资源表大小设置为0x1000)。
MSRAM :origin = 0x70080000、length = 0x40000
更改为
MSRAM0 :origin = 0x70080000、length = 0x1000
MSRAM1 :origin = 0x70081000,length = 0x3F000
更改了部分
MSRAM0 -> resource_table
MSRAM1 -> Text Segments、Code and Read Only Data、Data Segment、Memory Segments、Stack Segments、Initialization and Exception Handling
使用上述更改进行测试后、我发现未成功加载程序。
根据上述测试以及帖子上的回复、我有以下问题:
>首先,如果我记得正确的话,在客户的设备树中修改过的保留内存部分专门用于 DDR。 您可以在 am64-main.dtsi 文件中找到 SRAM 分配。 因此、如果客户要添加 SRAM 分配、则需要将其添加到 SRAM 节点而不是 DDR 节点。
k3-am64-main.dtsi 文件中的 SRAM 节点位于何处? 如何分配 SRAM? 分配 SRAM 后、我需要对 K3-am642-evm.dts 文件进行哪些更改?
>第二,请注意,我们只测试了1MB Virtio 部分作为工作在 DDR ,而不是在 SRAM。 我不确定资源表是否也需要位于 DDR 中、或者它是否可以进入 SRAM 中。 但这是另一项要测试的内容。
是否验证 R5F CPU 程序已由 Linux 系统引导至 MSRAM 存储器? 或者它在理论上工作吗?
如果已经过验证并且可行、TI 能否提供修改示例供我们参考、包括修改器件树文件?
黄先生、您好!
很高兴听到您正在取得进步! 我将把它分为不同的步骤、以便我更轻松地跟踪您的位置。
步骤1:修改 GPIO 闪烁示例、以便能够从 Linux 加载(已完成)
添加一个资源表、并按如下所述更新 linker.cmd 文件:
https://dev.ti.com/tirex/explore/node?node=A__AeMVTHckwFDmFoNkRHpRPw__AM64-ACADEMY__WI1KRXP__LATEST
步骤2:确保 R5F 存储器分配不与 Linux 冲突
请参阅 AM64x 学院多核模块的"如何分配内存"页面
https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AbwqjEswy38Z6lZWYQC-5g__AM64-ACADEMY__WI1KRXP__LATEST
Linux SRAM 分配在文件 k3-am64-main.dtsi、节点 OS_SRAM 中定义、
oc_sram: sram@70000000 { compatible = "mmio-sram"; reg = <0x00 0x70000000 0x00 0x200000>; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x00 0x70000000 0x200000>; tfa-sram@1c0000 { reg = <0x1c0000 0x20000>; }; dmsc-sram@1e0000 { reg = <0x1e0000 0x1c000>; }; sproxy-sram@1fc000 { reg = <0x1fc000 0x4000>; }; };
因此、R5F 无法使用 SRAM 地址0x701C_0000至0x701F_FFFF。
第3步:尝试将除资源表和 VRINGS 之外的所有内容放入 SRAM
请不要尝试从步骤1中的工作示例中移动资源表或 VRNG。 现在把它们留在原位。 我们只需要测试 Linux 是否可以将程序数据放入 R5F 内核的 SRAM 中。
我今天没有时间放完整的示例。 但我希望您可以将要提供给 R5F 的数据段添加到 oc_SRAM devicetree 节点中。 假设您将其称为 r5f0_0_MEMORY@80000。
然后、您应该能够将指向新 SRAM 分配 r5f0_0_MEMORY 的链接作为可选的 SRAM 属性传递到板级 devicetree 文件上的 r5f0_0节点中。
如需更多信息、请参阅 Linux SDK、board-support/ti-linux-kernel-6.1.46+gitAUTOINC+247b2535b2-g247b2535b2/Documentation/devicetree/bindings/remoteproc/ti、k3-r5f-rproc.YAML。
我希望它看起来与您在 K3-am642-evm.dts 节点&main_r5fss0_core0中看到的"存储器区域"属性中存储器分配 的引用类似。
此致、
尼克
您好,Nick W ü,
现在可以从在 MSRAM 上运行的 Linux 引导 R5F 内核、并且 Linux 可以正常运行。
但仍有一些问题,这些问题如下:
当我今天对它进行测试时、我发现所有 mcu+ core 相关.out 文件以前都没有删除。
只删除运行在 R5F0-0和 MSRAM 区域中的 GPIO_LED_BLINK 项目的.out 文件。
MCU+内核链接的其余部分工作如下(不修改 IPC_rpmsg_echo_linux 示例):
> R5F0-1 -> ipc_rpmsg_echo_linux_am64x-evm_r5fs0-1_freertos_ti-arm-clang.out
>r5F1-0 -> ipc_rpmsg_echo_linux_am64x-evm_r5fs1-0_freertos_ti-arm-clang.out
>r5F1-1 -> ipc_rpmsg_echo_linux_am64x-evm_r5fs1-1_freertos_ti-arm-clang
>m4f -> ipc_rpmsg_echo_linux_am64x-evm_m4fs0-0_freertos_ti-arm-clang.out
删除连接到 M4F 内核的.out 文件。 AM64x EVM 板再次通电后、 我们发现 Linux 可以正常运行、并且 COM 端口可以向 Linux 输入命令。
目前我们没有使用 M4F 内核、因此我们没有进一步测试它。
我修改 ipc_rpmsg_echo_linux 示例、 IPC_rpmsg 模块仅在 R5F0-1、R5F1-0和 R5F1-1中进行测试。
为 IPC rpmsg echo.c 修改 R5F0-1项目的文件:
//In ipc_rpmsg_echo.c file 105-112 line uint32_t gRemoteCoreId[] = { // CSL_CORE_ID_R5FSS0_0, CSL_CORE_ID_R5FSS0_1, CSL_CORE_ID_R5FSS1_0, CSL_CORE_ID_R5FSS1_1, // CSL_CORE_ID_M4FSS0_0, CSL_CORE_ID_MAX /* this value indicates the end of the array */ }; //In ipc_rpmsg_echo.c file 316 line if( IpcNotify_getSelfCoreId() == CSL_CORE_ID_R5FSS0_1 )
R5F1-0和 R5F1-1工程不会被修改。
测试后、结果与下面链接上的描述一致:
TI 将来会考虑优化这款器件吗?
此致、
黄
黄先生、您好!
调试的后续步骤
1) 1)只是三重检查:您在 MCU+ SDK 和 Linux SDK 中都使用哪个版本的 SDK?
2)我很难确切地理解你描述的内容:
1. Linux 成功引导 R5F0-0内核项目(GPIO_LED_BLINK)在 MSRAM 上运行。 我们可以看到这些 LED 在闪烁(其他 R5F、M4F 项目仍在 DDR 上运行)。
2. 在 Linux 系统的 Remoteproc 驱动程序启动 MCU+内核后 Linux 系统卡住、Linux 系统的 LED 指示灯停止闪烁(LD23) 。 Linux 系统无法接受来自 COM 端口的任何指令。 Linux 启动日志发布在以下部分中。
如果我正确理解这一点、R5F 内核会继续按预期运行(即 GPIO_LED_BLINK 示例继续使 LED 闪烁)、但同时 Linux 会无响应?
3) 3)您是否进行检查以确保在 UART 上没有资源冲突? 如果 Linux 和 R5F 代码尝试使用同一个 UART 外设、则可能会发生不良情况。 如需更多信息、请访问 https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AROmAnuFxeqz306G2XuoZw__AM64-ACADEMY__WI1KRXP__LATEST
4)确保所有内核之间没有存储器冲突(即 R5F 项目和 M4F 内核之间、以及这些内核与 Linux 之间)。
如果事情仍然无法正常工作该怎么办?
如果您仍然无法使其正常工作、请随时给 Tony 一个修改后的项目供我查看。 请突出显示您所做更改的确切位置- Git 补丁是一种非常好的方式、可以在我们的示例中准确显示您所做的更改。
如果你还没有使用 git 版本控制,我强烈建议你开始使用它。 它使跟踪所有更改和测试变得更加容易。 如需更多信息、请访问 https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__AThWljFSwXcdQKgF4QGSXw__AM64-ACADEMY__WI1KRXP__LATEST
此致、
尼克
您好,Nick W ü,
非常感谢您的答复。
您是对的!
Linux 现在可以引导 R5F 内核在 MSRAM 上运行、而 M4F 内核和 Linux 系统可以正常运行。 基于此、无论 MCU+内核之间的共享存储器区域是在 DDR 或 MSRAM 上配置以进行测试、RPMSG 模块都可以正常工作。
因为我赶时间进行测试、所以使用了一些错误的文件来测试产生的错误。
使用 MCU+SDK 9.1进行测试
>如果 M4F 没有运行程序,R5F0-0 (MSRAM)、R5F0-1 (DDR)、R5F1-0 (DDR)、R5F1-1 (DDR)可以从 Linux 正常启动,而 Linux 正在正常运行。
可能是我使用了错误的.dTB 文件进行测试。 根据上述回复修改生成的.dtb 文件没有问题。 M4F 内核(DDR)可正常启动。
>当 R5F0-0在 MSRAM 上运行时、R5F 内核的其余部分都在 DDR 内存上运行。 在 DDR 上运行的 R5F 无法使用 IPC_rpmsg 进行 R5F 内核之间的数据交互、Linux 和 R5F 可以使用 IPC_rpmsg 进行数据交互(使用 ti-rpmsg-char 进行测试)。
我已经重新配置了在系统项目中使用 IPC 的 MCU+内核、但在测试期间、我没有重新编译所有 MCU+项目、也没有替换所有.out 文件。 我猜是一些 MCU+内核一直在执行 IpcNotify_syncall (SystemP_WAIT_FOREVER)。
此致、
黄
黄先生、您好!
很高兴听到一切都在为您服务! 如果您有任何其他问题、请随时创建新主题帖。
后续
可以帮个忙吗? 您提出了一个非常好的问题。 根据我们的讨论、我想创建一个新的 AM64x Academy 页面。 您是否可以附加 Linux devicetree 文件和远程内核链接器文件的这些部分?
Linux devicetree:
SRAM devicetree 节点
引用 SRAM 的远程内核 devicetree 节点
远程核心链接器文件:
您为 DDR 和 SRAM 分配不同区域的器件
此致、
尼克
你好,Nick
没问题。 我一直在学习 AM64x Academy。 同时也希望 AM64x Academy 能够帮助更多 AM64x 用户。
以 MCU+SDK 中的 GPIO LED 闪烁为例。(Linux SDK 8.6 / MCU+SDK 9.1)。
为了在 MSRAM 中实现 Linux 引导 R5F 运行、主要更改如下:
//SRAM devicetree 节点
oc_sram: sram@70000000 { compatible = "mmio-sram"; reg = <0x00 0x70000000 0x00 0x200000>; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x00 0x70000000 0x200000>; //SRAM node allocation -> MSRAM: ORIGIN = 0x70080000 , LENGTH = 0x40000 main_r5fss0_core0_msram:r5fss0_core0_msram@80000 { reg = <0x80000 0x40000>; }; atf-sram@1c0000 { reg = <0x1c0000 0x20000>; }; dmsc-sram@1e0000 { reg = <0x1e0000 0x1c000>; }; sproxy-sram@1fc000 { reg = <0x1fc000 0x4000>; }; };
//引用 SRAM 的远程核心 devicetree 节点
main_r5fss0_core0: r5f@78000000 { compatible = "ti,am64-r5f"; reg = <0x78000000 0x00010000>, <0x78100000 0x00010000>; reg-names = "atcm", "btcm"; ti,sci = <&dmsc>; ti,sci-dev-id = <121>; ti,sci-proc-ids = <0x01 0xff>; resets = <&k3_reset 121 1>; firmware-name = "am64-main-r5f0_0-fw"; ti,atcm-enable = <1>; ti,btcm-enable = <1>; ti,loczrama = <1>; sram = <&main_r5fss0_core0_msram>; //sram node reference };
//您将不同区域分配给 DDR 和 SRAM 的部件
SECTIONS { .vectors : { } > R5F_VECS , palign(8) GROUP : { .text.hwi : { } palign(8) .text.cache : { } palign(8) .text.mpu : { } palign(8) .text.boot : { } palign(8) .text:abort : { } palign(8) } > MSRAM GROUP : { .text : { } palign(8) .rodata : { } palign(8) } > MSRAM GROUP : { .data : { } palign(8) } > MSRAM GROUP : { .bss : { } palign(8) RUN_START(__BSS_START) RUN_END(__BSS_END) .sysmem : { } palign(8) .stack : { } palign(8) } > MSRAM GROUP : { .irqstack : { . = . + __IRQ_STACK_SIZE; } align(8) RUN_START(__IRQ_STACK_START) RUN_END(__IRQ_STACK_END) .fiqstack : { . = . + __FIQ_STACK_SIZE; } align(8) RUN_START(__FIQ_STACK_START) RUN_END(__FIQ_STACK_END) .svcstack : { . = . + __SVC_STACK_SIZE; } align(8) RUN_START(__SVC_STACK_START) RUN_END(__SVC_STACK_END) .abortstack : { . = . + __ABORT_STACK_SIZE; } align(8) RUN_START(__ABORT_STACK_START) RUN_END(__ABORT_STACK_END) .undefinedstack : { . = . + __UNDEFINED_STACK_SIZE; } align(8) RUN_START(__UNDEFINED_STACK_START) RUN_END(__UNDEFINED_STACK_END) } > MSRAM GROUP : { .ARM.exidx : { } palign(8) .init_array : { } palign(8) .fini_array : { } palign(8) } > MSRAM .bss.user_shared_mem (NOLOAD) : { } > USER_SHM_MEM .bss.log_shared_mem (NOLOAD) : { } > LOG_SHM_MEM .bss.ipc_vring_mem (NOLOAD) : { } > RTOS_NORTOS_IPC_SHM_MEM .bss.nocache (NOLOAD) : { } > NON_CACHE_MEM // Add resource_table GROUP : { .resource_table : { } palign(4096) } > DDR_0 } MEMORY { R5F_VECS : ORIGIN = 0x0 , LENGTH = 0x40 R5F_TCMA : ORIGIN = 0x40 , LENGTH = 0x7FC0 R5F_TCMB0 : ORIGIN = 0x41010000 , LENGTH = 0x8000 NON_CACHE_MEM : ORIGIN = 0x70060000 , LENGTH = 0x8000 MSRAM : ORIGIN = 0x70080000 , LENGTH = 0x40000 USER_SHM_MEM : ORIGIN = 0x701D0000 , LENGTH = 0x80 LOG_SHM_MEM : ORIGIN = 0x701D0080 , LENGTH = 0x3F80 RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0x701D4000 , LENGTH = 0xC000 FLASH : ORIGIN = 0x60100000 , LENGTH = 0x80000 DDR_0 : ORIGIN = 0xA0100000 , LENGTH = 0x1000 // Allocate the DDR area to place the resource table DDR_1 : ORIGIN = 0xA0101000 , LENGTH = 0xEFF000 LINUX_IPC_SHM_MEM : ORIGIN = 0xA0000000 , LENGTH = 0x100000 }
不要忘记向项目中添加资源表、 我使用 example.syscfg 文件进行配置(IPC->Linux A53 IPC RP 消息)
现在、我并不担心 Linux 如何引导 M4F 在 MSRAM 上运行、因此我没有在我身边进行测试。 我希望 Nick 可以在 AM64x Academy 上加入该团队。
此致、
黄
黄先生、您好!
这太棒了、再次感谢您与我共享您的代码! 当我有一些空闲时间在多核学院添加更多页面时、我将以您的示例为基础进行构建。
此致、
尼克
黄先生、您好!
我正在努力添加我们讨论过的有关 R5F 和 M4F 的 SRAM 示例。 我确实注意到有一件事可能影响您的用例、也可能不影响您的用例:
我以 IPC_rpmsg_echo_linux 示例 SDK 9.1为基础进行构建。
我查看了 R5F0_0 SysConfig、其中设置了 TI 驱动程序移植层> MPU ARMv7 > CONFIG_MPU_Region3、以确保 SRAM 存储器区域已选中"允许代码执行"。
默认情况下、"Access Permissions (访问权限)"列出了"Supervisor RD+WR、User RD (主管 RD+WR、用户 RD)"。 我不确定这是否会阻止堆栈正常运行、或者您是否需要将其更新为 "Supervisor RD+WR、User RD+WR"。
此致、
尼克