揭开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日志工具。 此致，

启动 QSPI 时 S32g274a 中的 LLCE 固件加载失败 大家好， 我们正在使用 S32g274a，其中所有 LIN 核心都用作 UART，我们还使用中断转发来让 LIN 核心在有 rx 数据时获取中断。一切都与调试器完美配合。但我们面临的问题是，当我们将图像刷入外部启动存储器（如 qspi flash）并从中启动时，代码会在 llce_firmware_load() 处停止。 有什么方法可以解决这个问题吗？ S32G2 #LLCE 回复：启动 QSPI 时 S32g274a 中的 LLCE 固件加载失败 你好@naveenkumar_muthusamy ， 您能提供更多有关您的设置的信息吗？ 我了解您在这个项目中使用 Core M7，我的理解正确吗？ 我知道您使用的是定制板而不是 RDB2，我的理解正确吗？ 您使用的 LLCE FW 是什么版本？ 您使用的 RTD 是什么版本？ 您是从一个例子开始您的项目吗？如果有的话，哪一个？ 您以前能够从 QSPI 启动 LLCE 应用程序吗？ 您能描述一下构建二进制文件并将其刷入 QSPI 闪存的一般过程吗？ 您如何识别程序正在阻止上述函数llce_firmware_load() 中的执行。 提前感谢提供的信息。

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 下がる

