支持 S32K344 的 MATLAB 和 S32DS 您好，先生， 我正在尝试为 S32K344 制作一个简单的版本模型，并使用 S32 配置工具对其进行配置。但是，它并没有像预期的那样工作，我觉得我可能遗漏了一些步骤。 我已经查看了恩智浦网站上的论坛和视频，但仍然无法解决这个问题。 我附上了一些我的工作截图，供您审阅。 我恳请您就正确的程序或我可以遵循的任何文件提供指导。非常感谢你们的支持。 谢谢！ Re: Support on MATLAB and S32DS for S32K344 你好 我检查了您所附的图片，似乎您正确地将 PTB26 配置为输出引脚。 您遇到的问题是，在应用程序刷新到板后，PTB26 的逻辑电平仍然很低。我说得对吗？ 为了更好地理解这个问题，你能告诉我你正在使用的开发板的确切模型吗？您安装的是什么版本的 S32K3？您使用的是哪个版本的 MATLAB？ 顺祝商祺！ 索林-伊万尼德-班奇拉 Re: Support on MATLAB and S32DS for S32K344 你好 我昨天漏查了一件事。 除了引脚和 DIO 元器件外，您还需要将端口元器件配置为使用指定的引脚。由于您使用的是旧版本的工具箱，端口引脚不会根据引脚配置自动更新（这也是它能在 S32DS 中工作的原因）。 总而言之 1。打开配置项目并导航到 Port 元器件。 2.在Dio 端口容器中，添加一个新的端口引脚 ，其 MSCR 为所需引脚的 MSCR（在本例中，对于 PTB28，MSCR 为 60）。 如果这能解决你的问题，请告诉我。 顺祝商祺！ 索林-伊万尼德-班奇拉 Re: Support on MATLAB and S32DS for S32K344 感谢您的回复。 所需的详细信息请参见下文： MATLAB 版本：R2022a 开发板：S32K344-172 S32K3 软件包版本：1.6 与此同时，我们还使用 PTA27 进行了测试，但观察到了相同的行为。这让我们怀疑在 DIO 配置和引脚配置之间可能缺少一个环节。我们恳请就正确的程序提供指导，以确保不遗漏任何配置步骤。 关于我前面提到的一点：当我说它可以使用"嵌入式代码时，" ，我的意思是我们通过 S32DS 平台使用嵌入式 C 代码测试了相同的逻辑，在这种情况下，引脚的表现与预期完全一致。该问题仅在使用 MATLAB/Simulink 生成的代码时出现。 Re: Support on MATLAB and S32DS for S32K344 是的，现在 Dio 的问题已经解决，而且工作正常。 Re: Support on MATLAB and S32DS for S32K344 你好 我们刚刚发布了 S32K3 工具箱的新版本 (1.8.0)。如果你想升级到最新版本，请前往 MATLAB 中的插件管理器并搜索 nxp_support_package_s32K3。安装支持软件包后，你可以运行 GettingStarted.mlx 脚本，该脚本将指导你安装最新版本。 顺祝商祺！ 索林-班奇拉 Re: Support on MATLAB and S32DS for S32K344 您好，感谢您的回复。 您提到的是旧版本的软件。为了便于配置，你能否与我们联系应该使用哪个版本？ Re: Support on MATLAB and S32DS for S32K344 你好，@chaudharimohit73、 如果建议的解决方案解决了您的问题，请告诉我。 顺祝商祺！ 索林-班奇拉 Re: Support on MATLAB and S32DS for S32K344 您好， DIO 配置成功后，我现在正试图配置 CAN。我想使用混合标准报文和扩展报文的 CAN。 能否请您指导我完成配置步骤？

