使用 NXP 密钥对 i.MX93 进行安全调试 SPSDK 中的 nxpdebugmbox 工具的当前版本有一个参数 --nxp-keys，其描述为“使用 ROM NXP 密钥进行身份验证”。 这是否意味着恩智浦可以解锁所有设备上的安全调试功能？ 如果可以，是否有熔丝将安全调试功能限制在 OEM SRK 密钥范围内？ 安全 Re: Secure debug on i.MX93 with NXP keys 但是，如果您控制了 ELE，您就可以访问 DDR 内存，并可以监测 OEM 功能域从 ELE 功能域请求的所有加密操作的输入和输出。您可以解密所有 ELE 数据块，从而访问设备上存储的所有秘密数据。除非阻止写入 DDR 内存，否则您可以将代码注入到 OEM 功能域中。 Re: Secure debug on i.MX93 with NXP keys 你好， 不，NXP 无法使用 --nxp-keys 解锁 OEM 设备上的安全调试。 --nxp-keys 标志仅验证 NXP/ELE 内部调试功能域（使用 ROM 中嵌入的 NXP 密钥）。OEM SoC 调试功能域（Cortex-A55、M33 等）是完全独立的，只能使用 OEM 自己的 SRK 密钥解锁。 无需额外熔丝来强制执行此操作，这是架构设计的一部分。一旦设备进入 OEM_CLOSED 生命周期并熔丝化了 OEM SRK 哈希，ELE 硬件就会强制 NXP 密钥对 OEM 调试功能域没有任何权限。 此致敬礼/Saludos， 阿尔多。

EZH-V 在 IMXRT700 上的应用案例 NXP团队，大家好！ 根据 IMXRT700 的规格说明，它的架构分为媒体、计算和感知功能域三个功能域，芯片上的每个核心都需要自己独立的镜像才能运行。但似乎只有极少数文献记载了 EZH-V 内核的使用情况。 我已阅读应用笔记 AN14614、AN14618 和 AN14654，但关于此核心及其在 RT700 图形处理中的作用的信息仍然很少。据说它是用来实现智能DMA引擎的，但在其他MCX系列MCU中并没有提到这个内核的存在，而且Arm CM33内核可以通过mcuxpresso sdk提供的API直接使用智能DMA。 我现在非常困惑，我还能直接在 iMXRT700 上使用 smartDMA 吗？还是必须按照 AN14614 的说明，通过 LLVM 为 EZH-V 版本镜像？这似乎相当违反直觉，因为 IPC 通信本应由 Cpu0 直接驱动，却不得不求助于 RPMsg。 除此之外，我还没有看到 NXP 提供任何实际的演示或用例来明确地使用 EZH-V 内核。我还查看了一些可用的源头文件，发现其中只提供了一些非常直观的基本操作。请问EZH-V的用途是什么？ Re: EZH-V use case for IMXRT700 好的，快速更新一下，在查看了 Zephyr 主线中的 smartDMA 驱动程序后，我现在明白情况了。 smartDMA 一直以来都被设计成一个独立组网 (SA)的子系统，拥有自己的内核，有可能独立运行固件，但从未真正作为完全独立组网 (SA)的 RISC-V 内核推出。 TomC818_0-1785476896221.png 在当前现有的示例中，smartDMA 从未真正接触过自定义固件安装路径，而只是用作一个略微特殊的 DMA IP。 所以现在的问题应该是，我是否还能以旧的方式使用 smartDMA；直接通过 CM33 调用，而不是进行复杂的 IPC 设置。截至撰写本文时，smartDMA IP 尚未作为官方维护的 mimxrt700_evk 支持的 IP 公开。 TomC818_1-1785477330180.png Re: EZH-V use case for IMXRT700 嗨@mayliu1 ， 感谢您的快速回复，所以您的意思是 smartDMA 不再与 CM33 内核耦合，因此必须通过 EZH-V 内核使用吗？ 在恩智浦的其他MCU系列（例如MCX）中，智能DMA与CM33耦合，可以通过API直接调用。应用笔记AN14172和AN14916记录了此类用例，并且这些用例不涉及构建RISC-V内核的独立组网 \(SA\)镜像。 TomC818_0-1785417939531.png 那么i.MXRT700目前的架构是怎样的呢？所有关于EZH-V的文档都非常含糊不清，而且我目前还没有找到任何全面介绍EZH-V使用的演示或指南。 NXP 是否修改了 smartDMA 的架构，使其不再是 CM33 核心系统的一部分，而是归入 RISC-V 配套核心？我还能通过 CM33 直接调用 smartDMA 吗？ Re: EZH-V use case for IMXRT700 嗨@TomC818 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 根据 AN14614 和 i.MX RT700 参考手册，我的理解是 i.MX RT700 上的 SmartDMA 功能是通过 EZH-V RISC-V 内核实现的，而不是作为传统的 DMA 外设（如 eDMA）。 总的来说，eDMA 仍然是标准内存传输操作的首选解决方案，并且可以通过 CM33 内核直接配置。然而，与 SmartDMA 相关的处理，例如某些图形/数据后处理或数据格式转换任务，通常是由在 EZH-V 内核上运行的固件实现的。 根据 AN14614，CPU0 负责加载和启动 EZH-V 固件，之后实际处理由 EZH-V 执行。从这个角度来看，EZH-V 的行为更像是一个可编程协处理器，而不是传统的 DMA 引擎。 因此，RT700 上的 SmartDMA 最好被视为在 EZH-V 内核上运行的可编程处理引擎，而不是仅由 CM33 直接驱动的传统 DMA 外设。 希望对你有帮助 顺祝商祺！ 5月 Re: EZH-V use case for IMXRT700 嗯……如果恩智浦实际上并没有准备或计划支持“借助 EZH-V，Cortex-M33 内核可以腾出空间执行其他任务。在 EZH-V 执行分配的任务时，CM33 内核可以并行执行其他任务。 ”根据参考手册所述，考虑到 RT700 的文档和示例仍然非常不完善且杂乱无章，我认为我将寻求 ST 或 Infineon 以外的其他选择。对于这款MCU的大多数市场化独特功能，支持非常有限，寥寥无几。对于如此复杂且异构的架构，如此少的例子和指南简直是无稽之谈。 Re: EZH-V use case for IMXRT700 在 i.MX RT700 上，SmartDMA 的公开方式与由 CM33 直接控制的传统独立 DMA 外设不同。 SmartDMA 功能是通过 EZH-V 引擎提供的，因此典型的使用模型是 CM33 加载并启动 EZH-V 固件，然后根据需要与其协调。 mayliu1_1-1785830645435.png

