RT685: SDK 25.12 没有 HASHCRYPT 加速功能 你好 我们最近更新到了 SDK 25.12，发现我们的 TLS 解密率降低了一半。 mbedTLS v3.x 不再使用fsl_hashcrypt硬件加速功能。 下面是使用以前的 SDK 25.09 调用mbedtls_ssl_read 的调用堆栈。可以看到，最终使用了HASHCRYPT_AES_EncryptEcb。 hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> 下面是定义了MBEDTLS_USE_PSA_CRYPTO的 SDK 25.12 的调用堆栈。在该版本中，mbedtls_internal_aes_encrypt全部是 C 代码，没有硬件加速。 mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 下面是 SDK 25.12 的调用堆栈，其中没有mbedtls_use_psa_crypto定义的调用堆栈。在这个版本中， mbdtls_internal_aes_encrypt全部是 C 代码，没有硬件加速，也不涉及 PSA。 mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 是否有计划在 mbedTLS 中恢复 RT685 HASHCRYPT 硬件加速？某些 PSA Crypto 驱动程序似乎未被执行。 谢谢！ Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨，埃德温、 我在 EVK 上重现了这个问题。我修改了两个样本，在其中添加了一个迭代 200 次的循环 mbedtls_gcm_self_test 并使用 RTC 时钟为整个执行过程计时。 evkmimxrt685_mbedtls_selftest_cm33 执行测试的时间为 1087ms 使用此调用栈： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 执行测试的时间为 8990ms 使用此调用栈： mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 来自 SDK 25.12 的 mbedtls_psa_accel_key_type_aes 定义的测试执行时间为 8744ms 使用此 callstack： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 对示例的修改要点如下： BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... 其中test_rtc_get_msecs使用亚秒精度返回当前 RTC 时间。 正如您所看到的，使用新的 SDK 加密 GCM/AES 的速度慢了约 8 倍。 如果您需要，我可以附上修改后的示例。 问候， Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨，埃德温， 我们已经阅读了迁移指南。不过，我们看不出不带 PSA 的 mbedTLS 2.x 或 mbedTLS 3.x 如何在此版本的 SDK 中进行硬件加速。由于 aes_alt.c 已被删除，而 HASHCRYPT 功能仅由 PSA 驱动程序支持。 我们的应用程序在使用 SDK 25.12 时一切正常，我们当然希望在连接时使用 TLS 1.3，但现在的情况会让我们的性能大打折扣。 我们将继续调查此事。我将修改其中一个示例，看看能否重现性能损失。 问候， Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 感谢您耐心解答这个问题。我刚刚收到内部团队的回复，请参见下文。 从调用堆栈中我可以看到，您使用的是传统的 mbedtls_xxx 加密 API。事实上，它并没有加速。MbedTLS3.x推出了新的加密应用程序接口，它就是 PSA。mbedtls/docs/psa-transition.md at v3.6.5 - Mbed-TLS/mbedtls - GitHub而且它还被加速了。 MbedTLS4.x 进一步删除了传统加密 API。 我检查了 RT600 SDK 中的 psa_crypto_examples，通过定义PSA_CRYPTO_DRIVER_HASHCRYPT，HASHCRYPT硬件加速在默认情况下是启用的，这使得加密驱动程序封装器可以将加密计算卸载到硬件上。另一方面，MbedTLS3.x+ 更为复杂，也更符合 PSA API 规范，因此可能会出现某些用例性能较低的情况。对于 TLS，我认为非对称加密技术（CASPER 硬件 IP）会成为性能瓶颈，因为该 IP 只能支持少量加速，而且与 PSA API 不兼容，后者希望硬件 IP 实现整个算法。我们已尽全力至少加速了部分 ECC 操作（签名、验证），但其他操作（如 ECDHE 密钥交换过程中的密钥生成）可能会更糟。 现在，如果您能使用 PSA API 进行性能测量，并确认 PSA_CRYPTO_DRIVER_HASHCRYPT 已定义且调用栈使用了它，那将是一件好事。仅供参考：Hashcrypt本身没有提供AES-GCM加速，因此最好对AES-密码块链接(CBC)或AES-CTR进行基准测试，以查看硬件IP的实际收益。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 从mbedTLS 2.x（不含 PSA）迁移到 mbedTLS 3.x（含 PSA）必然会导致性能下降： " PSA 驱动程序接口仅部分实现。因此，编写驱动程序的交付内容以及将驱动程序与 Mbed TLS 集成的方法将根据所加速的操作而有所不同。"(https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) 目前，我所能推荐的最好方法是遵循如何正确从 2.x 迁移到 3.x 的指南：从 Mbed TLS 2.x 迁移到 Mbed TLS 3.0 - MCUXpresso SDK 文档 以及正确过渡到 PSA API 的指南：过渡到 PSA API - MCUXpresso SDK 文档 不便之处，敬请原谅。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 我在 mbedTLS 配置文件中定义了 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES，现在它正在调用 ASHCRY PT，但是我们的 mbedtls_ssl_read 读取速度现在更慢了。我想知道是否还有其他缺失的定义，或者PSA层增加了额外的开销。   通过 TLS 插口从 WiFi 下载 4KB 数据包的速率： SDK 25.09：205KB/秒（没有 PSA 和 ksdk 端口文件的 mbedTLS 2.x） SDK 25.12：138KB/秒（不带 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES） SDK 25.12：125KB/秒（使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 时） 下面是使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 的新调用栈： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 更新 SDK 后，您是否做了任何更改？您在使用 SDK 示例代码时也看到了这种行为吗？你使用的是独立组网 \\(SA\\) IDE 还是 VS Code 扩展？ BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@EdwinHz、 我们使用的是 MCUXpresso 集成开发环境。 更新 SDK 后无额外更改： 当我们更新 SDK 时，我们会重新运行 " SDK 管理 "-> " 刷新 SDK 元器件 " 来获取新的和更新的文件。 然后，我们比较 .cproject配置为已启用类似功能的样本之一（例如evkmimxrt685_wifi_wpa_supplicant_cm33) psa_crypto_driver_casper=1 psa_crypto_driver_hashcrypt=1 config_wpa_supp_crypto_mbedtls_psa=1 等等 我们使用默认的mcux_mbedtls_config.h作为主要的 mbedTLS 配置头文件，并使用与evkmimxrt685_wifi_wpa_supplicant_cm33示例中的wpa_supp_mbedtls_config .h几乎相同的用户配置文件。 我将尝试使用 mbedtls3x_examples，看看它们的表现如何。也许我们漏掉了一些定义。 我在浏览代码时注意到，也许需要定义MBEDTLS_BLOCK_CIPHER_C，以便加速 gcm 操作。 看起来头文件mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h对此负有责任，但由于某些原因最终没有定义该宏。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration 为了他人的利益... 看来 来自 mbedTLS 3.x 的 mbedtls_xor 一次循环遍历 4 字节的数据，并调用 mbed tls_get_unaligned_uint32 和 mbedtls_put_unalign ed_uint32， 它们都使用 memcp y 来处理单个 uint32。 我认识到 MbedTLS 的作者正试图通过一次计算 异或 4 字节块（使用余数循环）来提高性能，但是对 memcpy 的完整调用实际上使代码变慢。 在对反汇编进行一些调查后，我发现我们的项目在编译时使用了 -fno-builtin，导致编译器无法内联小的 memcpys。 移除该选项后，HASHCRYPT 硬件不用于 AES-GCM 操作所造成的性能损失基本得以恢复。因此，我发布的示例执行时间从 8600 毫秒缩短到 2100 毫秒。还没有达到 mbedTLS 2.x + ksdk alt（1087ms）的水平。但修复后的性能已经足够好了。 -阿米尔卡