揭开Linux中PCIe和CPU地址空间转换的神秘面纱 lspci output on iMX95EVK as PCIe RCiMX95EVK作为PCIe RC时的lspci输出 请仔细观察上述片段。它取自iMX95的控制台，在对特定PCIe设备[iMX8MM即PCIe EP]执行“lspci”后，此设备已枚举为BDF[总线设备功能]01:00.0。 本博客试图揭开围绕lspci输出内存地址信息的神秘面纱。 我们将探讨这一地址的定义、用途及其在PCIe领域的重要性。本博客将重点讨论以下议题：- 1. Linux设备树中的PCIe对应关系 2. 什么是CPU和PCIe地址空间，以及地址空间转换的必要性？ 3. 在Linux中为PCIe设备分配资源 4. 如何在Linux PCI子系统中进行地址空间转换？   Linux设备树中的PCIe对应关系 在Linux设备树中，PCIe对应关系可定义PCIe根复合体和端点在系统中的位置。设备树中的PCIe父节点代表PCIe控制器（根复合体/主机桥）。 参考imx95设备树源中的PCIe节点：- pcie@4c300000 {                         compatible = "fsl,imx95-pcie"; reg = <0x00 0x4c300000 0x00 0x10000 0x00 0x4c360000 0x00 0x20000 0x00 0x60100000 0x00 0xfe00000>;                         reg-names = "dbi\0atu\0config";                         #address-cells = <0x03>   …  } pcie@4c300000代表Designware PCIe控制器根复合体，它将作为与其连接的设备/桥的父节点。 -- “compatible”属性则用于标识特定的PCIe控制器。其对应的驱动程序位于drivers/pci/controller/dwc/pci-imx6.c -- “reg”属性可指定PCIe控制器的内存映射寄存器。 PCIe RC下的子节点代表PCIe总线上的设备。它们可以是固定功能设备，例如Wi-fi、以太网、NVMe，也可以是PCIe桥，后者可进一步连接设备。 参考“arch/arm64/boot/dts/freescale/imx95.dtsi” pcie_4ca00000： pcie@4ca00000 { compatible = "pci-host-ecam-generic"; reg = <0x0 0x4ca00000 0x0 0x100000>;                         /* 必须为3。*/              …              …              enetc_port0: ethernet@0,0 { 兼容 = "fsl,imx95-enetc"; reg = <0x000000 0 0 0 0>; clocks = <&scmi_clk IMX95_CLK_ENET>,                                          <&scmi_clk IMX95_CLK_ENETREF>;                                 clock-names = "ipg_clk", "enet_ref_clk"; nvmem-cells = <&eth_mac0>;                                 nvmem-cell-names = "mac-address"; 状态 = "disabled";                         }; }   ethernet@0,0是位于总线0、设备0、功能0的PCIe设备。它是PCIe RC的子设备，内存映射位置为0x4ca00000 这些子设备/桥既可以借助PCI枚举动态发现，也可以在设备树中静态描述，如上文中设备树片段所示，其中“ethernet@0,0”条目以静态方式向RC声明与其连接的以太网子设备。如上例所示，这些子节点嵌套在设备树的PCI父节点中。   什么是CPU和PCIe地址空间，以及地址空间转换的必要性？ CPU地址空间是处理器所能查看的系统物理内存映射。 Cortex-A55在iMX95上查看的CPU物理地址空间示例：   起始地址      结束地址    模块 0x48000000       0x4812FFFF    GIC编程寄存器 0x4AA00000      0x4AAFFFFF    Neutron SRAM 0x4AC10000      0x4AC1FFFF    摄像头域块控制 0x4E080000       0x4E08FFFF    DDR控制器 此地址空间是由系统固件/操作系统管理的全局系统视图。这些地址均由硬件设计固定。 另一方面，PCIe地址空间是PCI总线的本地空间，由PCIe子系统管理。该空间中的地址采用动态分配模式。 PCIe地址空间的示例如下：- 0x00000000   -    0x0FFFFFFF 0x10000000－0x1FFFFFFF 0x20000000   -    0x2FFFFFFF 由上文说明可知，CPU和PCIe地址空间运行在各自独立的地址域中。因此，除非部署转换机制，否则CPU无法访问PCIe设备的地址空间。我们将在后续章节中讨论这一内容，但请花几分钟时间来思考以下问题： 问：为什么CPU和PCIe需要独立的地址空间？ 答：主要考量因素之一是模块化。我们采用独立的空间设计，确保PCIe设备独立于CPU架构进行设计。同一张卡可以在不同的系统中运行。CPU可以根据需要随时重新映射PCIe空间，从而始终保持灵活性。 此外，不同的地址空间会阻止设备访问任意系统内存。 根据本节的讨论内容，PCIe地址空间显然与CPU地址空间存在本质差异，而事实上——这种差异恰恰赋予其独特优势。因此，我们需要一个能在地址空间之间实现双向转换的实体。 接下来，我们将介绍“iATU”，即内部地址转换单元。在iMX SoC中，这些硬件单元负责执行地址转换。它们是Synopsys DesignWare PCIe控制器的组成部分，可为入站和出站事务提供可编程的地址转换窗口。 对于不熟悉PCIe入站和出站事务的读者，请花些时间阅读这篇技术博客 - 通过用例了解PCIe出站/入站窗口 - 恩智浦网络社区 注意：地址转换仅确保CPU可访问PCIe设备的内存，反之亦然。 到目前为止，读者应对PCIe地址转换形成基本认知。在深入研究Linux PCI子系统中的转换操作之前，让我们先讨论一下如何为PCIe设备分配资源。   在Linux中为PCIe设备分配资源 PCIe设备并未配置直接的CPU指令接口，因此其通过内存映射区域进行通信。设备需要内存来执行DMA操作或MSI/MSIX中断。不同的设备有不同的需求，因此PCIe中的资源可以是映射设备寄存器的MMIO，也可以是DMA传输所需的内存区域。 在Linux中，PCI子系统的pci_assign_resource函数负责在系统初始化期间为PCIe设备分配IO和内存资源，此操作将在枚举PCIe设备后执行。PCI总线上的所有设备均可调用此函数，并根据PCI设备的资源需求进行分配。 但是，Linux中的PCI子系统如何确定PCIe设备需要什么资源？ - 每台PCIe设备都设有由PCIe规范定义的配置空间。这包括   BAR[基地址寄存器] - 用于指示设备所需资源的类型[IO/Mem]和规模。 功能 - 用于广播设备功能，例如MSI中断、ASPM低功耗状态等。 通过从PCIe设备读取BAR，我们可以了解设备所需资源的类型和规模。 // 从PCIe设备的BAR中确定资源规模：- 步骤-1：将所有1写入目标BAR寄存器。 步骤-2：读回该值并清除低4位（对于内存BAR）或2位（对于I/O BAR），因为这些状态位并不参与大小的计算 步骤-3：对该值执行按位取反后加1。 步骤-4：返回值表示大小。 举例说明：- 假设在读回上述步骤-2中的值后，BAR返回0xFFFFF000。低4位已清零。 步骤-3：对该值执行按位取反 -> ~(0xFFFFF000) = 0x00000FFF 加1：0x00000FFF + 1 = 0x00001000 得到的值0x1000 = 4096字节表示大小，即BAR需要4KB的内存区域。 // 从PCIe设备的BAR中确定资源类型：-   PCI 配置空间中的基地址寄存器（BAR）： 位 0 → 资源类型： 1 = I/O 空间 0 = 内存空间 对于内存BAR： 00 = 32位 10 = 64 位 位1–2 → 寻址类型： 位 3 → 可预取标志 解释值0xFFFFF000，我们得到：   位 0 = 0 → 内存空间 位 1–2 = 00 → 32位地址 位 3 = 0 → 可预取 高位 → 基址（屏蔽后）   pci_read_bases [drivers/pci/probe.c]在Linux PCI子系统中负责确定设备枚举期间的BAR内存大小和类型需求。 毋庸置疑，上述向端点的BAR写入数据并确定资源类型与规模的操作流程，均在PCIe RC上执行。我们的设置如下：- iMX95<------> iMX8MM[RC]                     [EP] 在PCIe RC确定所需的BAR大小后，pci_assign_resource函数会分配一个内存范围，然后设置从该内存范围向PCIe地址空间的转换。 我们以一个lspci日志片段为切入点来撰写这篇博客文章，具体片段如下：- 综上所述，请注意RC驱动程序已分配以下资源： 0x910100000 - 0x910110000作为不可预取的内存地址范围，大小=64KB 上述内存地址范围位于iMX95 SoC上映射的PCIe 1出站空间内存中：-   范围0x910100000 - 0x910110000将映射到端点的PCIe地址空间。这实际上意味着，如果CPU生成此范围内的任何地址[包括起始和结束地址]，PCIe控制器则会在RC上向总线中的端点发送PCIe TLP。它可能是对端点内存的读取/写入操作。写入/读取地址将根据地址空间转换来决定。 我们将在下一节详细探讨如何在Linux内核中实现这一转换。   在 Linux PCI 子系统中如何进行地址空间转换？   我们先从部分关键问题入手：- 如何指定0x910100000-0x910110000的范围？内核如何确认其必须映射PCIe 1出站空间，而非PCIe2出站空间或其他地址空间？ -- 正如Linux 中的所有优秀设计，这同样始于“设备树二进制”。Uboot会将dtb传递给内核，以便其获取我们的板硬件描述。由于我们使用Torradex的Verdin iMX95 EVK板作为根复合体，因此我们使用的dtb为 imx95-19x19-verdin-adv7535.dtb 我会附上可用的dtb，供读者按需使用。 该dtb包括 -arch/arm64/boot/dts/freescale/imx95.dtsi 让我们重点关注特定的pcie节点：-   “ranges”属性正是本节先前所提问题的答案。  - 此属性可定义父地址空间和子PCI地址空间之间的地址转换规则。   注意：此博客仅关注“ranges”属性，因为它与我们的讨论内容相关。因此，如果读者想了解PCIe节点的其他设备树属性，建议查阅其他资料。  让我们解码“ranges”属性： 具体格式如下：-      3个单元               2个单元             2个单元             因此，一个条目将配置7个单元。我们的dtsi设有2个条目。第一个条目用于IO空间转换，第二个条目则用于内存空间转换。请参考第二个条目：-   0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000 |------PCI地址---------------| |-CPU地址-| |---PCI大小---|   根据上文，我们获得以下信息：- 内存空间可预取 <   0x82000000 0x00 0x10000000 // PCIe 地址：0x10000000   0x09 0x10000000              // CPU/系统地址：0x910000000 0x00 0x10000000 // 大小：256MB >; 0x82000000 = 1000 0010 0000 0000 0000 0000 0000 0000   位 31-30 (10) → 配置空间类型：这表示内存空间。 位29(0) → 不可重定位 位 28 (1) → 可预取 = 否（0 表示不可预取） 位 27–24 (0010) → 地址空间类型 = 内存 因此，0x82000000表示： PCI 内存空间 不可预取 32 位地址空间 注意：- 对于想了解lspci输出为何显示[size=64K]而dts256 MB的人，这是因为256MB是PCIe设备可用的最大地址空间。端点设备根据自身所需地址空间的大小，向系统申请分配。 同样，IO空间转换也是根据“ranges”中的第一个条目创建的：- < 0x81000000 0x00 0x00 → PCI I/O 地址：0x00000000 0x00 0x6ff00000 → CPU/系统地址：0x6ff00000 0x00 0x100000 → 大小：1MB >;   我们在iMX95 Verdin EVK Linux控制台的dmesg输出中也观察到类似情况：-   因此，内存空间映射已从 CPU地址0x910000000 - 0x091fffffff转换为PCIe地址0x10000000 - 0x1fffffff 我们有必要说明使用“ranges”属性的驱动程序。“ranges”属性在“pci_parse_request_of_pci_ranges -> devm_of_pci_get_host_bridge_resources”中进行解析，具体路径是“drivers/pci/of.c” 每个范围中的devm_of_pci_get_host_bridge_resources会自动管理这些资源的内存分配。它能确保在设备断开连接或驱动程序移除时释放这些资源。 我们已确定CPU和PCI地址范围的定义和原因。但是在lspci中，您观察到的是0x910100000，而非0x910000000，后者才是根据dtb指定的起始范围。这是为什么呢？ 要回答这个问题，我们需要回溯PCIe设备枚举过程。 如上文所述，在PCIe枚举过程中，Linux PCI驱动程序会确定BAR资源，随后PCI核心驱动程序可能会遵循对齐要求分配地址。正因如此，系统会为EP的BAR0分配PCI总线地址0x10100000，且与0x10000000存在1MB[0x100000]的偏移量。 同时，您还需关注设备树PCI转换窗口：- 0x10100000转换为0x910100000 这一转换并非自动完成。设备树二进制仅指定转换窗口的具体信息，例如目标CPU地址空间和源PCI 地址空间之间的转换关系。实际转换是由iATU完成的。 此操作可在drivers/pci/controller/dwc/pcie-designware-host.c的dw_pcie_iatu_setup函数中完成，具体方式是使用dw_pcie_prog_outbound_atu函数创建出站窗口。 RC上的转换已成功配置，但部分环节仍需完善。 .. .. 入站窗口！！ 如果端点（如iMX8MM）上并未配置入站窗口，对0x910100000的读取/写入操作将毫无意义。我们在iMX8MM上使用的是PCI端点测试驱动程序，该驱动程序是Linux社区中的热门选择。如果读者需要了解更多信息，建议访问此页面：- 9. PCI端点框架 — Linux内核文档 pci_epc_map_addr函数（位于drivers/pci/endpoint/pci-epc-core.c中）通过将PCI地址[0x10100000]映射到EP内存中的物理地址来创建入站窗口。读取和写入操作就是通过这种方式进行的。 如果未配置入站窗口，进行读取操作时将出现以下情况：-   现在，一切准备就绪。转换窗口已在PCI驱动程序中配置，且处于Linux控制台环境中。当CPU发起内存读取请求时，将按以下顺序执行：-   对于内存写入操作：- 端点上会出现以下情况：- 最妙的是，整个转换过程由硬件以透明的方式完成 - 您的驱动程序只需读取/写入CPU地址，PCI主机控制器就会自动处理所有转换！ —— 我们如何测试地址映射？   要测试读取和写入操作，我们可以针对驱动程序本身作出一些改动，或者使用devmem5用户空间二进制。我们将对iMX8MM进行驱动程序方面的细微修改，并在RC上使用devmem5。 iMX8MM是PCIe端点，我们使用端点测试驱动程序对其进行相应配置。如果您需要实现相同配置，请参照此博客的指引操作 - 在iMX95 torradex板和iMX8MM EVK上启用PCIe端点框架 - 恩智浦网络社区 相反，如果您想将iMX95设为RC并将iMX8MM设为端点，请随时关注此博客 - 如何将iMX95EVK配置为PCIe端点并使用PCIe端点测试框架进行测试 - 恩智浦网络社区 接下来，我们需要完成两个任务：- 1. 在iMX8MM EP中，我们将写入部分随机值 在drivers/pci/endpoint/pci-epf-core.c中，对pci_epf_alloc_space函数进行以下修改：-     “space”是虚拟地址，“phys_addr”是连续的物理地址。 请注意，这是测试转换的初步方式，还有更合适的方案。 在修改后编译内核并用其启动开发板。使用PCI端点测试框架将iMX8MM设为端点。 2. 在iMX95 Verdin EVK [PCIe RC]上，我们将使用devmem5读取地址0x910100000，以验证能否在RC上观测到相同的数据。   以上就是本期的全部内容。此博客篇幅较长，如果您对其中的细节感到困惑，请随时通过私信或评论留言，我将尽力为您解答。 下次再见！ Gaurav Sharma IMX95EVK

S32G VNP RDB2 Rev.E 上的 LLCE CAN 传输问题 尊敬的恩智浦社区成员： 当我尝试通过 S32G2 LLCE 模块的 BCAN0 发送 CAN 帧时，我遇到了一个问题。我正在使用演示板 S32G-VNP-RDB2 Rev.E。 我已经通过模拟器看到，当我弹出 BLROUT FIFO 以获取 Tx 传输表的索引时，一切都运行良好，之后我将消息填充到共享内存中，然后通过 BLRIN FIFO 发回索引。 问题是 CAN 总线上没有任何反应。因此，弹出索引 15 后，BLROUT 返回 0xFFFFFFFF。 为了启用 BCAN，我们需要设置什么配置吗？ 仅供参考，固件对我发送的命令响应良好，并且我已正确配置 SIUL2 来配置 LLCE_CAN_0 的 Tx 和 Rx 引脚。 我们还观察到，当我们驱动 LLCE_CAN0_TXD 信号时，BCAN0（U17）的收发器并没有改变 LLCECAN0H 和 LLCECAN0L 的逻辑电平。我们还检查了信号LLCE_CAN01_EN处于高逻辑电平。 感谢您的支持。 顺祝商祺！ 回复：@Re: S32G VNP RDB2 Rev.E 上的 LLCE CAN 传输问题 是的，我错了，我实际上有2个节点，第二个是CAN日志工具。 此致，

S32K3X4EVB-T172板是否支持OpenSDA？ 1.我可以使用OpenSDA下载图像并将其放在S32K3X4EVB-T172板上吗？ 换句话说，是否可以使用 S32DS 下载图像而无需连接外部调试器（j-link、multilink）？ 开始使用 S32K3X4EVB-T172 汽车通用评估板 | NXP 半导体 上面说它有一个到 OpenSDA 的 USB 连接，但没有说明如何使用它。 2.我目前有一个j-link，并且有一个OpenSDA 10pin的jtag连接器，我可以将S32K344连接到它吗？ 换句话说，连接到 OpenSDA 的是 MK26FN2M0VMI18，我想知道这是否是连接到 S32K344 的那个。 3.MK26FN2M0VMI18的作用是什么？ 4.我是否可以获得 S32K3X4EVB-T172 中的图像？我可以获得该图像的代码吗？ 我将包含 S32K3X4EVB-T172 的图像作为测试，但如果我想重新创建它，我没有原始图像。此外，每个都有示例，但似乎没有一个 SDK 可以演示 S32K3X4EVB-T172 的所有功能。 回复：S32K3X4EVB-T172板是否支持OpenSDA？ 你好@velma41abbott 谢谢您的回复。 我同意你的想法。 我不知道为什么，但遗憾的是 NXP 没有为 EVB 提供 SDK。 祝你开发顺利....:) 回复：S32K3X4EVB-T172板是否支持OpenSDA？ 你好@Senlent 太感谢了。我现在可以使用 OpenSDA 测试我的电路板。 记录显示，micro-b USB 未被设备管理器识别，因为它不用于数据。 我没有意识到这是电缆问题，因为我不确定我是否可以使用 OpenSDA 进行调试。 再次感谢您的回复。 回复：S32K3X4EVB-T172板是否支持OpenSDA？ 你好@daigerlee_work 1.OpenSDA是一个独立的调试端口。您可以通过 USB 电缆调试 S32K3X4EVB，无需使用外部调试器 2.通过MK26FN2M0VMI18芯片模拟OpenSDA的功能，可以实现类似PEmicro的功能 3. 您还可以使用外部调试器，例如 J-Link、PEMicro 或 Lauterbach。S32K3X4EVB提供额外的外部调试器接口 4、如果MCU没有加密，那么理论上可以读取MCU内存中的二进制数据，但这不是代码，而是二进制。