s32k3 flash swap requirements? Hi Nxp,     for S32K3 flash swap function, i don't know is there any limitation for it, 1.  is it MUST need hse fw? if not ,is there any simple code example available? 2. if hse fw is MUST, is ab-swap fw needed, or full-mem also works? thanks. Re: s32k3 flash swap requirements? thanks your explanation. Re: s32k3 flash swap requirements? Hi @victory  to be able to perform AB swap, it is necessary to install HSE AB Swap firmware and then call HSE service HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK. It won't work with Full Mem version of the firmware and it won't work without the firmware. You can take a look at HSE examples here: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples Search for function HSE_ActivatePassiveBlock. Or absolute minimalist code without any drivers is to: Write value 0x00000051 (that the ID of HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK service) somewhere to non-cacheable (this is important because Messaging Unit does not see cached data) SRAM memory (not DTCM). And then write address of this value to Messaging Unit MU0, TR1 register. That's all. If you receive response 0x55A5AA33 (that's HSE_SRV_RSP_OK) in RR1 register, the operation was successful. Regards, Lukas

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

OpenAMP support for m33 core on i.mx93 Hey, I know this question has already been asked here Solved: Re: RPMsg support for m33 core on i.mx93 - NXP Community but I do not understand the accepted answer. In the NXP's Real-Time Edge software framework the RPSMG support is only listed for FreeRTOS. The i.mx95 A7 core, however, has already been added lately https://github.com/zephyrproject-rtos/zephyr/pull/86923 So my question is if NXP is planing to add also support for the m33. And if not what would be needed to add support manually? Re: OpenAMP support for m33 core on i.mx93 To enable inter-core communication between Linux (running on the A-core) and Zephyr (running on the M33 core), the recommended starting point is the openamp_rsc_table sample from Zephyr. This sample leverages: - OpenAMP on Zephyr - remoteproc and rpmsg on Linux Prerequisites Linux setup Linux BSP: use NXP's official BSP  https://github.com/nxp-imx/linux-imx/tree/lf-6.12.y Device tree: use the `-rpmsg` variant, e.g. imx93-11x11-evk-rpmsg.dts U-Boot: run `prepare_mcore` before booting Linux  Zephyr setup (M33 core) To run the openamp_rsc_table sample successfully, shared memory between the host and remote cores must be defined using the `zephyr,ipc_shm` property in a DTS overlay. Next, add the MU node in nxp_imx93_m33.dtsi: ``` mu1: mu1@44220000 {     compatible = "nxp,imx-mu";     reg = <0x44220000 DT_SIZE_K(64)>;     interrupts = <21 0>; }; ``` Then, linker script update - add the resource table section in `linker.ld`: ``` #if defined(CONFIG_OPENAMP_RSC_TABLE) SECTIONS {     SECTION_PROLOGUE(.resource_table,, SUBALIGN(8)) {         KEEP(*(.resource_table*))     } GROUP_LINK_IN(ROMABLE_REGION) } #endif ``` Configuration adjustments for i.MX93 The RX and TX IDs on i.MX93 differ from other boards. You must override the default values in the `.conf` overlay file: ``` CONFIG_IPM_IMX_MAX_DATA_SIZE_16=n CONFIG_IPM_IMX_MAX_DATA_SIZE_4=y CONFIG_OPENAMP_WITH_DCACHE=y CONFIG_LOG=y CONFIG_OPENAMP_RSC_TABLE_IPM_RX_ID=1 CONFIG_OPENAMP_RSC_TABLE_IPM_TX_ID=0 ``` Sample PRs https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards https://github.com/zephyrproject-rtos/zephyr/pull/86923 https://github.com/zephyrproject-rtos/zephyr/pull/79220/commits Linux patch requirement For proper operation on i.MX93, apply the following Linux patch: https://lore.kernel.org/imx/CAEnQRZDoYvK-YXLjqbXsRAWDkHrWNOoR1OCCWxs+AfNUDuPB_w@mail.gmail.com/T/ Final steps before execution Before launching the application: Run `prepare_mcore` in U-Boot. Use the `-rpmsg` device tree blob. Follow the steps in the Application Note AN5317. Additional Resources i.MX Linux User Guide - https://www.nxp.com/docs/en/user-guide/UG10163.pdf Application Note AN5317 - https://www.nxp.com/docs/en/application-note/AN5317.pdf Details on the remoteproc, rpmsg, mailbox, and OpenAMP frameworks. It includes examples on how to create the DTS and configuration overlays. Please note that this is specifically an example for the HiFi4 core from the i.MX 8M Plus https://www.youtube.com/watch?v=JqwPljnm2_k&t=14s DTS API, on `zephyr,ipc_shm` - https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/build/dts/api/api.rst?plain=1#L421 Re: OpenAMP support for m33 core on i.mx93 All zephyr IPC support here( Linux kernel OS on the main processor and a Zephyr application on the co-processor) https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards Confirm from the internal team, this is no plan of supporting MPU cm33 now. But I have send your requirement to the internal team, if there is any update will let you know. I am sorry for that.

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 版本。如果该工具不能按预期运行，则应尝试安装用户指南中推荐的版本。 此致 查维拉

eTPU crank, cam, injections and Ignitions on S32K3 Hello, I need to implement drivers to actuate Injections and ignitions phased with crank and cam signals. I need to understand which is the best solution to implement this drivers. My doubt are: 1) The API provided by AN4907SW.zip are compatible with eTPU present in S32K3xx? 2)If no, it's a good solution adapt this API for S32K3xx or the best solution it's use ConfigTool ? There is an example for S32K3xx about this application? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico  Converting data from big-endian to little-endian involves reversing the byte order by adjusting bit shifts and masks according to the data type size. GCC provides built-in functions to simplify this process, for example: uint32_t __builtin_bswap32 (uint32_t x). You can find more details in the GCC documentation: 7.2.3 Byte-Swapping Builtins Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @VaneB , if I understood well , the Automotive functions (CRANK, SPARK...), are made for big endian microcontrollers. To use eTPU with Automotive functions on S32K364 (little endian), I need to download a function set selecting : francescovico_0-1761136257258.pngfrancescovico_0-1761136257258.png And change the functions: uint32_t *fs_memcpy32(uint32_t *dest,uint32_t *source,uint32_t size); void fs_memset32(uint32_t *start,uint32_t value,int32_t size); to swap each 32 bit values to read/write little endian code and parameters, it's true? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico  The S32K39/37/36 Microcontrollers for Electrification Applications, includes eTPU. However, there is currently no dedicated documentation or demo similar to the MPC5634's AN4907 available for these devices. That said, the AN4907 document, demo, and microcode are suitable for the S32K39/37/36 family, but please note that these devices use a little-endian architecture. Therefore, you will need to modify the memory access API. You can refer to the motor control-related modules in the CodeWarrior eTPU Function Selector, which has been updated to little-endian. BR, VaneB Re: eTPU crank, cam, injections and Ignitions on S32K3 Thanks for pointing this out! There was an endianity conversion issue. As a result, the missing tooth mask was not configured correctly and it counted 350 deg per rev resp 700 deg per cycle. Now, the demo app in the original post is fixed. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , Now I'm trying to use Fuel Cyl 1 etpu driver. It seem that  the driver use s24AngleNormalEnd as "start angle" and stop all injections at s24AngleStop. The duration u24InjectionTime it's never respected. It's possible? Attached there is a .rar file that contain  picoscope acquisition of "fuel cyl 1" where the injector parameter are: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd = DEG2TCR2(-180), .s24AngleStop = DEG2TCR2(-360), .s24AngleOffsetRecalc = DEG2TCR2(-30), .u24InjectionTime = USEC2TCR1(1200), .u24CompensationTime = USEC2TCR1(0), .u24InjectionTimeMinimum = USEC2TCR1(0), .u24OffTimeMinimum = USEC2TCR1(0), .eGenerationDisable = ETPU_FUEL_GENERATION_ALLOWED }; In the picoscope acquisition it's visible start of injection exactly at 180° , stop of injection at 360° and injection duration of 30 ms (it should be 1,2ms). Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl  , Now I'm trying to use Fuel Cyl 1 etpu driver. It seem that  the driver use s24AngleNormalEnd as "start angle" and stop injection ever at s24AngleStop. The duration u24InjectionTime it's never respected. It's possible? Attached there is a .rar file that contain  picoscope acquisition of "fuel cyl 1" where the injector parameter are: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd = DEG2TCR2(-180), .s24AngleStop = DEG2TCR2(-360), .s24AngleOffsetRecalc = DEG2TCR2(-30), .u24InjectionTime = USEC2TCR1(1200), .u24CompensationTime = USEC2TCR1(0), .u24InjectionTimeMinimum = USEC2TCR1(0), .u24OffTimeMinimum = USEC2TCR1(0), .eGenerationDisable = ETPU_FUEL_GENERATION_ALLOWED }; In the picoscope acquisition it's visible start of injection exactly at 180° , stop of injection at 360° and injection duration of 30 ms (it should be 1,2ms). Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , You are right, the s24AngleOffsetRecalc must be a positive number, but putting: s24AngleOffsetRecalc = DEG2TCR2(30) The result it's the same (. I'm using S32K364 that have 2 ETPU (A and B) with 16 channels. Using fuel driver on ETPUA the driver work correctly, but I need to use ETPUB channel 0. My necessity it's to share TCR1 and TCR2 from ETPUA to ETPUB, using STAC registers. It's possible that STAC registers are not correctly initialized? Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico, this is how to configure STAC_ENG1 and STAC_ENG2 registers to share TCR1 and TCR2 from eTPU1 to eTPU2: MilanBrejl_0-1770199430269.pngMilanBrejl_0-1770199430269.png Let me know if it helps.  Regards, Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , my registers are exactly the same of your suggestion: ETPU_A_B_REGISTER.pngETPU_A_B_REGISTER.png But the problem it's still present. In the attached picoscope acquisition you can see the spark generated with ETPU A in BLU and spark generated with ETPU B in RED. Both sparks have end angle 180 degree and dwell time 8000 us. Regards, Francesco.   Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @francescovico, I duplicated your issue on my site and found the root cause. It is not enough to share TCR1/TCR2 time/angle buses between both eTPU engines. Spark and Fuel functions do time to angle transformation, based on the actual engine speed. It uses TRR (Tick Rate Register). This register is part of the Angle Clock logic and it is maintained by Crank eTPU function, running on eTPU A. Hence, TRR has the correct value on eTPU A only. Then, time to angle transformation on eTPU B, using eTPU B TRR, returns a wrong result. This is pretty fundamental, I probably never met anybody running engine control over both eTPU engines and hence this has not been solved. And especially with the new S32K3 devices limited to 16+16 channels this becomes important. Thanks for bringing up this use-case and thanks for your patience. The attached demo application is based on the previous one (in this thread) and adds the following changes: Spark 2 channel is moved from eTPU engine A to eTPU engine B MilanBrejl_0-1770672522362.pngMilanBrejl_0-1770672522362.png Channel masks are updated accordingly MilanBrejl_1-1770672675064.pngMilanBrejl_1-1770672675064.png Channel links need to support usage of both engines (use macro ETPU_IP_CHANNEL_TO_LINK) MilanBrejl_2-1770672729220.pngMilanBrejl_2-1770672729220.png pin configuration is updated, interrupt configuration updated And now new features of Crank eTPU FW: eTPU FW image is updated. The Crank function can run on both engines and update the TRR value also for the other eTPU engine.  This new feature requires to set one new parameter to the Crank configuration MilanBrejl_4-1770673143063.pngMilanBrejl_4-1770673143063.png where MilanBrejl_3-1770673103441.pngMilanBrejl_3-1770673103441.png I hope this helps.  Regards, Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl , Now It's working perfectly. Thank you very much for the support! Regards, Francesco. Re: eTPU crank, cam, injections and Ignitions on S32K3 Hello, I'm also researching the K396 board and want to use ETPU for crankshaft, camshaft, and oil injectors. Could we discuss this further? Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl  I'm currently working on V12 ECU projekt with s32k396.  For the first prototype i will be using the lqfp176 packaging and was happy to see that this project is written in that packaging. I would like to ask you, if there would be a way to have more Linking channel for the crank_instance? Etpu_Crank_Ip_InstanceType crank_instance = { .u8ChanNum = ETPU_CRANK_CHAN, .u8OtherEngChanNum = ETPU_CRANK_OTHER_ENG_CHAN, .ePriority = ETPU_PRIORITY_HIGH, .ePolarity = ETPU_CRANK_IP_POLARITY_FALLING, .u8TeethTillGap = TEETH_TILL_GAP, .u8TeethInGap = TEETH_IN_GAP, .u8TeethPerCycle = TEETH_PER_CYCLE, .u24Tcr2TicksPerTooth = TCR2_TICKS_PER_TOOTH, .u24Tcr2TicksPerAddTooth = 0, .eLogToothPeriods = ETPU_CRANK_IP_LOG_TOOTH_PERIODS_ON, .u32LinkCam = ((ETPU_IP_CHANNEL_TO_LINK(ETPU_CAM_CHAN) << 0) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_CAM_CHAN) << 8) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_CAM_CHAN) << 16) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_CAM_CHAN) << 24)), .u32Link1 = ((ETPU_IP_CHANNEL_TO_LINK(ETPU_SPARK_1_CHAN) << 0) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_SPARK_2_CHAN) << 8) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_SPARK_3_CHAN) << 16) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_SPARK_4_CHAN) << 24)), .u32Link2 = ((ETPU_IP_CHANNEL_TO_LINK(ETPU_FUEL_1_CHAN) << 0) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_FUEL_2_CHAN) << 8) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_FUEL_3_CHAN) << 16) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_FUEL_4_CHAN) << 24)), .u32Link3 = ((ETPU_IP_CHANNEL_TO_LINK(ETPU_KNOCK_1_CHAN) << 0) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_KNOCK_2_CHAN) << 8) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_BANK_1_CHAN) << 16) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_BANK_2_CHAN) << 24)), .u32Link4 = ((ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_1_CHAN) << 0) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_2_CHAN) << 8) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_3_CHAN) << 16) + (ETPU_IP_CHANNEL_TO_LINK(ETPU_INJ_4_CHAN) << 24)), .pCpba = NULL_PTR, .pCpbaToothPeriodLog = NULL_PTR }; I would like to use eTPU engine A for like 12 DI, 12 Ignition, and crank, rightbank intake CAM, rightbank exhaust bank, eTPU engine B for 12 PI injection, and leftside CAM instances. Or perhaps eTPU engine A for 6DI,6Ignition,6PI, Knock, RH CAMx2, eTPU engine B 6DI,6Ignition,6PI, Knock, LH CAMx2. but for this i would need like 2 more Link entries. and im not even counting all the other things i would likely need too. i will want WMI, and Nitro too. i know its a big project but i would really be thankful for some help.  Im new to eTPU programming, and for this whole NXP ecosystem. Thanks in advance for your answer, Richard Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @rudikakk11, If the current set of parameters .u32Link1 to .u32Link4 (up to 16 channels) is extended to .u32Link1 to .u32Link12 (up to 48 channels) would it work for you? Regards, Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi @MilanBrejl  That would be perfect! The eTPU compilers are all pay-to-use? Just in case i would need any more modification or self made functions.  Thank you for your reply and thanks in advance for the next! Richard Re: eTPU crank, cam, injections and Ignitions on S32K3 Hi, @MilanBrejl  One more question, how do you control the HPFP (High Pressure Fuel Pumps) of the GDI engine? I couldnt find a function for it in the libraries. My thought was to use an injection instance for it. Regards, Richard Re: eTPU crank, cam, injections and Ignitions on S32K3 Yes, I think the INJ function is general enough to support various functionality. But I don't know your requirements. Re: eTPU crank, cam, injections and Ignitions on S32K3 The updated Crank function is up at eTPU Function Selector: https://www.nxp.com/webapp/etpu_cw/ It supports linking up to 48 channels on stall.