带有 S32K5xx RTD 的时钟 IP 发出的 S32DS 警告 0.8.0 使用 S32K5xx RTD 时 0.8.0编译时，我收到了来自时钟 IP 模块的许多警告。 有办法纠正它们吗？ 这些警告是否可以忽略？ 有计划把它们修好吗？ Re: S32DS Warnings from Clock IP with S32K5xx RTD 0.8.0 你好@DirkEtzler、 谢谢您的提问。如前所述，S32K5 系列目前是 NPI（新产品推出）设备。因此，所有支持请求必须直接通过指定的恩智浦 FAE 处理。 或者，请通过以下网址创建支持票据： https://support.nxp.com/s/?language=en_US 系统会自动将您的请求转给相应的 FAE 团队，以便提供进一步帮助。 感谢您的理解。 顺祝商祺！ 帕维尔

RT1021 输入最大电流 您好，请问 GPIO 输入可以承受多大的电流？我使用的是 GPIO_AD_B1_02，通过该引脚的电流为 8mA。 在损坏引脚之前，输入端可承受的最大电流是多少？ 如果我没理解错的话，该引脚是默认值，默认配置为带 100k 下拉电阻的输入引脚。 谢谢 Re: RT1021 input max current 你好，@jtrujillo、 一般来说，任何 RT1xxx GPIO 引脚的最大电流都应限制在 25mA，无论它是输出电流还是下沉电流。这是防止可靠性问题（如电迁移造成的潜在损坏）的技术安全极限，如果引脚需要，可以持续很长时间。 BR, Edwin.

IMX8M PLUS LPDDR4 2G 兼容性 我们尝试使用 ISSI IS43LQ32512A-046BLI 2GB RAM。校准后，在配置为 2000MHz 的memcpy SSN armv8_x32 测试中，RAM 出现故障。 如果我将内存配置为 1500MHz，它就能通过所有测试。 有人使用过这种 LPDDR4 内存吗？它与 IMX8M PLUS 兼容吗？ i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: IMX8M PLUS LPDDR4 2G compatibility 你好@TMpieye 您是否使用 DDR 配置工具运行校准？如果是，.请共享您的配置页面和故障日志文件。 B.R Re: IMX8M PLUS LPDDR4 2G compatibility IS43LQ32512A-046BLI（ISSI 2GB LPDDR4X 同步动态随机存取存储器(SDRAM)）通常与恩智浦 i.MX 8M Plus 处理器兼容，前提是它符合 LPDDR4/LPDDR4X 内存的 JEDEC 标准。但是，你的memcpy SSN armv8_x32测试在2000MHz（但通过了 1500MHz）时失败的问题并不少见，可能源于配置、板设计或校准方面的挑战，而不是根本的不兼容性。 兼容性确认 i.MX 8M Plus 支持高达 4266 MT/s（2133MHz 时钟）的 LPDDR4/LPDDR4X 内存，IS43LQ32512A-046BLI 工作频率高达 2133MHz（4266 MT/s 数据速率），与恩智浦的规格一致。 恩智浦的社区论坛证实，类似的 ISSI LPDDR4X 部件（例如，IS46LQ32512A-046BLA2，这是您的型号的汽车变体）与 i.MX 8M Plus 兼容，前提是它们遵循 JEDEC 规范。只要配置得当，用户都能顺利实施。 导致 2000MHz 频率测试失败的潜在原因 根据恩智浦和嵌入式论坛上的类似报告： 定时/配置不匹配：i.MX 8M Plus DDR 控制器需要 RAM 的 SPD/数据表提供精确的时序参数（如 CAS 延迟、tRCD、tRP）。在 2000MHz 时，您的校准可能无法完全优化 ISSI 部件的规格（例如，在更高的速度下，CL=32，RL=14）。将频率降至 1500MHz 可降低压力和通过率，但这表明调谐未达到最佳状态。 板设计问题：信号完整性问题，如走线长度不匹配、阻抗错误或功率解耦不足，可能会导致较高速度失效。使用示波器检查 DQ/DQS 线路上是否有反射或噪音。 校准限制：i.MX 8M Plus 使用恩智浦的 DDR 工具进行校准。如果您的脚本或设置基于 Micron/Samsung 参考（在 EVK 中很常见），则它们可能与 ISSI 的特征不符。使用 ISSI 专用参数重新运行校准。 功率/温度：在 2000MHz 时，较高的电流消耗可能会导致电压下降或过热，从而使 memcpy 测试（强调顺序读/写）失败。 有人使用过这种内存吗？ 是的，有记录的实施方案： 在恩智浦社区话题中，用户已将类似的ISSI LPDDR4X（例如 IS46LQ 系列）集成到用于工业应用的定制i.MX 8M Plus板上，在微调后实现了高达2133MHz的稳定运行。 嵌入式Linux/电路板支持包开发人员报告说，在基于Yocto的版本中成功使用了ISSI部件，但通常使用自定义的DDR初始化脚本来处理512M x 32的组织（16Gbit密度）。 解决问题的建议 验证数据表对齐： 下载ISSI数据表（IS43/46LQ32512A系列），将时序参数与恩智浦的i.MX 8M Plus RM（参考手册，第13.5节DDR控制器）进行比较。 内存的主要规格：2133MHz 最大时钟、LVSTL 接口、1G x 16 组织（双通道 x32 总计）。 重新运行校准： 使用恩智浦的DDR 测试工具或SCFW DDR 配置工具进行 ISSI 特定压力测试。 从 1600MHz 开始，逐渐增加到 2000MHz，同时监测眼图。 如果使用 U-启动/Linux，请使用正确的时间更新设备树 (.dtb)（例如 mx8mp-ddrc-devfreq.dtsi）。 董事会级别的检查： 确保 VDDQ = 1.1V、VDD2 = 0.6V，采用干净的解耦（电容靠近引脚）。 使用信号完整性模拟器（如 HyperLynx）验证迹线。 用更低的温度或更好的冷却方式进行测试，以排除热节流。 如果仍然失败 通过恩智浦的社区或票务系统联系恩智浦支持人员——提供您的校准日志和电路板原理图。 考虑改用美光 MT53E512M32D2NP（恩智浦 EVK 默认值）等经过验证的内存进行比较。 总的来说，内存是兼容的，但你的 2000MHz 故障很可能是设置问题。如果你分享更多细节（例如校准日志或电路板原理图片段），我可以帮助进一步排除故障！ 我建议通过消息应用程序联系 +8526583 (7594)；从他那里获得 EOL 文件，然后提出建议。他能帮助你 Re: IMX8M PLUS LPDDR4 2G compatibility 感谢你的支持 在附件中，我向您发送了配置文件 .xls和测试日志。 Re: IMX8M PLUS LPDDR4 2G compatibility 在二手板上，我们成功地在 2000MHz 上运行了 3GB（MT53E768M32D2ZW-046 WTC）和 4GB（MT53E1G32D2FW-046 AAT: B）美光 LPDDR4。 Re: IMX8M PLUS LPDDR4 2G compatibility 你好@pengyong_zhang、 使用配置工具 V 13.1 时结果相同。也许我们对 IS43LQ32512A-046BLI 的配置有误？能否提供正确的配置（*.ds 文件）？我们的硬件设计是关于 LPDDR4 接口的评估板的 1:1 副本。 此致 托比亚斯 Re: IMX8M PLUS LPDDR4 2G compatibility 你好@TMpieye 请使用以下链接下载我们的 DDR 配置工具，然后使用 configure 2GB 动态随机存取存储器(DRAM) 运行 ddr 测试。 https://www.nxp.com/design/design-center/development-boards-and-designs/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX B.R Re: IMX8M PLUS LPDDR4 2G compatibility 你好@TMpieye 请使用以下设置运行 DDR 测试。 B.R Re: IMX8M PLUS LPDDR4 2G compatibility 感谢您的配置示例。我已经用这个内存试过了，还是出错。 Re: IMX8M PLUS LPDDR4 2G compatibility 你好@TMpieye 真奇怪。请分享您的 DDR 配置工具 v25.12 故障日志 B.R Re: IMX8M PLUS LPDDR4 2G compatibility 你好@TMpieye 您使用我们的 DDR 配置工具进行压力测试了吗？从你的日志文件来看，配置工具的输出结果似乎与之不符。同时使用最新的工具版本 v25.12。 B.R Re: IMX8M PLUS LPDDR4 2G compatibility 你好@pengyong_zhang、 这是 Stresstest 的日志。我们的 4GB ISSI IS43LQ32K01S2A-046BLI 也遇到了同样的问题。 Re: IMX8M PLUS LPDDR4 2G compatibility hi@pengyong_zhang 我们使用 Mscale DDR 工具 3.31 进行stresstest。我将使用其他配置工具进行配置 Re: IMX8M PLUS LPDDR4 2G compatibility 你好@pengyong_zhang、 我在配置工具中运行测试，结果通过了。因此，这似乎是 MSCALER 工具的问题。非常感谢你们的大力支持！