FRDM-MXCN947ボードでイーサネットとカメラを同時に使用する MCXNx4x では、SmartDMA を使用してカメラ インターフェースを実装できます。 MCXNx4x データシートによると、イーサネット と SmartDMA の Pinmux 割り当てが競合します。このため、イーサネットとカメラを同時に使用することはできないと考えました。 ただし、FRDM-MCXN947 ボード ユーザー マニュアル (UM12018) には次のよう記載されています。 > カメラの使用中にイーサネット機能が必要な場合は、別の回避策があります SJ16 および SJ26 ジャンパーをデフォルトの位置から移動することです。 イーサネットとカメラを同時に使用する方法はありますか? 開発ボード MCX N Re: Simultaneous use of Ethernet and camera on the FRDM-MXCN947 board こんにちは@dubian1shu 書類の内容を再確認したところ、書類の記載内容に問題があることが確認できました。 文書には適時変更を加えます。 SmartDMA (EZH_CAMERA) と イーサネット (ENET)は同時に使用できますが、カメラが使用するには共有されていないピンを見つける必要があります。 こちらの記事を参考にCAN。 MCX N947：イーサネットとカメラ機能の同時実装 - NXPコミュニティ これがお役に立てれば幸いです。 BR 下がる Re: Simultaneous use of Ethernet and camera on the FRDM-MXCN947 board 確認して返信してくれてありがとう@Harry_Zhang SmartDMA は P1_X と P3_X をサポートしているので、MCXNx4x は SmartDMA と イーサネット 機能を同時に使用 CAN と理解しています。 しかし、FRDM-MCXN947 を使用して SmartDMA および イーサネット 機能を使用することはできますか? FRDM-MCXN947 の J9 (カメラ ヘッダー) には、イーサネット ピンと競合する 7 つのピンがあります。FRDM-MCXN947 ボードのユーザー マニュアル (UM12018) に記載されている P1_4 の解決策では、そのうちの 1 つだけが解決され、他の 6 つの競合については触れられていません。 たとえば、P1_5、P1_13、および P1_15 は SmartDMA と イーサネット 間で競合します。回路図ドキュメント (SCH-90818) から見る限り、この競合を解決する解決策はないようです。 FRDM-MCXN947でSmartDMA(EZH_CAMERA)とイーサネット(ENET)を同時に使用する方法はありますか？ Re: Simultaneous use of Ethernet and camera on the FRDM-MXCN947 board こんにちは@dubian1shu MCXNx4xのデータシートを確認したところ、確かにイーサネットとSmartDMAが競合するピンがいくつかあります。ただし、イーサネットとSmartDMAを同時に使用したい場合は、イーサネットとSmartDMAが競合しないピンを選択できます。 たとえば、SmartDMA ピンとして P3_X を選択し、イーサネット ピンとして P1_X を選択できます。 FRDM-MCXN947 ボード ユーザー マニュアル (UM12018) を参照してジャンパーを移動します。 これがお役に立てれば幸いです。 BR 下がる

RPMsg-Lite rpmsg_lite_alloc_tx_buffer ブロック iodsfid2df4d1 こんにちは、 i.MX93 上の Cortex-M33 と Cortex-A55 間の RPMsg-Lite 通信で問題が発生しています。 A55 がサスペンド モードに入ると、M33 側での rpmsg_lite_alloc_tx_buffer() への呼び出しは、正確な状況に応じて無期限にブロックされるか、ハード エラーが発生します。関数 rpmsg_lite_is_link_up() は引き続き true を返すため、この状態が明確に検出されません。 グラフィックスとディスプレイ ハンズオン・トレーニング HW-Open-Source i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus

S32K312 FLASH HELLO ,EXPERT: i am using S3K312 CHIP, I want to use flash and eeprom function without autosar(MCAL),There are some issues troubling me： 1. in the drivers group, i only found C40 ip and cache ip conponent ,what's the meaning of C40? 2. in the MCAL group, i can use FLS and FEE ,is it used for autosar standard interface? 3. in the MCAL i found a component named Mem_43_INFLS_TS,what's the meanning of Mem_43_INFLS_TS at last, if i want to develp FLASH AND EEPROM without autosar ,which component i could use,which demo or example is useful for my requirement ? thanks Re: S32K312 FLASH thank you Re: S32K312 FLASH Hi @PINKMAN, 1. The C40 driver is a non-AUTOSAR IP layer. You can refer to the 02: S32K3xx Real-Time Drivers (RTD) training and chapter 21 (Embedded Flash Memory c40asf) from the S32K3XX reference manual. 2. Yes, the FEE and FLS drivers are derived from MCAL. 3. Depending on which AUTOSAR version you are trying to use, the flash driver changes. For example, you can see included in the SW32K3_S32M27x_RTD_4.4_4.0.0_P20 the driver Fls_TS_T40D34M40I0R0. On the other hand, SW32K3_S32M27x_RTD_R21-11_4.0.0_P19 includes the Mem_43_INFLS_TS_T40D34M40I0R0 driver. This is because in Autosar R21-11, the Fls Driver has been replaced by Mem_InFls/Mem_ExFls. You can refer to the official Specification of Memory Access from AUTOSAR. 4. Any example which includes the "IP" word refer to the non-AUTOSAR (low level) drivers. So, for example "C40_Ip_Example_S32K344". Best regards, Julián

在 IMX8mm 上编程 SJC_DISABLE、JTAG_SMODE 和 JTAG_HEO 熔丝 你好 在 AN4581 应用笔记第 5.7 节中，建议对 SJC_DISABLE、JTAG_SMODE 和 JTAG_HEO 熔丝进行编程以完全保护设备，但是同时看 IMX8MMRM 和 IMX8MMSRM，我找不到这些熔丝的确切位置（银行、字、位）。在哪里可以找到这些信息？ 谢谢！ Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 你好，我是@igorpadykov、 如果您能把这些信息也发给我，我将不胜感激。 预先致谢 Dj Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 您好， 您能否将这些信息也发给我？ 另外，imx8m nano 和 mini 之间有区别吗？ Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 我们也希望得到这些信息。 Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 嗨，@伊戈尔帕季科夫、 我需要有关 imx8m mini 熔丝的信息。能否请您提供给我？出于网络安全原因，我需要禁用 JTAG。 最好的奖励 胡利安 Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM @igorpadykov 你还能把 JTAG_HEO 熔丝的信息发给我吗？ 谢谢！ Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 您也能与我分享一下吗？为什么这不只是发布在公共应用程序备注、参考手册或网络安全参考手册中？通过隐蔽实现的网络安全不是网络安全。 Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 您能公开这封邮件吗？为什么安全参考手册中没有列出这些信息？对于i.MX8M Nano，这已在网络安全参考手册中列出。但是我不知道 Mini 是否使用同样的熔丝。 此外，AN4581 还列出了值得关注的熔丝 DIR_BT_DIS。但我找不到任何参考。 Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 我们还想在 imx8m-mini 上禁用 JTAG，但我在《参考手册》修订版 2，2019 年 8 月 8 日第 6.2 章 Fusemap 中找不到任何有关它的信息。您能为我指明正确的方向吗？ 谢谢！ Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM 嗨 Rodrigo_travess 附加信息已通过邮件发送。 问候 igor