EZH-V use case for IMXRT700 Hi team NXP! From the spec of IMXRT700 it was said to be architected in the 3 domain of media, compute and sense domain, which each of the cores on chip would require their own separate image to run. But it seems that there are only very few documented usage of the EZH-V core. I have read the application notes AN14614, AN14618 and AN14654, but there are still very few information regarding this core and it roles in graphical processing for RT700. It was said that it is used to implement the smartDMA engine, but in other MCX family MCU there are no mentioning of the existence of this core and the smartDMA can be directly used by the Arm CM33 core via the mcuxpresso sdk provided APIs. So now I am extremely confused, can I still directly use the smartDMA on iMXRT700 directly or must I build the image for the EZH-V via LLVM as per AN14614 instruction? This seems quite counterintuitive though having to resort to RPMsg for IPC communication as supposed to be directly driven by the Cpu0. On top of this, I am not aware of any actual demo or use case that has been provided by NXP that explicitly utilized this EZH-V core. I have also review the some of the source headers available, and only some very intuitive basic operations have been provided. May I know what is the usage of the EZH-V? Re: EZH-V use case for IMXRT700 okay quick update, after taking a look of the smartDMA driver in the mainline Zephyr now I understand the situation. The smartDMA has always been/planned as a standalone subsystem with its own core that could have the potential to run firmware on its own, but never have been actually presented as a fully standalone RISC-V core. TomC818_0-1785476896221.png In the current existing example, the smartDMA has never really touched the custom firmware installation path and only used as a slightly special DMA IP. So now the question should pivot to if I could still use the smartDMA in the old fashion; directly invoked via the CM33 instead of doing the complex IPC setup, as of time of writing, the smartDMA IP is yet to be exposed as a supported IP of the official maintained mimxrt700_evk. TomC818_1-1785477330180.png Re: EZH-V use case for IMXRT700 Hi @mayliu1 , Thanks for the quick reply, so you mean the smartDMA is no longer coupled to the CM33 core and therefore must be used via the EZH-V core? In NXP's other MCU family like MCX the smartDMA is coupled to the CM33 and can be directly invoked via APIs, there are application notes documenting such use cases AN14172, AN14916, and they do not involve building the standalone image for the RISC-V core.  TomC818_0-1785417939531.png So what is the current architecture on the i.MXRT700? All documents about EZH-V are very ambiguous and I am not aware of any existing demo or guides that have thoroughly covered the usage of EZH-V.  Has NXP revised the architecture of smartDMA so it is no longer part of the core CM33 system and grouped to the RISC-V companion core instead? Can I still invoke the smartDMA directly via the CM33? Re: EZH-V use case for IMXRT700 Hi @TomC818 ， Thank you so much for your interest in our products and for using our community. According to AN14614 and the i.MX RT700 Reference Manual, my understanding is that the SmartDMA functionality on the i.MX RT700 is implemented through the EZH-V RISC-V core rather than as a conventional DMA peripheral such as eDMA. In general, eDMA is still the preferred solution for standard memory transfer operations and can be configured directly by the CM33 core. However, SmartDMA-related processing, such as certain graphics/data post-processing or data format conversion tasks, is typically implemented by firmware running on the EZH-V core. Based on AN14614, CPU0 is responsible for loading and booting the EZH-V firmware, after which the actual processing is performed by EZH-V. From this perspective, EZH-V behaves more like a programmable coprocessor than a traditional DMA engine. Therefore, SmartDMA on RT700 is better viewed as a programmable processing engine running on the EZH-V core, rather than a traditional DMA peripheral directly driven by CM33 alone. Wish it helps you Best Regards May Re: EZH-V use case for IMXRT700 hey umm... if NXP didn't actually prepare or have any planned support for "With the assistance of the EZH-V, the Cortex-M33 cores can be freed to perform other tasks. While the EZH-V is executing the assigned task, the CM33 cores can execute other tasks in parallel." as per the reference manual described, I think I will be pursuiting a different option from ST or Infineon, considering the fact that RT700 documentations and examples are still extremely unpolished and all over the place. Support for most of the marketted unqiue features of this MCU are very sparse and few between. With such a the complex heterogeneous architecture, such little examples and guides are just abyssal. Re: EZH-V use case for IMXRT700 On i.MX RT700, SmartDMA is not exposed in the same way as a conventional standalone DMA peripheral directly controlled by the CM33. The SmartDMA-style capability is provided through the EZH-V engine, so the typical usage model is for the CM33 to load and start the EZH-V firmware, then coordinate with it as needed. mayliu1_1-1785830645435.png

Capturing CPS with CRANK, mpc5775e Hi, I am using the NXP eTPU CRANK function with a 36-2 crank wheel. The CPS signal is generated with an increasing RPM (acceleration profile). The CRANK parameters (gap_ratio, win_ratio_normal, win_ratio_across_gap, win_ratio_after_gap, and win_ratio_after_timeout) are calculated using the Excel sheet provided with the Function Selector. After the engine position reaches FS_ETPU_ENG_POS_PRE_FULL_SYNC, I call fs_etpu_crank_set_sync() once to synchronize TCR2. I verified that synchronization is applied correctly by checking the TCR2 value before and after the call; it changes by the expected amount. To calculate RPM, after the CRANK state changes from FS_ETPU_CRANK_TOOTH_AFTER_GAP, I copy the tooth period log using fs_etpu_crank_copy_tooth_period_log(), calculate the average tooth period, and then calculate RPM. The first RPM value is calculated correctly. However, after one or a few revolutions, the CRANK function reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL. Once these errors occur, synchronization is lost and I can no longer calculate RPM. The confusing part is that if I reset the debugger and run the application again with exactly the same CPS signal and configuration, sometimes it continues running correctly and I can capture RPM values for a much longer time, while other times the errors appear almost immediately. Because the input signal and configuration are unchanged, I do not understand why the behavior is inconsistent. Could this be related to the window ratio parameters? If so, which parameter should I adjust first for an accelerating crank signal (win_ratio_normal, win_ratio_after_timeout, gap_ratio, etc.)? Is there a recommended procedure for tuning these parameters for rapidly accelerating signals? Thanks! Re: Capturing CPS with CRANK, mpc5775e Hello, My current assessment is that the most likely causes are either window margins that are too tight for the applied acceleration profile, or an incomplete reinitialization that results in different starting conditions after a debugger reset. At this point, I would not consider the root cause confirmed. Based on the information provided, the CRANK function initially achieves synchronization and produces valid RPM values, indicating that the basic configuration is functional. The issue appears later, when the function loses timing acceptance and eventually reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL. To efficiently narrow down the root cause, I would start with two simple experiments: Increase the relevant window ratios and observe whether the timeout/stall condition is delayed or eliminated. Repeat the test with a reduced acceleration slope and compare the behavior to the original profile. If the issue improves with wider windows or a slower acceleration ramp, this would strongly suggest that the failure is related to timing margins rather than a fundamental configuration issue. Best regards, Peter

NXPキーを使用したi.MX93のセキュアデバッグ SPSDKに含まれるnxpdebugmboxツールの現行バージョンには、「ROM NXPキーを使用して認証する」と説明されているパラメータ--nxp-keysがあります。 これはNXPがすべてのデバイスでセキュアデバッグをアンロックできるということでしょうか? はいの場合、OEM SRKキーへのセキュアデバッグを制限するヒューズはありますか？ Security Re: Secure debug on i.MX93 with NXP keys しかし、ELEを制御できればDDRメモリにアクセスでき、OEMドメインがELEドメインから要求するすべての暗号操作の入出力を監視できます。すべてのELEブロブをCAN復号できるため、デバイスに保存されているすべての秘密データにアクセスできます。DDRメモリへの書き込みが禁止されていなければ、OEMドメインにコードを注入することも可能です。 Re: Secure debug on i.MX93 with NXP keys こんにちは、 いいえ、NXPは--nxp-keysでOEMデバイスでセキュアデバッグをアンロックできません。 --nxp-keysフラグは、NXP/ELE内部デバッグドメイン（ROMに組み込まれたNXPキーを使用）のみを認証します。OEMのSoCデバッグドメイン(Cortex-A55、M33など)は完全に別個で、OEM自身のSRKキーでしかアンロックできません。 これを強化するための追加のヒューズは必要ありません。これは設計上、建築的な設計です。デバイスがOEM_CLOSEDライフサイクルに入り、OEM SRKハッシュが統合されると、ELEハードウェアはNXPキーがOEMデバッグドメインに対して一切の権限を持たないことを強制します。 よろしくお願いいたします。 アルド。