CSEc エラー S32K144 で CSEc を使用する場合、BOOT_DEFINE 中に KEY_INVAILD エラーが返されるのはいつですか? 答えが得られることを祈り、毎日幸せになることを祈っています！ Re: CSEc Error こんにちは@xiaozhi BOOT_DEFINE 関数を呼び出すときにこのようなエラーが発生する理由がCANわかりません。この関数は、BOOT_MAC_KEY がまだプロビジョニングされていない場合でも呼び出すことができるため、キーは必要ありません。 よろしくお願いいたします。 ルーカス

CSEc Error 我在使用S32K144的CSEc，在BOOT_DEFINE时，何时会返回KEY_INVAILD错误呢？ 希望得到解答，祝每天开心! Re: CSEc Error 你好@小智 我看不出在调用 BOOT_DEFINE 函数时出现这种错误的原因。即使尚未配置 BOOT_MAC_KEY，也可以调用此函数，因此它不需要密钥。 此致， Lukas

需要帮助：在 RT1189 上从 FlexSPI2 QSPI 闪存启动 我们正在尝试在自定义硬件上启动用户应用程序。这种定制硬件仅有 FlexSPI2 QSPI 闪存，使用端口 A 上的主引脚组进行连接。闪存设备是美光 MT25QU256ABA。RT1189 (RT1189CVM8C) 上的启动 ROM 无法正确配置内存，启动失败。但是，恩智浦安全配置工具可以成功读取和写入数据。 闪存配置块 (FCB) 是使用安全配置工具创建的： XIP 启动标头在映像编译本身中被禁用。取而代之的是，安全配置工具被配置为使用从简化用户界面生成的 FCB，使用上面屏幕截图中显示的确切设置。虽然上述截图中没有显示，但"测试连接" 已通过。 此外，当安全配置工具（此后称为 " SPT "）提示配置外部存储器时，处理器和该工具可以成功读取 FlexSPI2 内存。如下图所示。 当用户打开闪存编程器工具时，在弹出窗口中单击 " 是 " 和/或单击 " 配置外部存储器 " 按钮将导致 SPT 使用上面显示的闪存配置模块设置来初始化 FlexSPI2 闪存以进行编程。 以下屏幕截图是在刷新完整应用程序映像（偏移量 0x400 处的 FCB，偏移量 0x1000 处的用户应用程序）后捕获的： 这让我相信闪存配置块是正确的。 RT1180 上的以下熔丝位被烧毁。所有其他熔丝位均为默认值： BOOT_CFG0 [6] (BT_FUSE_SEL)-> 1b，用于启用从熔丝启动 BOOT_CFG2[7] (FLEXSPI_INSTANCE) -> 1b，用于选择 FlexSPI2（默认为 FlexSPI1）。 将 BOOT_MODE 引脚设置为 000b（用于 " 从内部熔丝启动）会导致 RT1189 没有任何活动。它需要启动到"无限循环" 模式，然后再返回到串行下载器模式，才能再次与它通信。 将 BOOT_MODE 引脚设置为 100b（用于从 FlexSPI " 启动 "）会导致 RT1189 保持 " 卡住 "，但可以被 jLink 调试探测器停止。 尝试使用 BOOT_MODE 100b 从 FlexSPI 启动后暂停时，检查 FlexSPI2 内存区域显示全部为零： 值得注意的是，"all zeroes" 与 RT1189 的 FlexSPI2 存储器区域的默认状态不一致。以下屏幕截图是在未配置外部存储器的情况下启动到串行下载器模式后捕获的： 最后一件事：用户应用程序中 MCUXpresso 示例的链接器脚本已更改为从 FlexSPI2 启动： 注意：截图中的标题显示"0x14000000" ，但"0x04000000" 才是代码中使用的真实值。这是一个错字 这一点在 SPT 中有所体现： 综上所述，我目前的理解是这样的： FCB 必须正确，否则 SPT 将无法与连接到 FlexSPI2 Bank A 的外部闪存交互。 ROM 本身在启动时必须尝试以某种不同于 SPT 的方式初始化该外部存储器。如果没有 RT1189 启动 ROM 的源代码，如果不对其进行逆向工程，我就无法进一步调试，而作为恩智浦的客户，我们无意这样做。 我的问题 是我们的配置出了什么问题导致了这种行为？ 有没有办法调试启动 ROM 以了解为什么它无法初始化闪存？ 谢谢 Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 @Sam_Gao、 感谢您的回复。 正如原帖所述： 启动实例的选择正是你在评论和 AN14589 中指定的内容：BOOT_CFG2 [7] 是为了选择 FlexSPI2 而烧掉的。 应用程序代码被链接到指定的 FlexSPI2 内存映射区 (0x04000000)（m_start_flash 更改为 0x04000000）。在你的回复中，你以 " 0x40000000 " 的形式给出，这不正确，如上面提到的应用笔记和 RT1189 参考手册中所述： FCB 出现在预期偏移位置。我们甚至把闪存芯片换成了可以正常工作的 MIMXRT1180EVK，但仍然无法正常工作。 使用逻辑分析器，我们得以确定闪存配置模块很可能由启动 ROM 读取——不久之后，时钟速度从 30 MHz 变为 125 MHz，读取数据通过 SPI 数据线传输。 有没有什么机制可以进一步调试启动ROM或启动顺序？ Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 经过数周的努力，我能够通过链接到 ITCM (0xFFE00000) 而不是 XIP 来启动处理器。但这个主题仍然相关 -- 为什么 FlexSPI2 上的 XIP 无法正常工作？ Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 您好， 在像 RT1189 这样的设备上，它似乎无法从 FlexSPI2 QSPI 闪存启动，这通常源于一些常见的配置区域。以下是潜在问题的详细介绍，以及如何调试启动 ROM 过程以确定根本原因。 参考 AN14589：https://www.nxp.com/docs/en/application-note/AN14589.pdf 1。检查启动实例选择： 需要明确告知启动 ROM 使用 FlexSPI2 而不是默认的 FlexSPI1。 这由 BOOT_CFG2[7] 熔丝或引脚控制。 你需要确保 BOOT_CFG2[7] 设置为 1 才能选择 FlexSPI2 作为启动实例。 仍需要正确设置主启动模式引脚 ( BOOT_MODE[2:0]) 才能从串行 或非 （例如，'100'）启动 2.应用程序链接器地址：为 FlexSPI2 制作可启动映像时，必须链接应用程序代码，以便从 FlexSPI2 内存映像运行。FlexSPI2 的起始地址为 0x40000000 。你需要修改项目的链接器文件，将闪存起始地址（ m_flash_start ）设置为 0x40000000 。参考：AN14589 第7页。 3.FCB：启动 ROM 需要在闪存的开头（通常在偏移量 0x400 处）有一个有效的 512 字节配置块，才能正确初始化外部 QSPI 设备。如果此模块缺失、损坏或与您使用的特定闪存芯片不匹配，则启动 ROM 将无法与闪存通信。更多详情，请参阅https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#preparing-source-image-for-rt118x-devices Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 看来没有问题。 有关启动 ROM 和启动顺序的信息，请参阅 https://www.nxp.com/docs/en/application-note/AN14589.pdf 了解更多详情。 当设备"卡住时"，不要将其RESET。例如，使用 JLink/debugger 直接连接到运行中的内核，检查以下寄存器状态： 程序计数器 (PC)： 如果 PC 处于 0x2xxxxxxx（ROM 区域），则表示 ROM 仍在运行或陷入无限循环（如等待外设响应）。 如果 PC 指向 0x002xxxxx（OCRAM）或其他 RAM 区域，则 ROM 可能尝试了跳转，但应用程序崩溃了。 如果 PC 指向 0x4000xxx（FlexSPI2 AMBA 区域）并被读取为全零或出现总线错误，则会发生跳转，但是 XIP 访问失败。