PCA9539 RESET 问题取决于 I²C 连接状态 你好 我正在使用 PCA9539 I/O 扩展器，遇到了意外的 RESET 问题，这似乎取决于 I2C 连接状态。 问题如下： 我通过 I²C 通信将 PCA9539 的所有输出端口配置为高电平。 输出引脚按预期保持高电平。 但是，当我移除 SDA/SCL 探头（用于监控 I2C 总线）时，PCA9539 似乎 RESET 了——输出引脚恢复到默认状态。 在此过程中，VCC 保持稳定，持续供电，RESET 引脚通过上拉电阻器保持高电平。 MCU 没有故意发出 RESET 信号或电源重启 其他说明： 在相同的测试条件下，PCA9538 没有出现这个问题。 存在 I2C 上拉电阻。 电源稳定，可与电容解耦。 RESET 引脚在事件期间未显示异常活动。 我怀疑，断开探测器连接时出现故障或启动/停止状态不完整可能会导致 PCA9539 的内部 I2C 状态机进入故障状态，从而导致类似RESET的行为。但是，我没有找到任何文件可以确认 PCA9539 是否可以在不明确 RESET 或重新通电的情况下清除其输出寄存器。 据我所知，就 I2C I/O 扩展器而言，只要有电源供应，无论是否连接了 I2C 探头，它都应保持其配置。您能确认这种理解是否正确吗？ 问题 在任何情况下，PCA9539 可以在没有 RESET 引脚断言或电源循环的情况下 RESET 其输出寄存器或 I2C 逻辑？ 拆除探头期间 SDA/SCL 出现的故障是否会导致设备进入故障状态并丢失其配置的输出？ 既然 PCA9539 和 PCA9538 的功能相似，为什么 PCA9539 会出现这种行为，而 PCA9538 却不会？ 不管 I²C 总线连接如何，只要有电源，I2C I/O 扩展器都应保持其配置，这是否正确？ 如果您对此行为有任何见解或官方文件，我们将不胜感激。 谢谢！

CST 4.0.1 の Openssl バージョン こんにちは、 NXPからCST 4.0.1（コード署名ツール）をダウンロードし、 docsフォルダ内のドキュメント（具体的にはUG10106 ）を確認したところ、セクション3.1.1に遭遇しました。CST はUbuntu 22.04をサポートし、 OpenSSL 3.2.0が必要であると記載されています。 しかし、私の現在のUbuntu 22.04システムにはOpenSSL 3.0.2が搭載されています。インストールされました。OpenSSL 3.2.0へのアップグレードが心配です既存のシステム依存関係が壊れる可能性があります。CST を使用するには、本当に OpenSSL をアップグレードする必要がありますか?もしSOなら、システムに影響を与えずにそれを実行する最も安全な方法は何ですか? 参考までに、UG10106 のスクリーンショットも添付しました。 ありがとうございます カルティーク Re: Openssl Version for CST 4.0.1 こんにちは@kartheek ！ NXP サポートにお問い合わせいただきありがとうございます。 CST ツールの推奨バージョンは OpenSSL 3.2.0 です。 残念ながらOpenSSL 3.0.2のバージョンはテストしていません。このツールを使用する場合は、システムにインストールされているバージョンの CST ツールを試すことをお勧めします。ツールが期待どおりに動作しない場合は、ユーザー ガイドで推奨されているバージョンをインストールしてみてください。 よろしくお願いいたします。 チャビラ

CST 4.0.1 的 Openssl 版本 您好， 我从恩智浦下载了CST 4.0.1（代码签名工具），在查看文档文件夹中的文档（特别是UG10106）时，我看到了第3.1.1 节、其中提到 CST 支持Ubuntu 22.04，需要OpenSSL 3.2.0。 不过，我当前的 Ubuntu 22.04 系统使用的是OpenSSL 3.0.2已安装。我担心升级到 OpenSSL 3.2.0可能会破坏现有的系统依赖关系。使用 CST 真的需要升级 OpenSSL 吗？如果是这样，有什么最安全的方法可以在不影响我的系统的情况下做到这一点？ 我还附上了 UG10106 的屏幕截图以供参考。 谢谢！ Kartheek Re: Openssl Version for CST 4.0.1 您好@kartheek! 感谢您联系恩智浦支持中心！ CST 工具的推荐版本是 OpenSSL 3.2.0。 遗憾的是，我们尚未测试 OpenSSL 3.0.2 版本。如果该工具不能按预期运行，则应尝试安装用户指南中推荐的版本。 此致 查维拉

缺少编译器 S32 Studio 我在 S32 Studio 3.6.4 中找不到编译器用于 S32K3x8 EVB。 arm-none-eabi-gcc " @board /siul2_port_ip_cfg.args "-MMD-MP-MF "板/siul2_port_IP_CFG.D "-MT " board/siul2_port_IP_CFG.O "-o " board/siul2_port_IP_CFG.O "".。/板/siul2_port_IP_CFG.C " make：*** [generate/src/subdir.mk:26: generate/src/Igf_Port_Ip_Cfg.o] ***.错误 127 /bin/sh：第 1 行：arm-none-eabi-gcc：找不到命令 make：*** [generate/src/subdir.mk:26: generate/src/OsIf_Cfg.o] ***.错误 127 /bin/sh：第 1 行：arm-none-eabi-gcc：找不到命令 make: *** [板/subdir.mk: 23:板/tspc_port_IP_CFG.O] 错误 127 /bin/sh：第 1 行：arm-none-eabi-gcc：找不到命令 make: *** [板/subdir.mk: 23:板/siul2_port_IP_CFG.O] 错误 127 Re: Missing compiler S32 Studio 你好，@Greavesinator85、 您使用的是哪个 RTD 版本？您的项目中似乎没有选择工具链。 示例项目也会出现这种情况吗？创建项目时，是否选择了"Create new S32DS application project" 选项？ 您可以尝试在项目属性中手动添加工具链路径，但我建议您创建一个新项目，以避免与此相关的任何其他配置问题。 致以最诚挚的问候， Julián

LPC55S36 I3C 主站在读取长度超过从站数据大小时挂起 我连接了两块用于 I3C 通信的 LPC5536-EVK 板，其中一块配置为 I3C 主板，另一块配置为 I3C 从机。如果主站指定的读取长度超过从站提供的数据量，主站就会卡在读取函数I3C_MasterTransferBlocking 中。根据波形，信号似乎是正确的，因此我认为问题出在主控端。 在我提供的示例中，从属服务器的数据是 [0x01，0x02]，长度仅为 2 字节。但是，主服务器将读取长度指定为 3。因此，在第 2 字节的末尾，Slave 将 T-Bit 作为 0 返回，以表示消息结束。 测试步骤： (1) RESET 从属板 (2) RESET 主板 有关 T 位的定义，请参阅《MIPI I3C 基本规范》v1.1.1。 第 5.1.2.3.4 节、SDR 目标返回（读取）数据的第九位为数据结束位 在 I2C 中，"从目标读取 "有一个问题，即只有控制器才能结束读取，因此目标无法控制其返回的数据量。相比之下，在 I3C SDR 中，目标可控制其返回的数据字数；但它也允许 I3C 控制器在必要时提前终止读取。 ... Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 尽管用户无法确定i3c_masterTransferNonBlocking实际传输了多少字节，但对于我的应用程序来说，这似乎已经足够了。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 我尝试改用I3C_MasterTransferNonBlocking。尽管它不会挂起，但用户无法知道Slave实际提供了多少字节。在我分享的示例中，它需要返回传输计数 = 2 这样的信息。 在你使用 lpcxpresso55s36_i3c_interrupt_b2b_transfer_master 示例进行测试时，尽管你将 dataSize 更改为 50，但之后代码仍会打印固定的32字节，这恰好与从属提供的传输数量相匹配。 在实际应用中，例如我在另一篇关于IBI 与待读通知的文章中提到的情况，在发生 IBI 并执行私人读取后，从属设备的传输计数是不可预测的，可能会发生变化。当主站使用大缓冲区调用读取传输函数时，传输函数需要返回实际传输的计数。 Re: LPC55S36 I3C Master Hangs When Read Length Exceeds Slave Data Size 你好@黄铃铃 我已经测试过了。 您是对的。 我检查了 I3C_MasterReceive 函数。 /* Check RX data */ if ((0UL != rxSize) && (0UL != (base->MDATACTRL & I3C_MDATACTRL_RXCOUNT_MASK))) { *buf++ = (uint8_t)(base->MRDATAB & I3C_MRDATAB_VALUE_MASK); rxSize--; if ((flags & (uint32_t)kI3C_TransferDisableRxTermFlag) == 0UL) { if ((!isRxAutoTerm) && (rxSize == 1U)) { base->MCTRL |= I3C_MCTRL_RDTERM(1U); } } } 它读取数据的大小取决于数据的大小。 我测试了 i3c 中断演示，它支持这一功能。 我将dataSize设置为 50。 它从来没有挂过。 您可以试试看。 BR 哈利