使用 CRANK 捕获 CPS，mpc5775e 您好， 我正在使用 NXP eTPU CRANK 功能，搭配 36-2 曲柄轮。CPS 信号随着 RPM 的增加而产生（加速我的）。使用函数选择器提供的 Excel 表格计算 CRANK 参数（gap_ratio、win_ratio_normal、win_ratio_across_gap、win_ratio_after_gap 和 win_ratio_after_timeout）。 当发动机位置达到 FS_ETPU_ENG_POS_PRE_FULL_SYNC 时，我调用 fs_etpu_crank_set_sync() 一次来同步 TCR2。我通过检查调用前后的 TCR2 值来验证同步是否正确应用；它的变化量符合预期。 为了计算转速，在曲轴状态从 FS_ETPU_CRANK_TOOTH_AFTER_GAP 改变后，我使用 fs_etpu_crank_copy_tooth_period_log() 复制齿周期日志，计算平均齿周期，然后计算转速。第一个转速值计算正确。 然而，在转动一两圈后，CRANK 函数会报告 FS_ETPU_CRANK_ERR_TIMEOUT 和 FS_ETPU_CRANK_ERR_STALL 错误。一旦出现这些错误，同步就会丢失，我将无法再计算转速。 令人困惑的是，如果我 RESET 调试器并使用完全相同的 CPS 信号和配置再次运行应用程序，有时它会继续正确运行，我可以捕获 RPM 值更长时间，而有时错误几乎立即出现。由于输入信号和配置均未改变，我不明白为什么会出现不一致的行为。 这是否与窗口比例参数有关？如果是这样，对于加速曲轴信号，我应该首先调整哪个参数（win_ratio_normal、win_ratio_after_timeout、gap_ratio 等）？对于快速加速的信号，是否有推荐的参数调整方法？ 谢谢您！ Re: Capturing CPS with CRANK, mpc5775e 你好， 我目前的评估是，最可能的原因要么是窗口边距对于所应用的加速我的来说太窄，要么是不完整的重新初始化，导致调试器RESET后起始条件不同。 目前，我认为根本原因尚未得到确认。根据提供的信息，CRANK 功能最初实现了同步并产生了有效的 RPM 值，表明基本配置是有效的。问题随后出现，当函数失去定时接受能力时，最终会报告 FS_ETPU_CRANK_ERR_TIMEOUT 和 FS_ETPU_CRANK_ERR_STALL。 为了有效地缩小根本原因的范围，我会先做两个简单的实验： 增加相关窗口比率，观察超时/停滞情况是否被延迟或消除。 以减小的加速度斜率重复测试，并将结果与原始我的进行比较。 如果通过扩大窗口或减缓加速斜坡来改善问题，则强烈表明故障与时间裕度有关，而不是与基本的配置问题有关。 顺祝商祺！ Peter

FS6500 IO2_3/FCCU故障在调试模式和正常模式下的行为差异 你好！   FS6500 的 IO2_3 引脚连接到 MCU FCCU。   在调试模式下，单个 FCCU 故障触发会导致立即复位。   在正常运行模式下，单个 FCCU 故障触发信号会导致 SBC 进入深度故障保护 (DFS) 模式。 请问这种现象是否属于预期行为？ 我的理解是：IO2_3故障将增加故障错误计数器。只有当故障错误计数器超过配置的阈值（3 或 6）时，才应执行功能安全响应（RSTB 脉冲、FS0B 断言或 DFS 转换）。 FS6500 DEVKIT-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 嗨，彼得， 非常感谢您的解释。   我还有一个问题。   我仔细查阅了 FS6500 数据手册和 RM，但几乎没有文档介绍由 IO2_3 FCCU 故障触发信号所触发的功能安全机制策略以及相应的 IMPACT 寄存器配置。 之前我以为 IO2_3 故障会使故障错误计数器递增，功能安全措施会在计数器达到阈值后生效。根据您的回复，IO2/IO3故障会直接触发信号安全响应。   请问手册的哪一章介绍了IO2/IO3直接功能安全反应的配置？ 顺祝商祺！ Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好， 如果两次测试中 SBC 的运行条件不同，则可能会出现这种现象。 请区分以下各项： 例如，MCU调试模式，即调试器连接到MPC设备，以及 FS6500 调试模式，通过 FS6500 DEBUG 引脚进入。 当 FS6500 处于调试模式时，看门狗仍在内部运行，但它不会通过置位 RESET 或故障保护引脚来影响设备操作。因此，调试期间观察到的行为可能与独立组网 \(SA\)/正常运行时的行为有所不同。此模式旨在允许进行软件调试，而无需 SBC 不断重置系统。 在正常运行中，FS6500 故障保护状态机监测已配置的功能安全输入/反应。如果 IO_2/IO_3 用于 MCU FCCU 错误输出监控，则 SBC 可以检测到 FCCU 故障，并执行配置的反应，例如根据配置断言 FS0B/RSTB。 因此，调试模式和独立组网 \(SA\)模式之间的不同行为不一定是MCU FCCU的问题。这很可能是由于 FS6500 处于调试模式，或者两种情况下 SBC 初始化/配置存在差异造成的。 故障错误计数器通常与看门狗监控和故障保护状态机处理等机制相关联。FCCU 报告的功能安全关键故障应直接发出触发信号，以触发其配置的反应，而不是累积到计数器达到阈值。 因此，观察到的即时功能安全响应行为与预期的功能安全理念是一致的。 顺祝商祺！ Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好， 关键在于，FS6500 对 IO2/IO3 FCCU 监控的处理方式与其他大多数故障源不同。 该描述不在 FCCU 故障反应 (IMPACT) 表中，而是在 FS6500 故障保护故障管理文档中。 根据 FS6500 文档，IO_23 错误检测 (FCCU) 被列为始终递增故障错误计数器的故障源之一，并且无法配置为关闭。文档明确将其与可配置故障源区分开来。 因此，观察到的 IO2/IO3 故障行为并非完全由用于可配置故障保护反应的 IMPACT 寄存器设置所控制。IO2/IO3 FCCU 监测器是 SBC 专用的 FCCU 监视路径的一部分，由故障保护状态机处理。 需要查阅的相关章节是 FS6500 文档中的“故障计数器”章节，其中指出： IO_23 错误检测 (FCCU) 会增加故障错误计数器。 此行为不可配置。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html 顺祝商祺！ Peter