MCX Lab MCX Lab: Empowering University Innovation with NXP FRDM-MCXN947 What is MCX Lab? MCX Lab is an NXP initiative designed to foster collaboration with universities, providing students and educators with cutting-edge hardware, software, and educational resources. The program centers around the powerful NXP FRDM-MCXN947 development board, enabling hands-on learning and advanced research in embedded systems, AI/ML, IoT, and more. Key Features of the MCX Lab Program 1. FRDM-MCXN947 Comprehensive Hardware Platform MCXN947 MCU: Dual Arm® Cortex®-M33 cores @150MHz, up to 2MB dual-bank flash, Neural Processing Unit, PowerQuad, Smart DMA, and more. Rich Peripherals: User LEDs, buttons, accelerometer, temperature sensor, touch pad, Ethernet, USB Type-C, CAN-FD, WiFi, and extensive expansion options (Arduino®, FRDM, mikroBUS™, Pmod™, FlexIO/LCD, SmartDMA/Camera headers). Custom Shields: NXP-designed shields for introductory labs, featuring buttons, joystick, DIP switch, rotary encoder, LED ring, potentiometer, IR sensors, OLED display, and more. See MCX Lab Expansion Boards page for more. Add-on Modules: Wide portfolio of sensors, actuators, interfaces, displays, and wireless modules. Explore the Expansion Board Hub for more options. 2. Powerful Software Ecosystem Development IDEs and Build Tools: MCUXpresso IDE MCUXpresso for Visual Studio Code Third-party toolchains from Arm, IAR, Keil Examples and Quick Start Software: MCUXpresso SDK Debugging and Visualization Tools: LinkServer FreeMASTER Software Development Resources: MCUXpresso Config Tools Secure Provisioning Tool Secure Provisioning SDK (SPSDK) Device HSM Trust Provisioning RTOS: Zephyr™ OS AI Software Development: eIQ Toolkit HMI Design Software: GUI Guider Connectivity Software NXP Platform Accelerator 3. Educational Materials Lecture & Lab Content: Tailored for all levels—introductory (embedded basics), medium (GPIO, ADC, timers, serial comms), and advanced (Zephyr, AI/ML, UI/UX). See MCX Lab Educational Materials page for more. Invited Lectures: On-demand sessions by NXP engineers at partner universities. Documentation: Reference manuals, datasheets, getting started guides, application notes, and access to the MCUXpresso Training Hub. 4. Application Examples Application Code Hub: Application software packs, demo apps, code snippets, and integration with GitHub and VS Code for easy access and collaboration. Diverse Domains: AI/ML, audio, graphics, low power, motor control, power conversion, safety, security, networking, touch sensing, vision, voice, wireless connectivity, and more.