使用 HSE 导入 RSA 中间证书的问题 您好， 我们目前在使用 HSE API 导入和验证 RSA 中间证书时遇到一个问题。 在进行必要的修改以支持 RSA 证书后，我们尝试导入中间 RSA 证书，并使用相应的根公钥对其进行验证。然而，尽管尝试了证书结构中 tbsOffset、tbsLen 和 signOffset 值的各种组合，HSE 始终返回响应代码：hse_srv_rsp_verify_failed 我们已经验证了证书和使用的密钥数据，根公钥的配置似乎是正确的。在不同的偏移配置和证书中，问题依然存在。 能否请您帮助我们找出可能出错的地方，或指导我们如何正确理解 RSA 证书结构中的偏移量（尤其是 rsaModulusOffset、rsaExponentOffset、tbsOffset、tbsLen 和 signOffset）？此外，HSE 内部是否有任何具体要求或检查可能导致核查失败？ 我们采用的方法与 hse_certificate.c 中演示的 ECC 证书导入方法（通过 HSE_ImportECCCert）相同。文件，该文件在 HSE FW 版本 HSE_DEMOAPP_S32G3XX_0_2_64_0 中共享。为了供您参考，我们附上了此文件和我们的请求。 如有需要，我们很乐意提供更多详细信息，如证书内容、根公钥和服务描述符配置。 期待您的支持。 Re: Issue with RSA Intermediate Certificate Import using HSE 你好，@Anup97 谢谢您的帖子。 我已经提到它也被张贴在私人文件夹中，让我直接在那里回复你，因为共享文件更方便。 感谢您的理解。 BR 切宁

TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. Howdy. I'm working with a client project, 27-30V, 550W designed using TEA2017 PFC and LLC. Now originally we were using Fixed Freq 55khz for PFC and the mosfets temps were hotter than usual but still controllable via heatsinks, but now we are trying to make our PFC more efficient. Hence utilizing DCM/QR/CCM mode. Unfortunately in our design in DCM/QR/CCM mode the mosfets rapidly goes up to the failure Temps.  things we have tried but didn't work: 1: Using transistors for gate drivers to drive the pfc gate hard 2: Confirming Our switching is happening after rigning period and when the DrainPFC was falling. 3. Disabling LLC and connect load directly to Vboost to test/tune PFC (result: tea didn't switch pfc the Vboost stayed at 327V (SNSBoost at 2V)) We haven't changed much with our design or TEA settings, as we are trying to test DCM/QR/CCM. Any help/clue int he right direction will be very helpful. I have posted the PFC part of the schematic, and CONFIG_D is what we use. Re: TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. HI  1: You should confirm which component getting hot the inductor or others,then provide the heat dissipation solution. 2: You can also configure the circuit as attached excel calculate sheet then update your schematic.

TEA2017启动异常 我参照UM11613文件，设计PFC+LLC电路，计划输出58V/13A。(TEA2017外围电路参数目前均与UM11613设计文件相同) 谐振腔参数为Lr=22uH,Lm=150uH,Cr=220nF ,输出暂采用带中心抽头的异步整流方式 目前在TEA2017上电启动后，仅能工作几百us就会停止工作。使用Ringo查看MTP并未看到触发保护（TEA2017所有参数默认）。这种情况下我应该检查哪一部分的电路，使其能正常工作？ Re: TEA2017启动异常 亲爱的 Yi 感谢您提供的补充信息。请使用设计工具中的推荐元器件。此外，MOSFET 和请按照 Magnetic_Implementation sheet 中的建议创建相应的电感器和变压器。 我可能需要联系应用工程师，就您的问题寻求建议。他们总是要求提供以下信息。 请分享： 客户：? 最终客户：?(可以与客户相同） 最终应用： ? 国家： 中国中国 年产量：? 致以最崇高的敬意 约瑟夫 Re: TEA2017启动异常 在我的次级侧，只有一个 TL431 反馈电路，而且我没有驱动任何负载。 Re: TEA2017启动异常 我将 Cr 改为 147 nF，但结果仍和以前一样。将温度从 333 K 调到 233 K 后，它就停止工作了。 我使用您提供的 Excel 工具进行了计算，结果显示 fo=88千赫.我不明白为什么 TEA2017 在 233 K 时停止工作。 在项目 2.1 中，我参考了 UM11613 中的 LLC 驱动器设计，并使用晶体管进行关断，这与第 2.1 节中指定的设置不同。在这种情况下，我应该如何调整参数设置，还是可以忽略这种差异？ 我已经购买了 TEA2017/3Y，到货后将用于后续测试。 非常感谢你们的帮助。 Re: TEA2017启动异常 亲爱的 Yi 我认为，随着负载的增加，TEA2017 试图通过降低频率来应对负载。这是所有 LLC 控制器的正确行为。然而，随着频率的降低，它已达到增益曲线的峰值，进一步降低频率将无法增加增益=功率来应对负载的增加，反而会降低增益=功率。 您需要对 LLC 进行设计，使增益曲线的增益峰值向左和向上移动，这样随着负载的增加=>频率的降低，增益峰值就不会达到。请将 Cr 从 220nF 减少到例如150nF。这将改变增益曲线，使其能够应对功率的增加。 您可以使用我在上一个答案中附上的 LLC 设计工具。输入所需的规格，将计算出您的 TEA2017 外部元器件。 另外，请考虑使用改进后的 TEA2017AAT/3 代替 TEA2017AAT/2。请参见附件。 致以最崇高的敬意 约瑟夫 Re: TEA2017启动异常 我使用的是 TEA2017AAT/2，注意到在触发信号停止输出之前，谐振频率突然从 333K 下降到 233K。为什么会这样？ Re: TEA2017启动异常 亲爱的 Yi 您使用的是哪个 TEA2017？我们建议使用最新的TEA2017AAT/3版本。 请将 Cr 从 220nF 降至 150nF，并观察启动行为。 请使用随附的设计工具来计算推荐的元器件。 致以最崇高的敬意 约瑟夫

"S32G2 定制硬件上的同步中止" 处理器，esr 0x96000210 - 访问 LPDDR4 时崩溃 亲爱的社区成员 我们在基于 S32G274 的硬件上遇到了启动问题，引导加载程序因数据中止异常而失败。 设置详情： 启动方法：QSP I 图像带集成 ramdisk 的定制 FIP 映像 闪存方法：S32DS 闪存工具和 Lauterbach（两种方法都会出现问题） 电路板支持包。 版本：43.0 启动加载程序： U-Boot 2022.04+gc01b3bf7b1+p0 SoC：S32G274A 我们能够配置 DDR 并能够启动直到 uboot 提示为止。但是在那之后访问DDR时崩溃， ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 请查找以下详细信息以供参考。 => md 80000000 1000 " Synchronous Abort" handler, esr 0x96000210 elr：00000000ff91cb68 lr : 00000000ff91cab8 (reloc) elr：00000000ff91cb68 LR : 00000000ff91cab8 x0 : 0000000000000009 x1 : 00000000ffbc66e8 x2 : 00000000fffffe x3 : 000000000020 x4 : 000000000000 x5 : 00000000ffbc66e0 x6 ：000000000030 x7 : 00000000ffbc6630 x8 : 000000000010 x9 : 0000000000000002 x10: 00000000ffffffd8 x11: 000000000010 x12: 000000000001 x13: 000000000001 x14：000000000030 x15: 000000000021 x16: 00000000ff8af778 x17: 000000000000 x18: 00000000ffbcfd80 x19: 0000000000000004 x20: 0000000000000004 x21: 0000000000000004 x22：0000000080000000 X23: 00000000ffbc66e9 X24: 000000000000 X25: 00000000ffbc6698 X26: 00000000ff9398a7 X27: 0000000000000008 X28: 0000000000000004 X29: 00000000ffbc6630 代码：2a0403f3 17ffffcb 7100129f 54000181 (b94002c3) RESET CPU... 正在重置... 注意：RESET 状态：上电复位 注意：BL2：v2.10.7（版本）：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- ----------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ U-启动 2022.04+gc01b3bf7b1+p0(Nov 21 2024 - 14:00:36 +0000) SoC：NXP S32G274A rev.2.1 CPU：Arm Cortex-A53 r0p4 @ 最大 1000 MHz 型号：S32G2-平台 动态随机存取存储器(DRAM)：4 GiB 内部 dm_init_and_scan............ pfeng_mdio mdio@2：EMAC MDIO ID 超出范围 88Q5152 RESET 核心：291 个设备，24 个 uclasses，devicetree：板 MMC：FSL_SDHC：0 从 SPIFlash 加载环境... SF：检测到页面大小为 256 字节的 mt35xu01gbba，擦除大小为 4 KiB，总计 128 MiB *** 警告 - CRC 错误，使用默认环境 s32cc_serdes_phy serdes @40480000：对 SerDes 子系统使用模式 0 pci_s32cc pcie @40400000：DBI 未启用 pci_s32cc pcie @40400000：无法设置 PCI 设备和供应商 ID pcie_s32cc pcie @40400000：DBI R/W 未启用 s32cc_serdes_phy serdes @40480000：无法锁定 PCIe phy s 32cc pcie cc_serdes_phy serdes @40480000：PHY：无法开机 @40480000: -110。 pci_s32cc pcie @40400000：无法开启 PHY 'serdes_lane0' pc i_s32cc pcie @40400000：无法设置 PCIe 主机设置 输入：串行 @401c8000 输 出：串行 @401c8000 错误：串行 @401c8000 主 板版本：RDB2 网络： 找到 PFE 版本 0x50300 (S32G2) pfeng pfeng-base：上传类固件 pfeng pfeng-base：EMAC0 区块已初始化 pfeng pfeng-base：EMAC1 区块已初始化 pfeng pfeng-base：EMAC2 区块已初始化 pfen g pfeng-base：启用 CLASS 区块 pfen g pfeng-base：PFE 平台已启动 成功（掩码：7） pfeng_netif pfe0：无法获取 “emac0_xpcs” PHY eth1：pfe0pfeng_netif pfe1：无法获取 “emac1_xpcs” PHY，eth2：pfe 1，eth3：pfe2 按任意键停止自动启动：0 切换到分区 #0，好的 mmc0（第 0 部分）是当前设备 ** 没有分区表-mmc 0 ** 找不到分区 mmc 0:2 无法设置区块设备 mcr=cc000f03 ip cr=3400000f flashcr=3030100 buf0cr=3f000000 buf1cr=3f000000 buf2cr=3f000000 buf3cr=80000 bufgencr=e00000 buf0ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1 cr=0 buf1ind=0 buf2ind=0 awrcr=0 dllcra=d 0080c2 par itycr=0 sf ar=2c03 sfacr=0 spr=33 rbsr=0 rbct=1f000000 awrsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=0 dllsr=f4c0000 dlcr=ff40ff40 dlsr_fa=0 tbdr=0 tbct=0 sr=0 380002 fr=1000009 rser=0 sptrclr=0 dlpr=433455aa = > 运行 flashboot 从闪存启动... 在偏移量 0x00000000 处读取 17629184 字节 " 错误 " 处理器，esr 0xbf000002 elr：00000000f8f5f6c lr：00000000f8f5e68 (reloc) elr：00000000f8f5f6c lr：00000000000000 x1：000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:000000000000 x2:00000000000ba0 x3:0000000000003f x4:0000000000000002 x5:000000001fe00411 x6:0000000000000000 x7:00000000000011 x8:000000000000000011 x8:0000000000000008 x10:00000000000002 x11:000000001fe00000 x12 : 00000000000001 x13:0000000000003f x 14:00000000000000 x15:00000000000021 x 16:000000000000001 x17:0000000000000000 x18:000000000000000000 x 18:0000000000bcfd80 x19:0000000000000000000 x21:00000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22:00000000002b0000 x22:0000000000002b0000 x22:0000000000002b0000 x22: x23:00000000007d2dc2 x24:00000000000007 x25:00000000000000 x26:00000000000001 x27:00000000000001 x27:00000000000001 x28:00000000010d0000 x29:00000000ffbc6130 代码：d1000694 380016c0 17fffbd f8606aa1 (f8206ac1) RESET CPU... 正在删除使用次数 1 的 MTD 设备 #5（内核）删除分区时 出错 " 内核 " (-16) 正在 RESET... 注意：RESET 状态：破坏性 RESET（运行） 通知：BL2：v2.10.7（版本）：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 我们希望得到任何指导或建议来帮助解决这个问题。 敬上， Vishal G Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to 你好，@vishalg 感谢您的回复。 日志显示"Internal error: synchronous external abort" ，这表明在访问某些地址时发生了异常，可能与访问未映射内存或权限不一致有关。 不确定您是否修改了 GIC 部分的默认 dts？您是否检查了 gic_iterate_rdists 中使用的内存？ BR 切宁 Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to Hi Chenyin, 感谢您的快速回复。 我能够通过使用 S32 Design Studio 执行 DDR 验证测试并使用重新生成的配置正确配置 DDR 来解决这个问题。 现在我能够成功地启动 uboot 进入内核，我在启动时观察到内核崩溃，这是由 " 内部错误触发的：在运行 Linux 6.6.52-rt43 的自定义 S32G274A 平台上初始化 GICv3 中断控制器时发生的内部错误：同步外部中止 "。 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 注意：RESET状态：上电复位 注意：BL2：v2.10.7(版本)：bsp43.0-2.10.7-dirty 注意：BL2：版本：2024 年 11 月 26 日 08:17:37 注意：BL2：正在启动 BL31 U-启动 2022.04+gc01b3bf7b1+p0(Nov 21 2024 - 14:00:36 +0000) SoC：NXP S32G274A rev.2.1 CPU: Arm Cortex-A53 r0p4 @ 最大 1000 MHz 型号: S32G2-平台 动态随机存取存储器(DRAM): 3.5 GiB 内部 dm_init_and_scan............ pfeng_mdio mdio@2: EMAC MDIO ID 超出范围 88Q5152 RESET 核心: 291 个设备, 24 个 uclasses, devicetree: 板 MMC: FSL_SDHC: 0 从 SPIFlash 加载环境... SF: 检测到页面大小为 256 字节的 mt35xu01gbba, 擦除大小为 4 KiB, 总计 128 MiB *** 警告 - CRC 错误, 使用默认环境 s32cc_serdes_phy serdes @40480000：对 SerDes 子系统使用模式 0 pci_s32cc pcie @40400000：DBI 未启用 pci_s32cc pcie @40400000：无法设置 PCI 设备和供应商 ID pcie_s32cc pcie @40400000：DBI R/W 未启用 s32cc_serdes_phy serdes @40480000：无法锁定 PCIe phy s 32cc pcie cc_serdes_phy serdes @40480000：PHY：无法开机 @40480000: -110。 pci_s32cc pcie @40400000：无法开启 PHY 'serdes_lane0' pc i_s32cc pcie @40400000：无法设置 PCIe 主机设置 输入：串行 @401c8000 输 出：串行 @401c8000 错误：串行 @401c8000 主 板版本：RDB2 网络： 找到 PFE 版本 0x50300 (S32G2) pfeng pfeng-base：上传类固件 pfeng pfeng-base：EMAC0 区块已初始化 pfeng pfeng-base：EMAC1 区块已初始化 pfeng pfeng-base：EMAC2 区块已初始化 pfen g pfeng-base：启用 CLASS 区块 pfen g pfeng-base：PFE 平台已启动 成功（掩码：7） pfeng_netif pfe0：无法获取 “emac0_xpcs” PHY eth1：pfe0pfeng_netif pfe1：无法获取 “emac1_xpcs” PHY，eth2：pfe 1，eth3：pfe2 按任意键停止自动启动：0 切换到分区 #0，好的 mmc0（第 0 部分）是当前设备 ** 没有分区表-mmc 0 ** 找不到分区 mmc 0:2 无法设置区块设备 mcr=cc000f03 ip cr=3400000f flashcr=3030100 buf0cr=3f000000 buf1cr=3f000000 buf2cr=3f000000 buf3cr=80000 bufgencr=e00000 buf0ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1cr=0 buf1ind=0 buf1 cr=0 buf1ind=0 buf2ind=0 awrcr=0 dllcra=d 0080c2 par itycr=0 sf ar=2c03 sfacr=0 spr=33 rbsr=0 rbct=1f000000 awrsr=0 dllsr=0 dllsr=15c0000 dlcr=ff40ff40 dlsr=0 tbdr=0 tbct=0 sr=0 sr=0 sr=0 sr=0 sr=0 sr=0 sr=0 0002 fr=1000009 rser=0 sptrclr=0 dlpr=433455aa = > 运行 flash boot 从闪存启动... 在偏移量 0x00000000 处读取 17629184 字节在偏移量 0x00000000 处 读取 196608 字节在偏移量 0x00000000 处 读取 32571392 字节 ## Loading init Ramdisk from Legacy Image at 90000000 ... Image Name: fsl-image-base-s32g2-platfo Image Type: AArch64 Linux RAMDisk Image (uncompressed) Data Size: 29917545 Bytes = 28.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## 扁平化设备树 blob 在 0x83000000 处使用 fdt blob 启动使用设备树位于 00000083000000，结尾 000000830120ae 正在启动内核... 无法选择模式：-70 device_remove：设备 '[email protected]'无法删除，但是孩子们不见了 [0.000000] 在物理 CPU 上启动 Linux 0x0000000000 [0x410fd034] [0.000000] Linux 版本 6.6.52-rt43-g1a29a32be610-dirty (oe-user@oe-host) (aarch64-fsl-linux-gcc (GCC) 11.4.0、GNU ld (GNU Binutils) 2.38.20220708) #1 SMP PREEMPT_RT Thu Nov 21 09:35:09 UTC 2024 [ 0.000000] Machine model: s32g274 Platform [ 0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '') [ 0.000000] printk: legacy bootconsole [linflex0] enabled [ 0.000000] OF: reserved mem：0x0000000034000000..0x000000003407ffff (512 KiB) nomap non-reusable pfebufs@34000000 [ 0.0000000000] OF: reserved mem：0x0000000034080000..0x000000003409ffff (128 KiB) nomap non-reusable pfebufs@34080000 [ 0.000000] Reserved memory: created DMA memory pool at 0x0000000083200000, size 3 MiB [ 0.000000] OF: reserved mem: initialized node pfebufs@83200000, compatible id shared-dma-pool [ 0.000000] OF: reserved mem：0x0000000083200000..0x00000000835dffff (3968 KiB) nomap non-reusable pfebufs@83200000 [ 0.0000000000] OF: reserved mem：0x00000000835e0000..0x00000000835fffff (128 KiB) map non-reusable pfebufs@835e0000 [ 0.000000] OF: reserved mem：0x0000000084000000..0x0000000084ffff (16384 KiB) nomap non-reusable shm@84000000 [ 0.0000000000] OF: reserved mem：0x00000000c0000000..0x00000000c03fffff (4096 KiB) nomap non-reusable shm@c0000000 [ 0.0000000000] OF: reserved mem：0x00000000c0400000..0x00000000c07fffff (4096 KiB) nomap non-reusable shm@c0400000 [ 0.000000] OF: reserved mem：0x00000000d0000000..0x00000000d000007f (0 KiB) nomap non-reusable shm@d0000000 [ 0.0000000000] OF: reserved mem： 0x00000000d0000080..0x00000000d00000ff (0 KiB) nomap non-reusable shm@d0000080 [ 0.000000] OF: reserved mem：0x00000000ff600000..0x00000000ff7fffff (2048 KiB) nomap non-reusable atf@ff600000 [ 0.000000] 区域范围： [ 0.000000] DMA [mem 0x0000000080000000-0x00000000ffffffff] [ 0.000000] DMA32 空 [ 0.000000] 正常 [mem 0x0000000100000000-0x00000008dffffffffffff] [ 0.000000] 每个节点的可移动区域起点 [ 0.000000] 早期内存节点范围 [ 0.000000] 节点 0: [mem 0x0000000080000000-0x00000000831fffff] [ 0.000000] 节点 0: [mem 0x0000000083200000-0x00000000835dffff] [ 0.000000] 节点 0： [mem 0x00000000835e0000-0x0000000083ffffff] [ 0.000000] 节点 0： [mem 0x0000000084000000-0x0000000084ffffff] [ 0.000000] 节点 0： [mem 0x0000000085000000-0x00000000bffffffff] [ 0.000000] 节点 0： [mem 0x00000000c0000000-0x00000000c07ffffff] [ 0.000000] 节点 0： [mem 0x00000000c0800000-0x00000000cfffffff] [ 0.000000] 节点 0： [mem 0x00000000d0001000-0x00000000ff5fffff] [ 0.000000] 节点 0： [mem 0x00000000ff600000-0x00000000ff7fffff] [ 0.000000] node 0: [mem 0x00000000ff800000-0x00000000ffffffff] [ 0.000000] node 0: [mem 0x0000000880000000-0x00000008dffffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000008dffffffff] [ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges [ 0.000000] cma：在 0x00000000ef600000 保留 256 MiB on node -1 [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci：固件中检测到 PSCIv1.1。 [ 0.000000] psci：使用标准 PSCI v0.2 功能 ID [ 0.000000] psci：不支持 MIGRATE_INFO_TYPE。 [0.000000] psci：SMC 通话约定 v1.4 [0.000000] percpu：嵌入式 20 页/CPU s42112 r8192 d31616 u81920 [0.000000] pcpu-alloc：s42112 r8192 r8192 d31616 u8192 d31616 u8192 d31616 u81920 alloc=20*4096 [0.000000] pcpu-alloc：[0] 0 [0] 1 [0] 1 [0] 2 [0] 3 [0.000000] 在 CPU0 上检测到 VIPT i-Cache [0.000000] CPU 功能：已检测：GIC 系统寄存器 CPU 接口 [0.000000] CPU 功能：已检测：ARM erratum 845719 [0.000000] CPU 功能：已检测：恩智浦勘误表 ERR050481（VA 的 TLBI 处理不正确） [0.000000] CPU 功能：已检测：ARM 勘误表 1165522、1319367、1530923 或 1530924 [0.000000] 备选方案：应用启动替代方案 [0.000000] 内核命令行：console=ttylf0,115200 root=/dev/ram rw earlycon [0.000000] Dentry 缓存哈希表条目：524288（顺序：10，4194304 字节，线性）[0.000000]] inode-Cache 哈希表条目：262144（顺序：9，2097152 字节，线性） [0.000000] 内建 1 个区域列表，移动分组开启。 总页数：903167 [ 0.000000] Mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] software IO TLB: area num 4. [ 0.000000] software IO TLB: mapped [mem 0x00000000eb600000-0x00000000ef600000] (64MB) [ 0.000000] Memory：3194416K/3670012K 可用 (9856K 内核代码, 686K rwdata, 3012K rodata, 1856K init, 245K bss, 213452K reserved, 262144K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] RCU：可抢占式分层 RCU 实现。 [ 0.000000] RCU：已启用 RCU 事件跟踪。 [ 0.000000] RCU：RCU 限制 CPU 从 NR_CPUS=8 到 nr_cpu_ids=4。 [ 0.000000] RCU：RCU 优先级提升：优先级 1 延迟 500 毫秒。 [ 0.000000] rcu：RCU_SOFTIRQ 处理移至 rcuc kthreads。 [ 0.000000] 没有加速宽限期（rcu_normal_after_boot）。 [ 0.000000] 启用任务 RCU 的蹦床变体。 [ 0.000000] 启用任务 RCU 的跟踪变量。 [ 0.000000] RCU：RCU 计算出的调度程序启动延迟值为 100 jiffies。 [ 0.000000] rcu：Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS：64, nr_irqs: 64, preallocated irqs: 0 [ 0.000000] GICv3: GIC：使用分割 EOI/Deactivate 模式 [ 0.000000] GICv3：实现 544 个 SPI [ 0.000000] GICv3：实现 0 个扩展 SPI [ 0.000000] GICv3：MBI 范围 [167:182] [ 0.000000] GICv3：使用 MBI 帧 0x0000000050800000 [ 0.000000] 根 IRQ 处理程序：gic_handle_irq [ 0.000000] 内部错误：同步外部中止：0000000096000010 [#1] PREEMPT_RT SMP [ 0.000000] 链接到的模块： [ 0.000000] CPU：0 PID: 0 Comm: swapper/0 Not tainted 6.6.52-rt43-g1a29a32be610-dirty#1 [ 0.000000] Hardware name: s32g274 Platform (DT) [ 0.000000] pstate：600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : gic_iterate_rdists+0x4c/0x114 [ 0.000000] lr : gic_init_bases+0x198/0x664 [ 0.000000] sp : ffffffc080e83b80 [ 0.000000] x29: ffffffc080e83b80 x28: 0000000080ca6074 x27: 000000000000 [ 0.000000] x26: 000000000000 x25: ffffffc080e8c208 x24: 000000000018 [ 0.000000] x23： 000000000000ffe8 x22： 000000000000 x21： ffffffc08040ed84 [ 0.000000] x20： ffffffc0809f9b60 x19： ffffffc081000000 x18： 0000000000000030 [ 0.000000] x17: 6a20303031207369 x16: 2079616c65642074 x15: ffffffffffff1660 [ 0.000000] x14: 000000000000 x13: 7172695f656c646e x12: 61685f636967203a [ 0.000000] x11 : ffffffffff0000 x10 : 000000000000000a x9 : ffffffc080e9aa78 [ 0.000000] x8 : 00000000fffff7ff x7 : ffffffc080ec6a78 x6 : 00000000004d [ 0.000000] x5 : ffffff885f8479c8 x4 : 000000000000 x3 : 000000000000 [ 0.000000] x2 : 000000000000 x1 : ffffff88000030e0 x0 : ffffffc08100ffe8 [ 0.000000] Call trace: [ 0.000000] gic_iterate_rdists+0x4c/0x114 [ 0.000000] gic_init_bases+0x198/0x664 [ 0.000000] gic_of_init+0x2a8/0x308 [ 0.000000] of_irq_init+0x318/0x3a8 [ 0.000000] irqchip_init+0x18/0x24 [ 0.000000] init_IRQ+0xac/0xc0 [ 0.000000] start_kernel+0x24c/0x5f0 [ 0.］ __primary_switched+0xb4/0xbc [ 0.000000] 代码：d29ffd17 9b387eda f87a6833 8b170260 (b9400000) [ 0.000000] ---[ 结束跟踪 0000000000000000 ]--- [ 0.000000] 内核恐慌 - 未同步：Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 有什么建议可以解决这个问题？ 问候， Vishal Re: "Synchronous Abort" handler, esr 0x96000210 on S32G2 Custom HW - Crash while access to 你好，@vishalg 谢谢您的帖子。 通常，此类问题是由于访问了保护或未映射的内存（如保留内存）造成的，请问您是否修改了默认 BSP43 的内存映射？添加更多保留地址范围？ 您测试过更多地址吗？还有其他地址范围可以用于加载图像吗？ BR 切宁

MC9S12ZVM128 SRAM 双位 ECC 处理 我们正在使用 MC9S12ZVM128，想知道如何处理 SRAM 中的双位 ECC 错误。具体来说，系统是否可以通过使用以下方法执行软件重启来恢复正常运行 CPMUCOP = 0x01; CPMUARMCOP = 0x00；? Re: MC9S12ZVM128 SRAM double bit ECC handling 你好，喇嘛 感谢您的答复。这个问题我们现在已经很清楚了，我相信我们可以结束这个话题。 BR, Mark Re: MC9S12ZVM128 SRAM double bit ECC handling 您好， 让我来概括一下。 在 POR 期间，SRAM 将被初始化。如果检测到双位 ECC 错误： 内存访问受阻。 已通知启动器模块。 7.3.4内存初始化 ... 为避免出现虚假的 ECC 错误报告，允许在首次写入前进行读取的内存操作（如非对齐访问的读取-修改-写入操作）要求在执行首次读取-修改-写入访问之前，内存必须包含有效的 ECC 值。ECC 模块提供在开机阶段将整个内存内容初始化为零的逻辑。在初始化过程中，SRAM 的访问被禁用，RDY 状态位被清零。如果初始化过程完成，则可以访问 SRAM，并设置 RDY 状态位。 POR（上电复位） 它的作用：POR 是通过重新启动电源或由专用 POR 信号触发的全面硬件 RESET。 对 ECC 错误的影响 -SRAM 已清除：所有易失性存储器都丢失，包括损坏的数据。 -ECC 逻辑已 RESET：所有 ECC 错误标志或状态位都被清除。 -寄存器RESET为默认值：所有配置寄存器返回其默认状态。 - 影响：除非从闪存或外部资源重新加载相同的损坏数据，否则系统将重新启动，双位 ECC 错误将不会继续存在。 ________________________________________ COP（计算机正常运行）RESET 它的作用：当软件无法及时维修时，看门狗定时器会触发 COP RESET。 对 ECC 错误的影响 - SRAM 未清除 - ECC 错误持续存在：如果损坏的数据仍在 SRAM 中，ECC 逻辑可能会在重启后再次检测到相同的双位错误。 -寄存器可能保留值：某些寄存器可能会保留其值，具体取决于RESET配置。 ________________________________________ 建议 如果您想保证消除 ECC 错误状态，请使用 POR RESET。如果您正在调试软件故障或从软件故障中恢复，并希望保留内存以供分析，则 RESET COP 可能更合适。 因此，最好确保在 POR 之后检查并处理 RDY，而不使用 RAM。 如果 COP 重新启动了系统，则尝试写入该字，并检查 ECC 错误是否确定。 此致 拉吉斯拉夫

S32G399 PCIe 无法发送 TLP 数据包 如图所示，请帮帮我。目前，我正在使用 S32G399A 芯片，并通过 PCIe 接口将其连接到 FPGA。在这种配置中，S32G399A 行动 RC，FPGA 行动 EP。我现在遇到的问题是可以访问FPGA的配置空间，但是bar0的内存空间无法触发信号TLP。 下图显示了"dmesg" 在操作系统中打印的信息。在"出境" 部分，显示的是 6OB 和 4IB。应如何配置出站和入站，以及应在何处配置？ 另外，原地址 基地址 目标地址分别代表什么？ Re: S32G399 PCIe cannot send TLP packets 你好，@龙岗素 是的，根据测试，在当前的电路板支持包驱动程序下，RC 会根据 EP 的 BAR 设置自动将该区域映射到 32 位/64 位地址空间。 BR 切宁 Re: S32G399 PCIe cannot send TLP packets 您是说 PCIe 位宽与 EP 有关吗？如果 EP 端是 64 位，那么是否无需对 RC 端进行任何修改？ Re: S32G399 PCIe cannot send TLP packets 你好，@龙岗素 感谢您的回复。 S32G PCIe RC 支持 64 位地址访问 例如，我使用另一个 S32G 板作为 EP，修改了 EP 端的 BAR 的相应位，然后从 RC 端的输出启动 RC 后，映射的一个区域是 " 区域 0：4900000000（64 位，可预取）[size=1M] " 的内存，可以通过 64 位地址访问。 详细修改方法可查看自己的 PCIe EP 驱动程序/RM。 BR 切宁 Re: S32G399 PCIe cannot send TLP packets 请问，如何将 PCIe RC 模式配置为 64 位宽？ 目前，我使用 32 位宽度与 FPGA 通信。 Re: S32G399 PCIe cannot send TLP packets 你好，@龙岗素 让我在这里继续支持它。 从显示的日志来看，有 6 个 OB 窗口和 4 个 IB 窗口。 1.OB 窗口和 IB 窗口的数量通常取决于硬件 IP，您认为这些窗口的数量是否足够？ 关于 iatu 的配置，您可以查看驱动程序/pci/controller/dwc 下的驱动程序进行设置。 2。原始地址可以是来自内存功能域的请求中的地址，基本地址可以是主机地址空间中该区域的参考点，而目标地址是 PCIe 功能域中的起点。 BR 切宁 Re: S32G399 PCIe cannot send TLP packets @cehnyin_h Re: S32G399 PCIe cannot send TLP packets 您好，@LONGGANGSU 感谢您的回复。 我发现这个问题也是通过其他渠道提出的，请直接向那里求助。 BR 切宁 Re: S32G399 PCIe cannot send TLP packets 你好，@龙岗素 谢谢你的帖子。 1。看来你在用电路板支持包，哪个版本？ 2。哪些串行器用于连接设备，使用 PCIe x1？ 3.所提到的快照是指哪份文件？ BR 切宁

uboot 跳转到内核会影响 llce_lin 的输出 你好，恩智浦 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出； s32g u-boot 跳转到内核，llce_lin 输出损坏，查询具体代码后找到； u-boot 代码：bootm.c-> announce_and_cleanup ()->cleanup_before_linux (void)-> board_cleanup_before_linux ();-> scmi_reset_agent ()； 我们发现， 由于调用 scmi_reset_agent 函数导致，M 内核配置 lce_lin 停止发送；由于 scmi（系统控制和管理接口）系统控制和管理接口 (SCMI) 是 启动 中的较低级别函数，内核，控制时钟、电源、io、RESET等，其中涉及 s32g 的底层控制逻辑；如何修改或配置为 解决导致 llce_lin 停止的 A-core 初始化问题？ 致以最诚挚的问候 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 注释掉相应的行只是一种测试，并不是建议的解决问题的方法，因为这可能会影响到多个部分，从而导致像你发现的那样的问题。 我认为还需要进一步分析和测试，为了方便讨论和资源共享，请让我帮助创建一个支持案例来继续提供支持，我会直接通过邮件回复您。 很抱歉给您带来不便。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 我现在有一些关于 S32G 时钟的问题，基本上和图片中的问题类似； 1. tf-a 初始化时钟后 tf-a 不会退出吗？ 2. u-启动 和内核如何初始化或使用时钟，需要与 tf-a 通信？ 3. 你能详细解释一下在 tf-a、u-启动 和内核中是如何使用 clk 的吗？ https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/tac-p/1771379/emcs_t/S2h8ZW1haWx8bWVudGlvbl9zdWJzY3JpcHRpb258TFBXQUozUkFGRzZFRjl8MTc3MTM3OXxBVF9NRU5USU9OU3xoSw BR. Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 感谢您的回复， 我测试了评论过的 scmi_reset_agent 函数，并确认在 u-启动-> 内核跳转期间 llce_lin 输出正常。 但是，我发现内核启动后有异常，比如无法访问eth0 ping，因为我不确定是否还有其他问题，所以我没有按照这条线索进行调查； 你建议我做这样的调查吗？ BR. Re: uboot jump to kernel affects llce_lin output 从U-Boot到Linux内核的过渡确实会影响外围设备的输出，包括与LLCE-LIN（低延迟通信引擎——本地互连网络）相关的外围设备的输出，尤其是在恩智浦S32G等复杂的嵌入式系统中。 这主要是由于 U-Boot 和 猴子型 Linux 内核管理和初始化硬件资源 的方式不同 。 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出；s32g u-boot 跳转到内核，llce_lin 输出损坏，查询... 但是，它们的用途不同，管理方式也大不相同。-> U-boot 设备树用于配置和初始化启动过程中所需的硬件元器件，而 Linux 内核则使用设备树来描述内核启动后的硬件配置 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 据我了解，U-boot 不会设置时钟，tfa 会在启动期间设置时钟。 对于当前的问题，您是否介意在测试时注释掉源代码中的 scmi_reset_agent，以检查您的测试是否仍然存在问题？ BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，nxp 我继续在 u-boot 中追踪代码后发现了以下内容： 调用链：scmi_reset_agent (void)-> devm_scmi_process_msg (dev，& scmi_msg)-> scmi_smccc_process_msg (struct udevice *dev, struct scmi_msg *msg)-> arm_smccc_smc (chan-> func_id, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, &res);-> SMCCC smc 对程序集进行了最后的调用，我不知道相关的细节，那么这部分代码是做什么的？它对 M 核心的运行有何影响，如何才能跳过代码执行的这一部分。 BR. Re: uboot jump to kernel affects llce_lin output 你好，chenyin 请提出一个问题，我们现在按如下方式启动流程 bootloader (M7)-> tf-a (A53)-> u-boot (A53)-> 内核 (A53) 我们已经在引导加载程序中配置了 uart 时钟，tf-a 中没有配置 uart 时钟，也没有在 u-boot 中进行任何修改； u-启动 中会重新配置 uart 模块和时钟吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 我建议首先尝试检查 TFA 中的 UART 时钟及其来源。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，切尼 我知道现在就是这样运行的。 你还有其他发现吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 既然你的 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，你的意思是说 UART 和外围设备 PLL3 的时钟也被禁用并在启动加载程序中设置，而不是在 TF-A 中设置？（在 TFA/uBoot 中，TFA/uBoot 只能从启动加载程序继承时钟设置来驱动 UART？） BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，陈怡 u-启动 中的 clk 转储如下所示： => clk dump Rate Usecnt Name ------------------------------------------ 40000000 0 |-- fxosc@40050000 51000000 0 |-- firc 32000 0 |-- sirc 20000000 0 |--ftm0_ext 20000000 0 |-- ftm1_ext 125000000 0 |-- gmac0_ext_rx 125000000 0 |-- gmac0_ext_tx 50000000 0 |-- gmac0_rmii_ref 200000000 0 |-- gmac0_ext_ts 100000000 0 |-- serdes_100_ext 125000000 0 |-- serdes_125_ext 125000000 0 |-- serdes0_lane0_ext_cdr 125000000 0 |-- serdes0_lane0_ext_tx 125000000 0 |--serdes0_lane1_ext_cdr 125000000 0 |-- serdes0_lane1_ext_tx 125000000 0 |-- serdes1_lane0_ext_cdr 125000000 0 |-- serdes1_lane0_ext_tx 125000000 0 |-- serdes1_lane1_ext_cdr 125000000 0 |-- serdes1_lane1_ext_tx 1 0 |-- pfe_mac0_rmii 1 0 |-- pfe_mac1_rmii 1 0 |-- pfe_mac2_rmii 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |-- flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |--linflex_lin 0 0 |-- gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |-- gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |-- qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |--qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |--siul2_reg 51000000 0 |-- siul2_filter 133333333 0 |-- crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |-- eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |-- rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 133333333 0 |-- pit_module 133333333 0 |-- pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 666666660 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |--wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |-- src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 | -- gic_module 133333333 0 | -- mscm_module 133333333 0 | -- mscm_reg 133333333 0 | -- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |-- xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |--pfe0_rx_sgmii 0 0 ||-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |--pfe0_tx_mii 0 0 ||-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |-- pfe1_rx_rgmii 0 0 |-- pfe1_tx_rgmii 0 0 |-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |--pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 |-- pfe2_tx_sgmii 0 0 |-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 `-- llce_per 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |--flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |-- linflex_lin 0 0 |--gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |--gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |--qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |-- qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |-- siul2_reg 51000000 0 |-- siul2_filter 13333333333 0 |--crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |--eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |--rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 13333333333 0 |-- pit_module 13333333333 0 |--pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 66666666 0 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |-- wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |--src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 |-- gic_module 133333333 0 |-- mscm_module 133333333 0 |-- mscm_reg 133333333 0 |-- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |--xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |-- pfe0_rx_sgmii 0 0 |-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |-- pfe0_tx_mii 0 0 |-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |--pfe1_rx_rgmii 0 0 ||-- pfe1_tx_rgmii 0 0 ||-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |-- pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 ||-- pfe2_tx_sgmii 0 0 ||-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 |-- llce_per Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 1. Lin 时钟在引导加载程序中配置； 2. 我们使用 bsp42，在 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，所有其他配置都处于关闭状态，具体取决于启动加载程序的配置； BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 谢谢您的帖子。 1.我想知道 LIN 时钟是在引导加载程序中配置的，还是在 M7 内核上运行的 LIN 应用程序中配置的？ 2。您的测试设置中使用的是哪个版本的电路板支持包？对时钟设置有任何修改吗？你介意分享你的 u-启动 中的时钟转储吗？ BR 切宁