S32K311 RTD 5.0 - 链接器错误：.non_cacheable_bss与 .int_results 溢出和重叠 您好，NXP团队： 我正在使用以下环境开发一个S32K311项目： MCU： S32K311 IDE： S32 设计工作室 3.6.7 RTD： S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR： 4.7 问题 项目初期进展顺利。 随着项目的推进，我启用并配置了多个 RTD 驱动程序，包括 ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCL 以及我的应用程序所需的其他外设。 集成这些驱动程序后，项目在链接阶段失败，并出现以下错误： .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status 存储器布局 默认链接器脚本包含以下 SRAM 区域： int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 链接器报告.non_cacheable_bss该部分超出分配的 int_sram_no_cacheable 区域约440 字节。 问题 在 S32K311 上启用多个 RTD 驱动程序时，这种内存使用量是否正常？ 是否有推荐的方法来减小 .non_cacheable_bss 的大小？ 是否建议修改链接器脚本并增加 int_sram_no_cacheable 区域？如果是这样，S32K311 的推荐内存布局是什么？ 是否有任何 RTD 配置选项可以减少分配给不可缓存部分的内存？ 有人在集成多个RTD外设时遇到过类似的问题吗？ 任何指导或建议都将不胜感激。 谢谢！ Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results 嗨@Esakki 以下讨论帖可能对您有所帮助，因为它们讨论了类似的问题，并提供了一些有用的故障排除建议。 int_sram_no_cacheable 问题 S32K312 的 SRAM 溢出 此外，还有一份 S32K3 应用笔记，更详细地解释了链接器文件和启动代码，包括如何修改和自定义内存区域。 AN14893 ：S32K3xx 链接器文件和启动代码 最后一个帖子包含了与代码优化技术相关的一些建议。 S32K3xx 如何优化 APP 代码以获得更高性能 BR，VaneB

MX8-DSI-OLED1 显示屏部件号和序列号。 大家好， 我们也计划在我们的定制板中使用 MX8-DSI-OLED1 配件。 请问能否提供一下显示屏的零件编号，以及是否有任何需要保持的电源顺序？ Re: MX8-DSI-OLED1 Display part No and sequence. 你好， 您能告诉我您想了解哪方面的信息吗？ MX8-DSI-OLED1A（raydium rm67199）的显示屏是支持触摸的 MIPI-DSI OLED 显示屏。以下是一些主要特点： • 5.49 英寸 FHD (1080p@60fps) AMOLED 显示屏 • 1670万色（RGB*8位）显示颜色 • 触摸屏 • 用于显示器的 4 通道 MIPI-DSI 接口 • 用于触摸和控制的 I2C 接口 另外，请注意，关于这部分内容，我们能分享的信息不多。 此致敬礼/Saludos， 阿尔多。 Re: MX8-DSI-OLED1 Display part No and sequence. 大家好， 这件事有任何进展吗？ Re: MX8-DSI-OLED1 Display part No and sequence. 嗨@AldoG 我想了解这些轨道上电是否有任何需要遵循的顺序。 VDD_1V8 VEXT_3V3 VDD_5V

LS1046A カスタムボード - FlexBuildで作成されたイメージは、DTの導管方法のためのpsci: probeingにハングします。 こんにちは、 私はLS1046Aをベースにしたカスタムボードを開発しているのですが、FlexBuildで生成したDebianイメージで起動時に問題が発生しています。 まず最初のステップとして、デフォルトのLS1046AFRWY BSPを一切変更せずにビルドし、自作の基板上でテストしました。カーネル起動中に、以下の出力後にシステムが必ずハングアップします。 PSCI:DTからの導管方法のプロービング。 カーネルパニックや例外は発生せず、システムはこの時点で停止する。 以下のNXPフォーラムのThreadで非常に似た問題を説明しているのを見つけました: https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075 一時的な回避策として、以下のコマンドを使ってU-Bootから手動でLinuxを起動できます。しかし、カーネルは、ブート引数「mem=」を使用して使用可能なメモリを1982MBに制限した場合にのみ正常に起動します。この値を増やすと、カーネルが再びハングアップします（起動中の異なるタイミングで発生することもあります）。 mmc dev 0 パートUUID mmc 0:3 パートUUIDr mmc 0:1 0x81000000 イメージをロードします ロード MMC 0:1 0x90000000 FSL-LS1046A-frwy-SDK.dtb setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M" booti 0x81000000 - 0x90000000 テスト環境： SoC: LS1046A DDR: IS43/46QR16512A (4GB DDR4) ブートメディア:SDカード BSP: FlexBuild (LSDK 25.12) FlexBuild特有の問題を除外するために、Yocto(YP 6.0 / lf-6.18.20)を使って完全に新しいBSPを作成し、同じハードウェアでテストしました。 結果は全く同じだ。カーネルは再び出力後にハングアップします。 PSCI:DTからの導管方法のプロービング。 bdinfoの出力のうち、関連する部分を以下に示します。 DRAMバンク0 開始: 0x80000000 サイズ：0x7be00000 DRAMバンク1 開始: 0x880000000 サイズ：0x80000000 LMBメモリ領域： メモリ[0] ：0x80000000 - 0xfbdfffff メモリ[1] ：0x880000000 - 0x8ffffffff 予約済み[0] : 0xfac154c0 - 0xfbdfffff 予約済み[1] : 0x8ffff5000 - 0x8ffffffff 同様の問題に遭遇した方はいらっしゃいますか？あるいは、次に何を調査すべきかについて何かご提案があれば教えてください。 どんなアドバイスでも大変ありがたいです。 QorIQ LS1デバイス Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from こんにちは、 根本原因 — BL31メモリの衝突 LS1046Aの起動フローは以下のとおりです。 Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux     BL31はDRAMに常駐し、すべてのSMC呼び出し（PSCI： psci_get_version 、CPUのオン/オフなど）を処理します。一般的な配置場所は、 RAMの最上位から約10MiB引いた領域付近で、サイズは最大2MiBです。   Linuxが4GBのDDRマップで起動すると、BL31のリージョンと物理的に重なるページが割り当てられます。最初の PSCI SMC 呼び出し ( psci_get_version ) が、すでに破損したメモリにジャンプし、システムはハングアップします。パニックも例外もなく、ただ沈黙するだけです。 bdinfo の出力は正確なパターンを確認しています。DDR バンク 1 は 0x8FFFFFFFF で終了し、BL31 は約 RAM_END - 10 MiB = 0x8FF600000 にあります。 DDR銀行 スタート 終了 備考 バンク0 0x80000000 0xFBDFFFFF ~1982 MiB —作業 mem= 制限 バンク1 0x880000000 0x8FFFFFFFF 2 GB 高銀行 — BL31 はここに住んでいます mem=1982M の回避策はLinuxをバンク0内に留め、BL31が存在するバンク1には一切触れません。これがまさに機能する理由です。 修正 — デバイスツリーでBL31メモリを予約する 正しい恒久的な解決策は、DTSに reserved-memory ノードを追加 し、BL31のリージョンをLinuxのメモリ割り当てでタブリングにすることです。 ステップ1：BL31がどこに積載されているかを確認する ATFビルド構成を確認してください（ plat/nxp/soc-ls1046a/.../platform_def.h ） BL31_BASE と BL31_SIZE について。FRWY BSPを搭載したLSDK/lf-6.xの場合、一般的な配置は以下のとおりです。 BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB) BL31_SIZE = max 2 MiB     実行時にU-Bootの出力やATFビルドログで BL31: v2.x... Entry point address = ... を確認することができます。 ステップ2：予約メモリノードをDTSに追加します ボードのDTSファイル( fsl-ls1046a-frwy-sdk.dts に基づく)に、以下を追加してください: / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* Reserve BL31 runtime region — adjust addresses to match your ATF build */ bl31_reserved: bl31@8ff600000 { reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */ no-map; }; }; }; dts   0x8ff600000 とサイズ 0x200000 を調整して、ATFビルドからの実際のBL31ロードアドレスに一致させてください。 ステップ3：フルメモリで再構築およびテストする 予約を追加した後、DTB を再構築し、 mem= 回避策 なしで 起動します。カーネルはその領域をスキップし、BL31はそのまま残り、PSCIは正しく機能します。   よろしくお願いします。 Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from こんにちは、 提案された解決策を試してみましたが、残念ながら問題は解決しませんでした。 まず、TF-A（ATF）ビルドからBL31アドレスを確認しました。 - BL31_BASE = 0xFBE00000 - BL31_SIZE = 0x200000 (2 MiB) 次に、BL31ランタイム領域を予約するために、デバイスツリーに「reserved-memory」ノードを追加し、DTBを再構築しました。 その後、「mem=1982M」ブートパラメータなしでシステムを再度起動しました。しかし、システムは依然として同じ箇所で停止したままです。