恩智浦技术日 - 特拉维夫 - 2016年3月22日 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 确保嵌入式系统安全的QorIQ可信功能的概述 Layerscape多核通信处理器的ARM® v8虚拟化 逻辑抽象和资源管理以及Layerscape管理复合体 家庭自动化的低功耗无线连接解决方案 NFC Everywhere - 为您的客户提供新的 NFC 用例 面向新虚拟网络的强大QorIQ多核处理器 面向工业-航空电子-军事-烹饪-蜂窝市场的射频功率解决方案 (L Gauthier) 可扩展多核QorIQ Layerscape处理器 基于 64 位软件环境的可扩展多核 QorIQ Layerscape 处理器，适用于企业、家庭和工业应用 (H Cohen) 可穿戴设备市场解决方案 面向未来网络的QorIQ Layerscape LS2085/88多核通信处理器 QorIQ LS2系列：AIOP、WRIOP、DPAA2 - 高性能数据路径和网络外设接口 VORTIQA智能虚拟化加速软件（IVAS）

Ara240 - LPDDR4 Memory Compatibility Guide The purpose of this document is to provide extended guidance for selection of compatible LPDDR4 memory devices that are supported by the Ara240 (aka Ara-2) processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the specific SoC requirement documents. LPDDR4 - maximum supported densities SoC Max Data bus width Maximum density Number of Interfaces Assumed memory organization Notes Ara240 64-bit 128Gb/16GB 2 Dual rank, Dual channel device with 17-row addresses 1   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes Ara240 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB) Micron   MT53E2G32D4DE-046 AUT:C  MT53E2G32D4DE-046 WT:C - 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB)   FORESEE FLXC4008G-30  2 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Micron MT53E512M32D1ZW-046BAUT:B     - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB)   Micron MT53E1G32D2NP-046 WT:B - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) SK Hynix H54G46CYRQX053N - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) SK Hynix H54G56CYRB-X247 421Y H54G56CYRB-X247 316A - 4Gb/(512MB) Total 8Gb/1GB (2 x 4Gb/1GB) SK Hynix H54G26AYRBX256 - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Samsung K4F6E3S4HB-KHCL      - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) ISSI IS43LQ32K01B 2 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) Samsung K4UBE3D4AB-MGCL - 8Gb/(1GB) Total 16Gb/2GB (2 x 8Gb/1GB)   Winbond W66DP2RQQAHJ 2 Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4C (LPDDR4). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 3: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Note 4: All memory parts are in production unless stated otherwise. Checked June 2026 Note 5: The processor does not support BYTE Mode (x8) memories.  Re: Ara240 - LPDDR4 Memory Compatibility Guide Cross reference: Ara-240 - NVM Memory Compatibility Guide

RT1021 input max current Hello, do you know how much current a GPIO input can handle? I'm using GPIO_AD_B1_02 and 8mA are flowing through that pin. What is the maximum current an input can handle before damaging the pin? The pin is on it's default values, if I understood right it is configured as input with 100k pulldown resistor by default Thank you Re: RT1021 input max current Hi @jtrujillo, In general, the maximum current for any RT1xxx GPIO pin should be limited to 25mA whether it is sourcing or sinking current. This is the safe limit for the technology to prevent reliability issues, like latent damage due to electromigration, and can be sustained for long durations if the pin needs to. BR, Edwin.

Connection problem with MCXN647 (Ee(42) error) Hi, I am having a problem with my FRDM-MCXN947 . Whenever I try to debug or flash my project, I get this error : I don't know if it's related, but it started when I changed this line in a while(1) loop to increase its frequency : SDK_DelayAtLeastUs(30000, SystemCoreClock); -> SDK_DelayAtLeastUs(10000, SystemCoreClock); I didn't update before the problem occurred, but I updated LinkFlash afterwards and it didn't solve anything. I already tried SPT erase but it didn't work. (Maybe I did it wrong.) On the SPT, after activating ISP mode, I was able to perform the “build image” and “write image” operations, but erasing still does not work. Thank you in advance for your help. PS: Please excuse my English and technical vocabulary, I am just starting this project at engineering school. Boot ROM|Booting | Flash Clock|Timers MCXN USB Re: Connection problem with MCXN647 (Ee(42) error) Hi @Peter-D  Please try using the Flash Programmer inside the SPT tool to erase and program a blinky SDK demo, and check whether it works properly. For details, please refer to the video in the attachment. If these steps work well but you still cannot debug with the onboard debugger, please use an external debugger to test. If you still have issues, please feel free to contact me. Thank you. BR Alice Re: Connection problem with MCXN647 (Ee(42) error) Hi @Alice_Yang, Thank you very much for your reply. I followed the instructions in the video, and the method works to make the LED flash. However, I get the same error when I return to the debugger from the MCUXpresso IDE. If the problem comes from the onboard debugger, I don't think I'll buy an external debugger such as PEMicro or SEGGER J-Link (if that's what you were referring to) especially since the board I'm using was lent to me at school. If I can't find a solution, I'll continue to use the flash programmer, which also works for my project, and I'll ask my professors if they have an external debugger. Best regards, Peter Re: Connection problem with MCXN647 (Ee(42) error) Hello @Peter-D  I’m not sure if the debugger on your board is actually broken. Please try updating the debugger firmware by following the instructions here: https://docs.nxp.com/bundle/UM12018/page/topics/Updating_MCU_Link_firmware.html  After the update, power cycle the board, create a new workspace in MCUXpresso IDE, import a fresh SDK demo, and try debugging again. It would be better if you could take a video and share it with me. I’ll help you check it. Thank you.     BR Alice Re: Connection problem with MCXN647 (Ee(42) error) Hello @Peter-D Thanks for your video. Please delete the .launch file (in below picture)and erase your board again. Use the Debug button shown in the picture below to start debugging. If it still doesn’t work, I recommend replacing the board. By the way, I will be on New Year holiday and will return on January 5th. If you still have questions, please contact me on that day. Thank you for your understanding, and Happy New Year! BR Alice Re: Connection problem with MCXN647 (Ee(42) error) Hello @Alice_Yang Thank you for your reply. I updated LinkServer as suggested, but I think I already had it after the problem appeared. I tried the update again anyway, then power-cycled the board, created a new workspace, and imported a demo project, but I am still getting the same Ee(42) error when trying to debug. I have recorded a short video showing the process, which I have attached. Thank you for your help, and I wish you a happy new year. Best regards, Peter