缺少编译器 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

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 错误是否确定。 此致 拉吉斯拉夫

NXPの日本語技術記事をまとめた「コンテンツ・マップ」を公開 (日本語ブログ) 2025年よりNXP Japanから日本語の技術記事をたくさんユーザーに届けよう！との想いの下、これまでに多数の技術記事(Tech Blog)を公開してまいりました。 これらの情報をより体系的にご活用いただけるよう「コンテンツ・マップ」（PDF）を公開しています。 ＊2026/5/11更新　計94個のコンテンツ 図１．「コンテンツ・マップ」イメージ図（中身は逐次更新します） コンテンツ・マップとは？ 本コンテンツ・マップは、NXP製品に関する技術情報をカテゴリ別に整理したもので、Yocto Linux、EdgeAI、Security、PMIC、Interface、NXPへの技術質問方法など、幅広い分野にわたる記事を網羅しています。各記事へのリンクも掲載しており、目的の情報にスムーズにアクセスできる構成となっています。 ・読みたいコンテンツの右端をクリックいただきますと、該当記事に飛ぶことができます。 図２．記事へのリンク   「Yocto Linux」、「エッジAI」、「I3C, I 2 C」、「セキュリティ」、「Zephyr」などのトピックについては、実装例やトラブルシューティングのヒントを含む実践的な内容が充実しています。これらは、開発現場での課題解決や新規プロジェクトの立ち上げ時に役立つ情報として、多くの技術者の皆様に活用いただいております。 コンテンツもメイントピック毎に色分けしており、ユーザーの状況に合わせたコンテンツを選択いただけます。 ・基礎コンテンツ： 　一般知識、基礎知識、プロトコルの解説など ・手順コンテンツ： 　実際に動かしてみる、環境構築など ・応用コンテンツ： 　深い技術知識、デバッグ手法、応用手順など ＊難易度も目安として★の数で表示しています。 　　　　　図３．カテゴリ分け 今後について 今後もコンテンツ・マップを本ページに公開・更新することを検討しております。より多くの方々にNXPの技術情報を活用いただけるよう努めてまいります。技術者の皆様はもちろん、教育機関や学生の方々にも参考になる内容となっておりますので、ぜひご覧ください。ブックマークも是非♪ 更新時には、SNSでもご案内いたします。 　 　　 　　 　　 現在コンテンツ・マップに掲載の「今後のプラン」は、ほんの一部であり、他にも作成予定のコンテンツが多数ございますため、今後の更新にもご期待ください。 2025年よりNXP Japanから日本語の技術記事をたくさんユーザーに届けようとの想いの下、これまでに多数の技術記事(Tech Blog)を公開してまいりました。これらの情報をより体系的にご活用いただけるよう「コンテンツ・マップ」（PDF）を公開しています。 実装例やトラブルシューティングのヒントを含む実践的な内容が充実しており、開発現場での課題解決や新規プロジェクトの立ち上げ時に役立つ情報として、多くの技術者の皆様に活用いただいております。 (読了：5分) introduction 日本語ブログ