LX2160A 上的 PCI 设备 ITS 设备 ID 你好， 我使用的是Honeycomb LX2板，它采用的是LX2160A芯片。我检查了uboot和linux代码，发现uboot中每个PCI BDF（桥接器和设备）都被分配了一个流ID，该ID被放入dtb中的msi-map文件中。 我假设 Linux 使用此流 ID 作为每个 PCI BDF 的 ITS 设备 ID，但是当我检查 Linux 代码drivers/irqchip/ irq-gic-v3-its-pci-msi.c时，ITS 特定的设备 ID 似乎只是 RID。 在我目前使用的系统中，BDF 的 ITS 设备 ID 是上游 PCI-PCI 桥的流 ID。此外，2 端口网卡上每个端口的 ITS 设备 ID 都相同。Linux 系统上也存在同样的问题吗？ 请问有人能帮我确认一下Linux系统中PCI设备的ITS设备ID是如何计算的吗？以及网卡的两个端口是否应该共享同一个ITS设备ID？如果不是，那我的系统可能缺少什么呢？ Re: ITS Device ID for PCI devices on LX2160A 我觉得这次讨论很有帮助。在 LX2160A 上使用 ITS 设备 ID 可能很棘手，尤其是在处理 PCI 中断路由和配置细节时。在研究类似技术主题时，我还发现了Citrus Court Resources ，它提供了组织良好的公共记录信息。感谢分享，能够看到其他使用相同硬件的人提供的实用见解总是很有帮助的。 Re: ITS Device ID for PCI devices on LX2160A 关于 LX2160A 上 PCI 设备的 ITS 设备 ID 的讨论非常有启发性，特别是对于从事中断转换和嵌入式系统工作的人来说。在查阅相关技术文档时，我还发现Bibb Court Clerk是一个获取有组织的公共信息的有用资源。感谢您分享这些见解，它们使一个复杂的话题更容易理解和进一步探讨。 Re: ITS Device ID for PCI devices on LX2160A 请另开新帖描述您的新问题。 谢谢！ Re: ITS Device ID for PCI devices on LX2160A 我还有一个硬件方面的问题，希望您能帮我解决。 从调试信息来看，似乎是 PCI 到 PCI 桥接设备而不是 PCI 设备发送了消息信号中断，导致我看到了错误的 ITS 设备 ID。PCI 配置寄存器中的某些设置是否可能导致这种情况发生？ 谢谢！ Re: ITS Device ID for PCI devices on LX2160A 请参阅以下更新 我的理解是这样的： 1. PCIe 设备生成一条中断消息，其中包括其请求者 ID (RID)。 2. ITS 收到此消息后，使用 RID 查找相应的 StreamID。 3. ITS 然后将此信息转换为适合中断控制器的中断消息。 更具体地说， RID（由BDF组成）被ITS用于管理和转换中断。 StreamID 源自与 RID 相同的 BDF，由 SMMU 用于管理和转换 DMA 操作。 Re: ITS Device ID for PCI devices on LX2160A 请参考AE团队的以下更新。 这些问题更多地与 Linux 有关，因此客户可以在 Documentation/PCI/msi-howto.rst 中找到有关 PCI-PCI 桥接器背后的 MSI 分配的信息。 Re: ITS Device ID for PCI devices on LX2160A 谢谢你调查此事。ITS 设备 ID 与映射到 BDF 的 LUT 条目中编程的流 ID 之间是否存在任何关系？ Re: ITS Device ID for PCI devices on LX2160A 与AE团队讨论。 Re: ITS Device ID for PCI devices on LX2160A LX2160A 上的 ITS 设备 ID 处理确实可能很棘手，尤其是在使用不同的 PCI 配置时。在研究类似主题时，我还通过Watauga Property Assessment找到了一些有用的房产数据，这些数据组织得很好。感谢分享这些信息，看到关于复杂硬件行为的实际讨论总是很有帮助的。

LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from DT. Hello, I am working on a custom board based on the LS1046A and I am experiencing a boot issue with a Debian image generated using FlexBuild. As a first step, I built the default LS1046AFRWY BSP without making any modifications and tested it on my custom board. During kernel boot, the system always hangs after printing: psci: probing for conduit method from DT. There is no kernel panic or exception; the system simply stops at this point. I found the following NXP forum thread describing a very similar issue: https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075 As a temporary workaround, I can boot Linux manually from U-Boot using the following commands. However, the kernel only boots successfully when I limit the available memory to 1982 MB using the "mem=" boot argument. If I increase this value, the kernel hangs again (sometimes at different points during boot). mmc dev 0 part uuid mmc 0:3 partuuidr load mmc 0:1 0x81000000 Image load mmc 0:1 0x90000000 fsl-ls1046a-frwy-sdk.dtb setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M" booti 0x81000000 - 0x90000000 Test environment: SoC: LS1046A DDR: IS43/46QR16512A (4 GB DDR4) Boot media: SD Card BSP: FlexBuild (LSDK 25.12) To rule out a FlexBuild-specific issue, I also built a completely new BSP using Yocto (YP 6.0 / lf-6.18.20) and tested it on the same hardware. The result is exactly the same. The kernel again hangs after printing: psci: probing for conduit method from DT. The relevant part of the bdinfo output is shown below: DRAM bank 0 Start: 0x80000000 Size : 0x7be00000 DRAM bank 1 Start: 0x880000000 Size : 0x80000000 LMB memory regions: memory[0] : 0x80000000 - 0xfbdfffff memory[1] : 0x880000000 - 0x8ffffffff reserved[0] : 0xfac154c0 - 0xfbdfffff reserved[1] : 0x8ffff5000 - 0x8ffffffff Has anyone encountered a similar issue or have any suggestions on what I should investigate next? Any advice would be greatly appreciated. QorIQ LS1 Devices Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, Root Cause — BL31 Memory Collision The LS1046A boot flow is: Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux     BL31 remains permanently resident in DRAM and handles all SMC calls (PSCI: psci_get_version , CPU on/off, etc.). Its typical placement is near top-of-RAM minus ~10 MiB, with a size of up to 2 MiB.   When Linux boots with the full 4 GB DDR map, it allocates pages that physically overlap BL31's region. The first PSCI SMC call ( psci_get_version ) jumps into now-corrupted memory and the system hangs — with no panic, no exception, just silence. Your bdinfo output confirms the exact pattern — DDR Bank 1 ends at 0x8FFFFFFFF , and BL31 is at approximately RAM_END - 10 MiB = 0x8FF600000 : DDR Bank Start End Notes Bank 0 0x80000000 0xFBDFFFFF ~1982 MiB — your working mem= limit Bank 1 0x880000000 0x8FFFFFFFF 2 GB high bank — BL31 lives here The mem=1982M workaround keeps Linux within Bank 0, never touching Bank 1 where BL31 resides — which is precisely why it works. Fix — Reserve BL31 Memory in the Device Tree The correct permanent fix is to add a reserved-memory node to your DTS marking BL31's region as off-limits to the Linux memory allocator. Step 1: Find where BL31 is loaded Check your ATF build configuration ( plat/nxp/soc-ls1046a/.../platform_def.h ) for BL31_BASE and BL31_SIZE . For LSDK/lf-6.x with the FRWY BSP, the typical placement is: BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB) BL31_SIZE = max 2 MiB     You can confirm at runtime by checking U-Boot output or the ATF build log for BL31: v2.x... Entry point address = ... . Step 2: Add the reserved-memory node to your DTS In your board DTS file (based on fsl-ls1046a-frwy-sdk.dts ), add: / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* Reserve BL31 runtime region — adjust addresses to match your ATF build */ bl31_reserved: bl31@8ff600000 { reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */ no-map; }; }; }; dts   Adjust 0x8ff600000 and size 0x200000 to match your actual BL31 load address from the ATF build. Step 3: Rebuild and test with full memory After adding the reservation, rebuild the DTB and boot without the mem= workaround. The kernel will skip that region, BL31 remains intact, and PSCI will function correctly.   Regards Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, I tried the suggested solution, but unfortunately it did not resolve the issue. First, I verified the BL31 address from the TF-A (ATF) build: - BL31_BASE = 0xFBE00000 - BL31_SIZE = 0x200000 (2 MiB) Next, I added a "reserved-memory" node to the Device Tree to reserve the BL31 runtime region and rebuilt the DTB. After that, I booted the system again without the "mem=1982M" boot parameter. However, the system still hangs at the same point.