[SAF85xx] GMAC生成ツール/例 お客様は、HSE_FW の結果と比較して、IVT_AUTH 構成として GMAC 値を計算しました。現在、お客様は HSE_FW で同じ結果を得ることができませんでした。GMAC 計算のツールや例を示していただくことは可能でしょうか? たとえば、お客様は添付の IVT データを計算し、HSE_FW から GMAC 値を取得できます。 HSE_FW Re: [SAF85xx] GMAC Generation Tool/Example こんにちは、Himanshuさん。ご協力ありがとうございます。 1. HSE_FW 1.2.39.0 2. お客様に問い合わせる必要があります。 3. お客様はNIST特別出版物800-38Dを参照しています タイトル: ブロック暗号動作モードに関する推奨事項: ガロア/カウンタモード (GCM) と GMAC URL: https://csrc.nist.gov/publications/detail/sp/800-38d/final rm649929-HSE-H&Mファームウェアリファレンスマニュアル(2.9).pdfの8.3ホストシステムイメージの認証 4. お客様に問い合わせる必要があります。 Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん 取り組んでいます。さらに分析するために、以下の情報を提供していただけますか? 1. HSE FWバージョン 2. GMACを計算したツールは何か 3. IVT上のGMACを計算するためにどのような方法を使用しているか 4. HSE 出力 MAC と比較する GMAC のもう 1 つの値は何ですか? よろしく ヒマンシュ・クマール Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん 質問2と質問4の回答を教えていただけますか？ よろしくお願いいたします。 ヒマンシュ・クマール Re: [SAF85xx] GMAC Generation Tool/Example 2. と 4. の質問に関しては、お客様が Python スクリプトを共有しました。スクリプトを確認して、問題や提案が見つかった場合はお知らせください。 Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん お客様名を教えていただけますか？ よろしくお願いいたします ヒマンシュ・クマール Re: [SAF85xx] GMAC Generation Tool/Example デンソー株式会社および DTS Insight 社 Re: [SAF85xx] GMAC Generation Tool/Example あなたが生み出した価値を両方とも私と共有してもらえますか? Re: [SAF85xx] GMAC Generation Tool/Example 添付スクリプトとして SHA-256 および AES-256 を使用してスクリプトを変更しようとしました。しかし、それでも HSE_FW の計算結果と同じ結果を得ることはできません。 Re: [SAF85xx] GMAC Generation Tool/Example 添付のスクリプト、データ、および HSE_FW と Python スクリプトからの GMAC 値をご覧ください。 Excel ファイルでは、HSE_FW による GMAC 値が左側に表示され、テスト スクリプトの結果が右側に表示されます。 Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん いくつか情報を教えていただけますか？ どの soc Cut お客様が使用していますか? お客様は、このサービスHSE_SRV_ID_BOOT_DATA_IMAGE_SIGN を使用して IVT の GMAC タグを生成した後、この HSe サービス HSE_SRV_ID_BOOT_DATA_IMAGE_VERIFY を使用して IVT を検証しましたか? Re: [SAF85xx] GMAC Generation Tool/Example 1. 2.1 2. IVTはHSE_SRV_ID_BOOT_DATA_IMAGE_SIGNを使用して検証されませんでした Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん ご指摘のとおり、この GMAC も HSE による検証を受けていないため、HSE 側からの検証を受ける必要があります。HSE がそれを検証できない場合は、タグ自体に問題がある可能性があります。Python スクリプトは正しく機能しているため、生成されたタグを HSE が検証できないことは、タグが破損しているか、正しく生成されていない可能性があることを示しています。したがって、最初のステップは、HSE 側からタグを生成して検証することです。 よろしくお願いいたします ヒマンシュ・クマール Re: [SAF85xx] GMAC Generation Tool/Example こんにちは@hiroshiHirashimaさん 共有されたタグとデータを確認しましたが、HSE 側で検証されていません。自分の側でタグを生成すると、タグは正常に作成され、問題なく検証されます。 お客様にHSEから直接タグを生成して検証していただくようご依頼いただけますでしょうか？ お客様が使用しているタグが破損している可能性があります。 よろしくお願いいたします。 ヒマンシュ・クマール Re: [SAF85xx] GMAC Generation Tool/Example ご評価とご提案ありがとうございます。お客様側で確認していただくようお願いいたします。お客様からのフィードバックを受けて、さらに詳しい情報が公開され、共有されます。

例 MPC5748G レジスタ保護 GHS614 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ******************************************************************************** *詳細な説明: *添付文書「MPC5748G.pdfでのレジスター保護の使用方法」をお読みください ※詳しい説明はこちら * この例では、レジスタMC_MEのロックとロック解除の方法を示しています。RUN_MC[3].R. * 1 つのオプションはポインタを介してメモリに直接書き込むこと、2 番目のオプションは * ヘッダー ファイル reg_prot.h のマクロを使用する場合 * ------------------------------------------------------------------------------ ※テストHW:MPC574XG-324DS Rev.A + MPC574XG-MB Rev.C ※MCU:PPC5748GMMN6A 1N81M * Fsys:160 MHz PLL *デバッガ:Lauterbach Trace32 * 対象:internal_FLASH * ******************************************************************************** 全般