LS1043 GPIO support in Linux SDK This document introduces how to configure RCW to support GPIO on LS1043 platform, how to configure Linux Kernel to load Linux GPIO driver to access GPIO from SYSFS and using loopback method to do verification on the target board. RCW configuration to support GPIO Configure GPIO driver in Linux Kernel Verify GPIO on the target board QorIQ LS1 Devices Re: LS1043 GPIO support in Linux SDK For all those who - like me - were searching for a list to map the individual pins to the GPIO number.. This is the answer I got from NXP Technical Support (thank you, Fedor!): modified table (refer to the QorIQ LS1043A Reference Manual, Table 2-3. CCSR Block Base Address Map): GPIOs 384-415, /soc/gpio@2330000: GPIO4[0-31] GPIOs 416-447, /soc/gpio@2320000: GPIO3[0-31] GPIOs 448-479, /soc/gpio@2310000: GPIO2[0-31] GPIOs 480-511, /soc/gpio@2300000: GPIO1[0-31] even if not all 32 signals are implemented for each GPIOn set, the math is identical - i.e., for GPIO4_03 it is: 384+3=387

ポータブルRFクッキングアプリケーションの設計上の課題 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 調理器具の設計では、家庭の有線電気システムから必要な電力や、安全性と動作温度を維持するために必要な性能について十分に考慮されています。NXPのソリッドステートRF調理チームは、バッテリー電源で動作することができるソリッドステートRFエネルギーを使用してポータブル食品加熱器具を開発しました。このセッションでは、持ち運び可能な外出先で食品を加熱するためのエネルギーを供給するための主要な課題とアプローチについて説明します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 調理器具の設計では、家庭の有線電気システムから必要な電力や、安全性と動作温度を維持するために必要な性能について十分に考慮されています。NXPのソリッドステートRF調理チームは、バッテリー電源で動作することができるソリッドステートRFエネルギーを使用してポータブル食品加熱器具を開発しました。このセッションでは、持ち運び可能な外出先で食品を加熱するためのエネルギーを供給するための主要な課題とアプローチについて説明します。