LS1046A 定制板 - 使用 FlexBuild 版本的映像在 psci 处卡住：正在从 DT 探测导管方法。 你好， 我正在开发一款基于 LS1046A 的定制板，在使用 FlexBuild 生成的 Debian 镜像时遇到了启动问题。 首先，我版本了默认的 LS1046AFRWY 电路板支持包。没有做任何修改，并在我的定制板上进行了测试。内核启动过程中，系统总是在打印以下内容后挂起： psci：从DT探测导管方法。 没有内核崩溃或异常；系统就此停止运行。 我在NXP论坛上找到了一个描述类似问题的帖子： https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075 作为临时解决方案，我可以使用以下命令从 U-Boot 手动启动 Linux。但是，只有当我使用“mem=”启动参数将可用内存限制为 1982 MB 时，内核才能成功启动。如果我增加这个值，内核又会挂起（有时在启动过程中的不同阶段）。 mmc dev 0 部分 uuid mmc 0:3 partuuidr 加载 mmc 0:1 0x81000000 图像 加载mmc 0:1 0x90000000 fsl-ls1046a-frwy-sdk.dtb setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M" booti 0x81000000 - 0x90000000 测试环境： SoC：LS1046A DDR：IS43/46QR16512A（4 GB DDR4） 启动介质：SD卡 BSP：FlexBuild（LSDK 25.12） 为了排除 FlexBuild 特有的问题，我还使用 Yocto (YP 6.0 / lf-6.18.20) 构建了一个全新的 电路板支持包。，并在相同的硬件上进行了测试。 结果完全相同。内核在打印以下内容后再次挂起： psci：从DT探测导管方法。 下面显示的是bdinfo输出的相关部分： 动态随机存取存储器\(DRAM\) 存储体 0 起始地址：0x80000000 大小：0x7be00000 动态随机存取存储器\(DRAM\) 存储体 1 起始地址：0x880000000 大小：0x80000000 LMB 内存区域： 内存[0] ：0x80000000 - 0xfbdfffff 内存[1] ：0x880000000 - 0x8ffffffff 保留[0] : 0xfac154c0 - 0xfbdfffff 保留[1] : 0x8ffff5000 - 0x8ffffffff 有没有人遇到过类似的问题？或者有什么建议，让我接下来应该调查哪些方面？ 任何建议都将不胜感激。 QorIQ LS1设备 Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from 你好， 根本原因——BL31 内存冲突 LS1046A 的启动流程如下： Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux     BL31 永久驻留在 动态随机存取存储器\(DRAM\) 中，并处理所有 SMC 调用（PSCI： psci_get_version 、CPU 开/关等）。它的典型位置在RAM 顶部减去约 10 MiB 的位置，大小可达2 MiB 。   当 Linux 使用完整的 4 GB DDR 映射启动时，它会分配与 BL31 区域物理重叠的页面。第一次 PSCI SMC 调用（ psci_get_version ）跳转到已损坏的内存，系统挂起——没有恐慌，没有异常，只有寂静。 您的 bdinfo 输出证实了确切的模式——DDR Bank 1 结束于 0x8FFFFFFFF ，而 BL31 大约位于 RAM_END - 10 MiB = 0x8FF600000 ： DDR银行 开始 结束 说明 银行 0 0x80000000 0xFBDFFFFF ~1982 MiB —您的工作 mem= 限制 银行 1 0x880000000 0x8FFFFFFFF 2 GB 高位银行——BL31 位于此处 mem=1982M 变通方法使 Linux 保持在 Bank 0 内，永远不会触及 BL31 所在的 Bank 1——这正是它有效的原因。 修复——在设备树中预留 BL31 内存 正确的永久解决方法是在 DTS 中添加一个 reserved-memory 节点，将 BL31 区域标记为 Linux 内存分配器禁止访问。 步骤 1：找到 BL31 的加载位置 检查您的 ATF 版本配置（ plat/nxp/soc-ls1046a/.../platform_def.h ）对于 BL31_BASE 和 BL31_SIZE 。对于采用 FRWY 电路板支持包。的 LSDK/lf-6.x，典型的安装位置如下： BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB) BL31_SIZE = max 2 MiB     您可以通过检查 U-启动 输出或 ATF 版本日志中的 BL31: v2.x... Entry point address = ... 。 步骤 2：将预留内存节点添加到您的 DTS 中 在您的板级 DTS 文件（基于 fsl-ls1046a-frwy-sdk.dts ）中添加： / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* Reserve BL31 runtime region — adjust addresses to match your ATF build */ bl31_reserved: bl31@8ff600000 { reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */ no-map; }; }; }; dts   调整 0x8ff600000 和大小 0x200000 ，以匹配 ATF 版本中的实际 BL31 加载地址。 步骤 3：重建并使用全部内存进行测试 添加预留信息后，重新构建 DTB 并启动，无需 mem= 变通方法。内核将跳过该区域，BL31 保持不变，PSCI 将正常工作。   此致 Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from 你好， 我尝试了建议的解决方案，但很遗憾，它并没有解决问题。 首先，我验证了 TF-A (ATF) 版本中的 BL31 地址： - BL31_BASE = 0xFBE00000 - BL31_SIZE = 0x200000 (2 MiB) 接下来，我在设备树中添加了一个“保留内存”节点，以保留 BL31 运行时区域，并重新构建了 DTB。 之后，我再次启动系统，但没有使用“mem=1982M”启动参数。然而，系统仍然卡在同一个地方。

Schematics of MPC5775B BMS & VCU Reference Design Unit Hey, I wanted to look into which pins in the MPC5775B MCU is connected to the digital and analog outputs available via the BMS & VCU reference design. But could not find schematics on that. Can I get it or possibly the link to it ? I am trying to figure out which of the Inputs pins exposed through the reference unit can do interrupt handling. Re: Schematics of MPC5775B BMS & VCU Reference Design Unit Hello, Schematic is available at our web page: https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png On page 12 are analog inputs and on page 14 digital inputs. Best regards, Peter