Build failed while compiling chromium-ozone-wayland Hello, I am trying to compile chromium-ozone-wayland on Yocto for IMX8MP board, but the compilation fails with the error: | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_configure | ERROR at //.gn:150:5: Assignment had no effect. | build_dotfile_settings.exec_script_allowlist + | ^--------------------------------------------- | You set the variable "exec_script_allowlist" here and it was unused before it went | out of scope. | WARNING: exit code 1 from a shell command. ERROR: Task (/home/admin/Dharmik/IMX8M-Plus/sources/meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_138.0.7204.157.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 2814 tasks of which 2800 didn't need to be rerun and 1 failed. I have added CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" in conf/local.conf Below is my yocto configuration, Build Configuration: BB_VERSION = "2.16.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS = "aarch64-poky-linux" MACHINE = "imx8mp-lpddr4-evk" DISTRO = "fsl-imx-wayland" DISTRO_VERSION = "6.18-whinlatter" TUNE_FEATURES = "aarch64 armv8a crc crypto"  Thanks, Dharmik Re: Build failed while compiling chromium-ozone-wayland I've seen this error in the past Chromium versions, and what worked for me in that build situation was a change in this file: \tmp\work\armv8a-mx8-poky-linux\chromium-ozone-wayland\117.0.5938.132\chromium-117.0.5938.132\media\gpu\sandbox\BUILD.gn if (current_cpu != "s390x" && current_cpu != "ppc64" && is_linux && ozone_platform_x11 && !is_castos) { # For DRI_DRIVER_DIR. configs += [ "//build/config/linux/dri" ] } Adding "&& ozone_platform_x11 " to the platform list at the bottom of this files fixed the issue. Could you check whether Chromium v138 has already ozone_platform_x11 added? Best regards, Diana Re: Build failed while compiling chromium-ozone-wayland After adding PREFERRED_VERSION_gn-native = "0+git" changes I am getting below error, | DEBUG: Python function extend_recipe_sysroot finished | DEBUG: Executing shell function do_configure | ERROR at //build/config/linux/dri/BUILD.gn:11:20: Script returned non-zero exit code. | dri_driver_dir = exec_script(pkg_config_script, | ^---------- | Current dir: /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/out/Release/ | Command: python3 /home/admin/Dharmik/IMX8M-Plus/build-imx8mp/tmp/work/armv8a-mx8mp-poky-linux/chromium-ozone-wayland/138.0.7204.157/sources/chromium-138.0.7204.157/build/config/linux/pkg-config.py --dridriverdir dri | Returned 1 and printed out: | | Error from pkg-config. | | stderr: | | Package dri was not found in the pkg-config search path. | Perhaps you should add the directory containing `dri.pc' | to the PKG_CONFIG_PATH environment variable | No package 'dri' found | | See //media/gpu/sandbox/BUILD.gn:31:18: which caused the file to be included. | configs += [ "//build/config/linux/dri" ] | ^------------------------- | WARNING: exit code 1 from a shell command. Thanks, Dharmik Re: Build failed while compiling chromium-ozone-wayland Hi Dharmik, Can you try adding to local.conf one more thing besides chromium package?  PREFERRED_VERSION_gn-native = "0+git" Let me know if the issue still persists. Best regards, Diana

s32_LLCE S32 系列中 LLCE 的加速方法主要是通过基于软件的路由和转发实现的，这种理解是否正确？实际上，硬件只包含一个查找表，而目的地的转发则完全由软件处理？ Re: s32_LLCE 你好，@yuancz 谢谢你的帖子。 1。从 S32G SOC 的角度来看，LLCE 是 SOC 上的 IP 块，LLCE 将主机 CPU 从所有接口级任务中卸下，以及对帧进行验证、身份验证以确保网络安全，它可以用于硬件加速以筛选和排定消息的优先级，因为S32 SOC上的内核不需要运行任何代码来处理此类流量，从这个角度来看，它确实是硬件加速引擎。 2. LLCE 实际上是恩智浦开发的内核、存储器、硬件加速 IP 模块和固件的组合。从 IP 块来看，软件（FW）运行在 M0+ 内核上，内核和其他硬件一起通过 FW API 实现主机所需的功能，从 LLCE 本身来看，一些操作是通过运行在 M0+ 内核上的代码完成的，这可以看作是基于软件（FW）的操作。 BR 切宁

how to change mode to 8g on MMA8451Q? Hello, i´m using accelerometer MMA8451Q on LFSTBEB3110 sensor kit. after testing i want to change the mode to 4g oder better 8g but i don´t know how. i read that i have to use code warrior and change something in the registers but i have neither the knowledge nor the devices for connecting and programming the kit. so my question is, do some options exist like switch a jumper or change settings in the toolbox? thank you for helping stefan Re: how to change mode to 8g on MMA8451Q? hey Jose, thank you for your help. so I will test the other evaluation kit you recommend. ciao Re: how to change mode to 8g on MMA8451Q? Hi Stefan, Unfortunately no, the designers of the SW GUI for this kit didn’t added the function to change g range or the registers values, and it is not possible to do this change via Hardware, so, the only way to change it from 2g to 4g or 8g would be programming the board externally via Code Warrior. If you do not have access to Code Warrior, and you need to check the full functionality of the Accelerometer MMA845x Family, then I would recommend you to get the LFSTBEB845X Evaluation kit compatible with Sensor Toolbox GUI: https://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=LFSTBEB845X In the following User Guide, you can find all the windows and features available for this kit: http://cache.freescale.com/files/sensors/doc/user_guide/MMA845xQSTUG.pdf Regards, Jose Re: how to change mode to 8g on MMA8451Q? Hello, Thank you for your post, however please consider moving it to the right community place (e.g. Sensors) to get it visible for active members. For details please see general advice Where to post a Discussion? Thank you for using Freescale Community.

i.MX 91 - LPDDR4 内存兼容性指南 本文档的目的是为选择 i.MX 91 系列处理器支持的兼容 LPDDR4 内存设备提供扩展指导。在所有情况下，强烈建议遵循恩智浦硬件开发者指南中针对特定 SoC 概述的动态随机存取存储器(DRAM)布局指南。 二进制密度（例如 1 GB、2 GB、4 GB）的内存设备是首选，因为它们通过与系统寻址方案保持一致并降低软件复杂性来简化内存管理。 LPDDR4 - 最大支持密度 SoC 最大数据总线宽度 最大密度 假定内存组织 说明 i.MX 91 (i.MX 91xx) 16 位 16GB / (2GB) 具有 17 行地址的单列单通道设备（R0-R16） 1, 2, 3 LPDDR4 - 经过验证的存储器列表 验证过程是一项持续性工作--预计将定期更新表格。 SoC 密度 内存供应商 经过验证的内存部件编号 说明 i.MX 91 16GB / (2GB) 美光 MT53E1G16D1FW-046 AAT:A MT53E1G16D1ZW-046 AAT:C 5 2 Gb/（256 MB） Winbond W66BP6NBHAHJ 4 8GB / (1GB) 南亚 NT6AN512M16AV-J1I   4 Gb/（512 MB） 南亚 NT6AN256M16AV-J1I 4 8GB / (1GB) ISSI IS43LQ16512B-046BLI 4 12GB / (1.5GB) 美光 MT53E768M16D1ZW-046 4 16GB / (2GB) 智能存储器 IMAG16L4KBBG 4 2 Gb/（256 MB） 南亚 NT6AN128M16AV-J1 4 4 Gb/（512 MB） 联合信息中心 SCB11N4G160BF-04ZI 4 4 Gb/（512 MB） ISSI IS43LQ16256B-053BLI 4 4 Gb/（512 MB） Winbond W66CP6RBHAHJ 4 Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. 注意：某些内存供应商的 LPDDR4 设备可能不支持低速运行，此外，DQ ODT 可能未处于活动状态，这可能会影响这些速度下的信号完整性。如果在用例中计划低速运行，请向内存供应商咨询内存设备的配置方面和可能的自定义，以确保功能正确。 注 1： 这些数字完全基于DDR控制器和DDR PHY的IP文档、为将其集成到SoC而选择的实现参数设置、SoC参考手册以及JEDEC标准 JESD209-4B（LPDDR4）。因此，除非另有说明，否则它们没有经过验证，也不能保证存储器供应商提供的 SoC 具有特定的密度和/或所需的内部结构。如果客户选择使用最大密度，并将其用于预期用途，则风险自负。 注 2： 不支持任何密度的字节模式 LPDDR4 设备（在两个芯片之间内部分配 x16 通道，每个 x8），因此，这些数字仅适用于内部组织 x16 的设备（在 JEDEC 规范中称为 " 标准 "）。 注 3： SoC 还支持双列单通道设备，因此，使用具有 16 行地址（R0-R15）的双列单通道设备也可以实现 16GB/2GB 的密度。 注 4： 该内存部件号没有经过 JEDEC 的全面验证，但通过了所有功能测试项目。 注 5： 该内存部件号不推荐用于新设计，已被新部件号取代