NET-N1879 5Gの推進:次世代のアクセス技術 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 5G規格が定義される中、高スループット、低遅延、および多数のユーザーが、5Gサービスを推進するための主要な要件の1つです。NXPがこれらの要素をブレンドして、5Gの課題に対処するための最適なハードウェアアーキテクチャを設計している方法をご覧ください。 スマートネットワーク

FTF-INS-F1134 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 备受期待的 i.MX 7 系列专为物联网应用、销售点产品和许多其他成本敏感的嵌入式应用而设计。本课程将揭示下一代 i.MX 系列的更多细节，重点关注安全性、处理能力和低功耗技术。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 备受期待的 i.MX 7 系列专为物联网应用、销售点产品和许多其他成本敏感的嵌入式应用而设计。本课程将揭示下一代 i.MX 系列的更多细节，重点关注安全性、处理能力和低功耗技术。

ESC技术报告.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队

AMF-ACC-T1647 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。

AMF-ACC-T1645 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在仍然执行微控制器应用程序的同时，在闪存中编写第二个应用程序代码映像，然后切换到新的代码映像的需求正在增加。提供了飞思卡尔微控制器架构的示例实现，以演示如何通过应用程序执行进行并发编程并随后重新映射到新的应用程序代码映像。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在仍然执行微控制器应用程序的同时，在闪存中编写第二个应用程序代码映像，然后切换到新的代码映像的需求正在增加。提供了飞思卡尔微控制器架构的示例实现，以演示如何通过应用程序执行进行并发编程并随后重新映射到新的应用程序代码映像。