MPC5775B 电池管理系统 & 整车控制器VCU 参考设计单元原理图 嘿， 我想了解 MPC5775B MCU 中的哪些引脚连接到电池管理系统和整车控制器VCU参考设计中提供的数字和模拟输出。但找不到相关的原理图。我可以得到它或者它的链接吗？我正在尝试弄清楚参考单元暴露出的哪些输入引脚可以进行中断处理。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit 你好， 原理图可在我们的网页上找到： https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png 第 12 页是模拟输入，第 14 页是数字输入。 顺祝商祺！ Peter

MX8-DSI-OLED1 Display part No and sequence. Hi Team, We are planning to use MX8-DSI-OLED1 accessory in our custom board as well. Could you please share the display part no and if there is any power sequence to be maintained. Re: MX8-DSI-OLED1 Display part No and sequence. Hi Team, Any updates on this? Re: MX8-DSI-OLED1 Display part No and sequence. Hello, Could you share what kind of information you are looking for? The display for the MX8-DSI-OLED1A (raydium rm67199) is a MIPI-DSI OLED display with touch support. Following are some key features: • 5.49" FHD (1080p@60fps) AMOLED display • 16.7 M (RGB*8bits) display color • Touch screen • 4-lane MIPI-DSI interface for display • I2C interface for touch and control Also, note that for this part there is not much information we can share. Best regards/Saludos, Aldo. Re: MX8-DSI-OLED1 Display part No and sequence. Hi @AldoG I would like to understand if there is any power up sequence to be followed for these rails. VDD_1V8 VEXT_3V3 VDD_5V

BMSおよびVCUリファレンスデザインユニットMPC5775B回路図 こんにちは、 MPC5775B MCUのどのピンがBMSやVCUのリファレンス・デザインで利用可能なデジタルおよびアナログ出力にコネクテッドされているかを調べたかったのです。しかし、その設計図は見つかりませんでした。入手できますか?もしくはリンクも教えてもらえますか?参照ユニットを通して露出している入力ピンのうち、どのピンが割り込み処理に使えるのかを調べようとしています。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit こんにちは、 回路図は当社のウェブページでご覧いただけます。 https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png 12ページにはアナログ入力、14ページにはデジタル入力があります。 よろしくお願いいたします。 ピーター

LX160A上のPCIデバイスのITSデバイスID こんにちは、 私はLX2160Aチップを搭載したHoneycomb LX2ボードを使用しています。ubootとLinuxのコードを調べたところ、uBootでは各PCI BDF(ブリッジやデバイス)にストリームIDが割り当てられており、それがdtbのmsiマップに入力されていることがわかりました。 LinuxはこのストリームIDを各PCI BDFのITSデバイスIDとして使っていると思いますが、Linuxコードやドライバ/irqchip/irq-gic-v3-its-pci-msi.c、ITS固有のデバイスIDはRIDのみのようです。 私が作業しているシステムでは、BDFのITSデバイスIDは、上流のPCI-PCIブリッジのストリームIDです。また、2ポートNICカードの各ポートのITSデバイスIDは同じです。Linuxでも同じようなケースですか? Linux上でPCIデバイスのITSデバイスIDがどのように計算されているのか、またNICカードの2つのポートが同じITSデバイスIDを共有するべきかどうか、誰か教えてもらえますか?もしそうでなければ、システムに何が欠けていたのでしょうか? Re: ITS Device ID for PCI devices on LX2160A この議論は参考になった。LX2160A上のITSデバイスIDを扱うのは、特にPCI割り込みのルーティングや設定の詳細を扱う際に難しいことがあります。同様の技術的なトピックを調べているうちに、 Citrus Court Resources という、整理された公的記録情報を提供するというサイトにも出会いました。この情報を共有していただきありがとうございます。同じハードウェアに取り組んでいる他の方々からの実践的な知見は、常に参考になります。 Re: ITS Device ID for PCI devices on LX2160A LX2160AにおけるPCIデバイスのITSデバイスIDに関する議論は、特に割り込み変換や組み込みシステムに携わる人にとって非常に有益です。関連する技術ドキュメントを調べる中で、 Bibb Court Clerk は組織化された公共情報にアクセスするための有用なリソースであることも感じました。これらの洞察を共有してくださりありがとうございます。複雑なテーマをより深く理解し、深く探求するのがとても簡単になりました。 Re: ITS Device ID for PCI devices on LX2160A 新しい問題については新しいThreadでどうぞ。 よろしくお願いします。 Re: ITS Device ID for PCI devices on LX2160A もっと作業に関わる問題があり、助けていただければと思っています。 デバッグの結果から判断すると、PCIデバイスではなくPCI-to-PCIブリッジデバイスがメッセージシグナル割り込みを送信しているため、誤ったITSデバイスIDが表示されている可能性があるようです。PCI設定レジスタにこの現象を引き起こす設定がある可能性はありますか? ありがとうございます Re: ITS Device ID for PCI devices on LX2160A 以下の更新情報をご参照ください。 私の理解では以下のとおりです。 1. PCIeデバイスは、要求者ID（RID）を含む割り込みメッセージを生成します。 2. ITSはこのメッセージを受信し、RIDを使用して対応するStreamIDを検索します。 3. ITSはこの情報を割り込みコントローラ向けの適切な割り込みメッセージに変換します。 SO、より具体的には、 BDFで構成されるRIDは、ITSによって割り込みの管理と翻訳に使用されます StreamIDはRIDと同じBDFから派生し、SMMUがDMA操作の管理と翻訳に使用します。 Re: ITS Device ID for PCI devices on LX2160A AEチームからの以下のアップデートをご参照ください。 これらの質問は主にLinuxに関するものなので、お客様はドキュメント/PCI/msi-howto.rstでPCI-PCIブリッジの背後にあるMSI割り当ての情報を見つけることができます。 Re: ITS Device ID for PCI devices on LX2160A 調べていただきありがとうございます。ITSデバイスIDと、BDFにマッピングされるLUTエントリにプログラムされているストリームIDとの間には、何らかの関係性がありますか？ Re: ITS Device ID for PCI devices on LX2160A AEチームと話し合っています。 Re: ITS Device ID for PCI devices on LX2160A LX2160A上のITSのデバイスID処理は確かに難しいことがあります。特に異なるPCI構成を扱う場合です。同様のテーマを調べている中で、 Watauga Property Assessment を通じて有用な不動産データにも出会いました。とても整理されていました。この情報を共有していただきありがとうございます。複雑なハードウェアの動作に関する実践的な議論は、常に参考になります。