imx95 low power mode I am working on a custom i.MX95 board running Linux 6.12 (Yocto-based). I am facing a suspend-to-RAM (deep sleep) failure related to the USB3 host controller. When executing echo mem > /sys/power/state, the system aborts suspend with xhci-hcd: WARN: xHC CMD_RUN timeout followed by PM: failed to suspend async: error -110. The issue occurs consistently when USB host mode is enabled, even with no active USB traffic. I am using a fixed 5V VBUS regulator controlled by a GPIO, and the USB3 controller, PHY, clocks, and power-domains are defined in the DTS (attached). My requirement is to fully power off USB VBUS during low power mode while allowing the system to enter deep sleep successfully. I have attached the full suspend/resume dmesg logs and the relevant USB-related DTS nodes for reference. I would like guidance on the correct DTS and/or driver-side handling required to avoid the xHCI suspend timeout on i.MX95. Re: imx95 low power mode In custom board iam using fusb302 but not enabled as usb3.0 , we are using it as usb2.0 . but when entering into deep sleep ( echo mem > /sys/power/state ) The error is occuring in xhci-hcd driver. Test Setup: • SoC: i.MX95 • OS: Yocto Linux (kernel 6.x, NXP BSP) • USB Mode: Host (xHCI, USB3) • Connected Device: USB flash drive (Mass Storage) Boot the board normally. Connect a USB storage device to the USB3 host port. Verify enumeration using lsusb and confirm device is accessible. Enter low power mode using: echo mem > /sys/power/state After this step itself it is showing error. Resume the system using the configured wake-up source (power button/ GPIO). After resume, observe that the USB device either: is not detected, or shows xHCI / DWC3 related errors in dmesg, or requires USB re-plug to work again. ERROR LOGS : echo mem > /sys/power/state [ 117.057281] PM: suspend entry (deep) [ 117.066009] Filesystems sync: 0.005 seconds [ 117.071209] Freezing user space processes [ 117.076800] Freezing user space processes completed (elapsed 0.001 seconds) [ 117.083781] OOM killer disabled. [ 117.087011] Freezing remaining freezable tasks [ 117.132725] Freezing remaining freezable tasks completed (elapsed 0.041 seconds) [ 117.140164] printk: Suspending console(s) (use no_console_suspend to debug) [ 117.156868] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 117.267552] xhci-hcd xhci-hcd.2.auto: WARN: xHC CMD_RUN timeout [ 117.267611] xhci-hcd xhci-hcd.2.auto: PM: dpm_run_callback(): platform_pm_suspend returns -110 [ 117.267631] xhci-hcd xhci-hcd.2.auto: PM: failed to suspend async: error -110 [ 117.267702] PM: Some devices failed to suspend, or early wake event detected [ 117.268017] hub 1-0:1.0: hub_ext_port_status failed (err = -108) [ 117.268044] usb usb1-port1: cannot disable (err = -108) [ 117.516365] PM: resume devices took 0.248 seconds [ 117.570639] OOM killer enabled. [ 117.573777] Restarting tasks ... done. [ 117.575261] sd 0:0:0:0: [sda] Test Unit Ready failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK [ 117.578423] random: crng reseeded on system resumption [ 117.587117] sda: detected capacity change from 120164352 to 0 [ 117.598136] PM: suspend exit -sh: echo: write error: Connection timed out Re: imx95 low power mode Could you share us the details steps, that we can reporcuce it on our EVK Board? Thanks Re: imx95 low power mode Hi @kannappan , OK, we are going to have the New Year's Day holiday. when I back to office I will try it on our board and then give your reply. Wish you have a nice day Best Regards Rita Re: imx95 low power mode Hi @kannappan , Sorry for too busy this week, I will test it for you next week and share the result to you. Wish you have a nice day Best Regards Rita Re: imx95 low power mode HI @Rita_Wang , Is there any reply for the above issue. Best Regards Kannappan

CLRC663 (CLEV6630B) スタンバイ電流はデータシートよりはるかに高い こんにちは、 CLEV6630BでCLRC663を使用して、スタンバイ モードで電流を測定しています。 設定： CLEV6630B VDDピンはNordic Power Profiler Kit (PPK) (J303)を介して電源供給されます。 nRF52840とCLEV6630B間のSPI接続（MOSI、MISO、SCK、SSEL） CLRC663とのSPI通信 ジャンパーJ303、J101、J300が切断されています 問題： スタンバイモードでは、VDD で約 60～70 µAを測定しましたが、データシートでは約 4～6 µA と指定されています。 質問: スタンバイ電流が高くなる原因は何でしょうか? SPI、MCU、またはその他の I/O パス（オンボード回路を含む）を介したリークが発生する可能性がありますか？ データシートのスタンバイ電流に達するために、リーク電流を最小限に抑えるにはどうすればよいですか? スタンバイ データシートの基準を満たすために、VDD から CLRC663 への電流のみを測定するための推奨方法は何ですか? よろしくお願いします。 Re: CLRC663 (CLEV6630B) Standby Current Much Higher Than Datasheet こんにちは@Lior スタンバイ (アイドル) モードにするコマンドも送信する必要があります。 Re: CLRC663 (CLEV6630B) Standby Current Much Higher Than Datasheet こんにちは、 コマンド レジスタのスタンバイ ビットを上げています。