S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi NXP Team, I am working on an S32K311 project using the following environment: MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 Issue Initially, the project was building successfully. As the project progressed, I enabled and configured several RTD drivers, including ADC, eMIOS, LCU, ICU, PIT, PORT, LPUART, LPSPI, TRGMUX, MCL, and other required peripherals for my application. After integrating these drivers, the project now fails during the linking stage with the following errors: .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status Memory Layout The default linker script contains the following SRAM regions: int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 The linker reports that the .non_cacheable_bss section exceeds the allocated int_sram_no_cacheable region by approximately 440 bytes. Questions Is this memory usage expected when multiple RTD drivers are enabled on the S32K311? Is there a recommended method to reduce the size of .non_cacheable_bss? Is it recommended to modify the linker script and increase the int_sram_no_cacheable region? If so, what is the recommended memory layout for the S32K311? Are there any RTD configuration options that can reduce the memory allocated to non-cacheable sections? Has anyone encountered a similar issue when integrating multiple RTD peripherals? Any guidance or recommended solution would be greatly appreciated. Thank you. Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi @Esakki  You may find the following discussion threads helpful, as they discuss similar issues and provide some useful troubleshooting suggestions. int_sram_no_cacheable issue S32K312's SRAM is overflow Additionally, there is an S32K3 application note that explains the linker file and startup code in more detail, including how memory regions can be modified and customized. AN14893: S32K3xx Linker File and Startup Code This last thread includes some suggestions related to code optimization techniques. S32K3xx How to optimization APP code for get more high performance BR, VaneB

S32K344 RTD 3.0.0:空の.slewRateCtrlSelLPSPI4ピン用に生成されました - ビルドが失敗します こんにちは、 私は、NXP RD33772C14EVMリファレンス・デザインに従ってSPI配線をしたS32K344(172ピンMQFP)カスタムボード上のバッテリー・マネジメントアプリケーションを紹介しています。私はS32 Design Studio 3.5とRTD 3.0.0を使っています(プラットフォーム、ポート、SPIモジュールはすべてSWバージョン3.0.0を報告しています)および FS26 SBC CDD 2.0.0 (Sbc_fs26)。私の出発点は、S32K344 用の Sbc_fs26_example_HLD サンプルです。 私のシステムではLPSPI0はFUTUREの2チャネルデイジーチェーン用に予約されており、他のSPIインスタンスはすでに使用中なので、FS26のSBCはLPSPI4上で動作しなければなりません。RD33772C14EVM回路図に従い、4つのLPSPI4信号をリファレンス・デザインで使われている同じパッドにルーティングしました:lpspi4_pcs0はPTB8、lpspi4_soutはPTB9、lpspi4_sckはPTB10、lpspi4_sinはPTB11に。ペリフェラル側ではSPIの物理ユニットマッピングをLPSPI_4に設定し、SpiHwUnitをCSIB0に残し、MCUコンポーネントのLPSPI_4ペリフェラルクロックゲートを有効にしました。 「Update Code」を実行してビルドすると、生成されたファイルgenerate/src/Siul2_Port_Ip_VS_0_PBcfg.cでエラーが発生してコンパイラが停止します。ジェネレーターは右辺のない代入式を生成しました。 ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: エラー: ',' トークンの前に式が必要です 118 | .slewRateCtrlSel= 、 同じ空の.slewRateCtrlSel= は、158行目、198行目、238行目に現れます。これは、4つのLPSPI4ピンそれぞれに対応しています。手動でその4行にPORT_SLEW_RATE_NOT_AVAILABLEを入力すると、ビルドは少し進みますが、.inputMuxRegで同じように失敗します。= { (空の初期化子、「ISO C では空の初期化子の括弧は禁止されています」)。つまり、これら4つのパッドのピン構成構造は、有効なCではない空のフィールドで生成されます。 PTB8–PTB11のピンツール「ルーティング詳細」を見ると、スリューレートコントロール列(および入力フィルター列)に該当なしが表示され、スリューレートセルを選択するとツールチップが表示されます:「選択したピンはこの機能の設定をサポートしていません。スルーレート制御を選択します。SO、これらのパッドにはスルーレート制御ハードウェアが搭載されていないのです。私の理解では、そのCASEジェネレーターは他のサポートされていないパッド機能に対して*_NOT_AVAILABLE値を使うのと同様に、PORT_SLEW_RATE_NOT_AVAILABLEを放出するはずです(その値はこのデバイスのSiul2_Port_Ip_PortSlewRateControl枚数に存在します)。しかし実際には何も発信せず、ビルドが壊れます。 これがピンの選択の誤りではなくツールやドライバの問題だと確信する理由は、NXP自身のLVBMS_RD_Bring_up_ExampleがFS26 SBC用にまったく同じ4つのLPSPI4パッド(PTB8/PTB9/PTB10/PTB11)を使っていて、きれいに組み立てられることです。その例と私のプロジェクトで唯一の違いはRTDバージョンです。LVBMSの例はRTD 2.0.0(プラットフォーム/Port/Spi SW 2.0.0)に基づいて構築されているのに対し、私のプロジェクトはRTD 3.0.0を使っています。基板のピン配置は同じで、ピンも4本とも同じ、ピンの電気的特性も同一です（方向のみが両者で設定されています）。SO、スルーレート対応しないパッドのSiul2_Port_Ipコード生成がRTD 2.0.0とRTD 3.0.0の間で逆行したように見えます。 私の質問： これはRTD 3.0.0の既知の問題ですか？修正版／パッチ適用済みのRTDリリースはありますか？ RTD 3.0.0環境下で、PTB8～PTB11（RD33772C14EVMピン配置）においてLPSPI4を正しく、かつサポートされている方法で構成するにはどうすればよいでしょうか？つまり、ピンツールが有効なコードを生成するようにするためです。つまり、slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLEと有効なinputMuxRegを生成し、空欄ではなく? 設定レベルでの修正がない場合、生成された Siul2_Port_Ip_VS_0_PBcfg.c を手動で編集することが唯一の回避策でしょうか (「コードの更新」のたびに上書きされます)、それともプロジェクトを Port/RTD 2.0.0 に移行することが推奨される方法でしょうか？ もし役に立つなら、完全なビルドログ、ピンの「ルーティング詳細」スクリーンショット(ツールチップ付き)、そして2つのプロジェクトのモジュールバージョンを並べて添付CAN。 ありがとう、 ソン・ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、VaneBさん。 どうもありがとうございました。まさにそれが問題だったのです。ピンツールはLPSPI4(PTB8–PTB11)に更新されていましたが、 ポート コンポーネントのポートピンエントリは元のLPSPI0パッドを指していたため、PortPin Pcr(Mscr)の値は古くなっていました。 ポート設定内の4つのPortPin Pcr値を、新しいピン割り当てに合わせて更新しました。 PCS0 → PTB8 (PCR 40) SOUT → PTB9 (PCR 41) SCK → PTB10 (PCR 42) SIN → PTB11 (PCR 43) Update Codeを実行して再構築した後、空の .slewRateCtrlSel/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c のエラーは解消され、プロジェクトは正常にビルドされます。 迅速かつ的確なご回答、本当にありがとうございました。おかげで大変時間を節約できました。これを解決策としてマークします。 よろしくお願いします、 ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、 @hyunsiksong この問題は、RTD自体にも、S32DS構成ツールによって生成されたコードにも関係ありません。むしろ、それは設定に関係している。 ペリフェラルツール内のポートドライバ構成では、PortPin Mscrパラメータに割り当てられた値は元のプロジェクト構成に対応しています。例えば、プロジェクトは以前、PTB1をLPSPI0_PCS0として使用するように構成されており、これはPortPin Mscr = 33に対応します。 ただし、更新された構成ではLPSPI4が使用され、PCS0はピン8に再割り当てされています。したがって、対応するPortPin Mscrの値は33ではなく40になります。 すべてのピンについてPortPin Mscrを確認し、現在のピン割り当てと一致していることを確認してください。これらの値を新しい構成に合わせて更新することで、問題は解決するはずです。 BR、VaneB