Missing Std_Types.h I have just upgraded to S32DS version 3.5 and have setup my pins and drivers. I have generated the necessary files but when I try and compile I get the following error message: Std_Types.h: No such file or directory This file is included in one of the generated files Port_Ci_Port_Lp.h /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" What am I doing wrong? Version 3.5 feels like a massive backward step from 3.4 which was super easy to use 😞 Andy Re: Missing Std_Types.h just looking for dir like this.  Re: Missing Std_Types.h for anyone who may read this in future: add them mannualy may sovle this problem. Re: Missing Std_Types.h I've had to go back to DS3.4 with SDK RTM 4.0.2 to get something that mostly works as advertised.  However, the more I use the NXP SDK, the more I hate it... Re: Missing Std_Types.h Any updates on this? @ArkAndyFraserdid you manage to solve the problem with the missing Std_Types.h file being included in the generated RTD files? I couldn't find  the Std_Types.h file even in the examples provided by NXP. Re: Missing Std_Types.h 3.6 Didn't improve things either.  These jokers don't bother to regression test.

ADKP保护后的S32K3 AES密钥配置 各位同事好， 我们已在 S32K 平台上启用基于 SHE 的安全启动。此外，我们还通过对 ADKP 密码进行编程来保护 JTAG 接口，并将生命周期推进到OEM。 请问我是否可以将 AES 密钥（密钥目录已针对 AES 密钥进行了调整）重新配置到已启用 ADKP 保护且OEM 中启用了生命周期管理的设备？ 或者我们需要将生命周期设置为IN_FIELD吗？ 另外，请指定要更新的密钥的OWNER 类型应该是什么？ 谢谢！ 布尚 Re: S32K3 AES Key Provisioning after ADKP protection 你好@Bhushan1312 密钥也可以在 OEM_PROD 或 IN_FIELD 生命周期中更新，但这取决于用户权限、主机身份 (HID) 和密钥所有者。 在 HSE 固件参考手册修订版中。2.8，请参见： 表 42. 主要集团所有者 6.2.3.2关键选择 这一部分很重要： “• 如果主机被授予超级用户 (SU) 权限，则目标密钥句柄的所有者必须与主机身份 (HID) 匹配（请参阅执行权限（超级用户与用户））” 如果主机具有用户权限，则目标密钥句柄的所有者必须为 HSE_KEY_OWNER_CUST（如果 LC 为 CUST_DEL），或 HSE_KEY_OWNER_OEM（如果 LC 为 OEM_PROD）。 然后是表 47、48 和 49，它们解释了在将密钥导入空槽或更新密钥时，是否需要根据用户权限进行身份验证和加密。 例如，如果您使用 CUST 拥有的授权密钥提升到超级用户权限，您也可以在 OEM_PROD 中导入或更新 CUST 密钥。 但是，在生命周期推进到 OEM_PROD 之前，您无法导入 OEM 拥有的密钥。那是因为您还没有OEM授权密钥。 此致， Lukas

S32G3におけるKMSの実現可能性 KMS機能はHSEデモアプリケーションでカスタムロジックで実装できますか?それとも HSE_FWTYPE = 9 / HSE_FWTYPE = 22 の使用は必須ですか? Re: Feasibility of KMS in S32G3 こんにちは、 @Pranathi06 投稿ありがとうございます。 デモアプリで言及されているKMSサービスはカスタムHSEのFW使用を目的としており、これがHSE_FWTYPE = 9(22)の理由です。プレミアムソフトに機能が含まれているため、詳細は地元のNXP担当者に問い合わせることをおすすめします(対応できない場合は support.nxp.com を通じてチケットを提出してください)。 BR チェイン  Re: Feasibility of KMS in S32G3 こんにちは、 @Pranathi06 ご返信ありがとうございます。 申し訳ありませんが、貴社のKMS実装がどのような規格/仕様を参照しているのかが不明なため、明確な確認を提供できない可能性があります。ご不便をおかけして申し訳ございません。 私の意見では、まず最新の標準HSE FW APIドキュメント(HSEのFWパッケージから入手可能なキーのインポート/エクスポート/生成など、標準HSEファイアメントでサポートされているすべてのAPI/サービスを含む)を確認し、その後、あなたの暗号スタックやカスタムアプリケーションに基づいて、KMSで定義された全機能が現在の標準HSE FWであるS32G3に基づいて正しく実装可能かどうかを分析することをお勧めします BR チェイン   Re: Feasibility of KMS in S32G3 KMS機能はHSEデモアプリケーション[標準]のカスタムロジックで実装できますか?

技術的実現可能性評価:i.MX8M Pluにおける32ビットアプリケーションおよび32ビットQt GUIのサポート こんにちは、NXP技術サポートチームの皆様、 [プロジェクトの背景] 私たちはi.MX8M Plusプラットフォームをベースにした量産プロジェクトを開発しています。 現在のソフトウェアスタックは以下の通りです: - ターゲットSoC:i.MX8M Plus(Cortex-A53、ARMv8-A 64ビット) - BSP / Yoctoバージョン:Yocto Project 5.0(Scarthgap)/ meta-imx - Linuxカーネル:6.6(AArch64) 【顧客要望】 エンドクライアントから新たな要件が出ました。これは、この64ビットのLinux OS環境上で32ビットLinuxアプリケーションと32ビットQt GUIアプリケーションの両方を動かす必要があるということです(古いプラットフォームからの32ビット依存やコードベースのためです)。 この要件が商業的かつ技術的に実現可能かどうかを評価するために、NXPの公式な立場を以下の点について明確にしていただけますか。 1. 32ビットアプリケーションおよび32ビットQtの実現可能性: NXPは公式に32ビットユーザー空間アプリケーション、特に32ビットQt GUIアプリケーションを、Yocto Multilibやその他の公式メカニズムを介して64ビットのi.MX8M Plusカーネル上で実行することをサポートしていますか? 2. 32ビットハードウェアアクセラレーションおよびQtライブラリの利用可能性: もしこれが可能なら: a) NXPは32ビットユーザー空間GPUアクセラレーションバイナリ(例:EGL/GLES用の32ビット版「imx-gpu-viv」)や、64ビットカーネル上でi.MX8M Plusと互換性のあるVPUバイナリを提供していますか? b) NXPはi.MX8ファミリ上で32ビットQtスタックをビルディングするための公式なYoctoレシピ、BSPサポート、または検証済みの設定を提供しているか? 3. パフォーマンスおよびレンダリングの制限(加速がない場合): i.MX8M Plusに32ビット専用GPUドライバが提供されていない場合、32ビットQtのGUIをソフトウェアレンダリング(例:LinuxFB、Mesa/llvmpipeソフトウェア)で動かすことは、NXPによって商用製品向けに公式に推奨されている、または本番環境対応と見なされているのでしょうか? 4. 公式推奨/解決策: i.MX8M Plus上でハードウェアアクセラレーションによる32ビットQtの動作がサポートされていない場合、NXPの公式声明と、従来の32ビットアプリケーション/Qtをi.MX8M Plusプラットフォームに移行するお客様向けの推奨アーキテクチャソリューションは何でしょうか? NXPからの正式な声明が、お客様向けの公式なエンジニアリングおよびアーキテクチャの基準となります。 お返事をお待ちしております！ ありがとうございます。よろしくお願いします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu こんにちは、 迅速かつ分かりやすいご説明をありがとうございました！ これにより、i.MX 8M Plus BSPの32ビットユーザー空間コンポーネントおよびGPU/マルチメディア加速に関するアーキテクチャ上の境界が完全に明確になりました。 NXPの公式推奨に従い、お客様のQtおよびアプリケーションスタック向けにネイティブAArch64展開を推進します。 改めてサポートありがとうございます!あなたの回答を解決済みとしてマークしました。 よろしくお願いします、 Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu こんにちは@DADAXIN I.mx8mp用のBSPは64ビット版です。AArch64専用にコンパイル・テストされており、Vivante GPUユーザー空間ライブラリ(EGL/OpenGL ES/Vulkan)、VPU、Qt 6(meta-qt6経由で提供)などのコンポーネントをカバーしています。i.MX 8M Plusでハードウェアアクセラレーションを使用した32ビットQtの利用は、BSPリリースの範囲外であり、サポート対象外の構成です。 私たちの推奨方法は、ネイティブのAArch64アプリケーション/Qtとして再コンパイルすることです。 32ビットソリューションが必須の場合は、以下のリンクから当社のプロフェッショナルサービスまでご連絡ください。 https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

技术可行性评估：在 i.MX8M 处理器上支持 32 位应用程序和 32 位 Qt GUI 您好，NXP技术支持团队， 【项目背景】 我们正在基于 i.MX8M Plus 平台开发一个生产项目。 我们目前的软件栈包括： - 目标SoC：i.MX8M Plus（Cortex-A53，ARMv8-A 64位） - 电路板支持包。 / Yocto 版本：Yocto Project 5.0 (Scarthgap) / meta-imx - Linux 内核：6.6 (AArch64) [客户需求] 我们的最终客户提出了一个新的要求：他们需要在 64 位 Linux 操作系统环境中运行 32 位 Linux 应用程序和 32 位 Qt GUI 应用程序（因为存在来自旧平台的遗留 32 位依赖项/代码库）。 为了评估这一要求在商业和技术上是否可行，请您澄清恩智浦对以下几点的官方立场： 1. 32 位应用程序和 32 位 Qt 的可行性： NXP 是否正式支持通过 Yocto Multilib 或任何其他官方机制在 64 位 i.MX8M Plus 内核上运行 32 位用户空间应用程序（特别是 32 位 Qt GUI 应用程序）？ 2. 32 位硬件加速和 Qt 库的可用性： 如果可行的话： a) NXP 是否提供 32 位用户空间 GPU 加速二进制文件（例如，用于 EGL/GLES 的 32 位版本的 `imx-gpu-viv`）和与 64 位内核上的 i.MX8M Plus 兼容的 VPU 二进制文件？ b) NXP 是否提供官方的 Yocto 配方、电路板支持包。支持或经过验证的配置，以便在 i.MX8 系列上构建 32 位 Qt 堆栈（`lib32-qtbase`、`lib32-qtdeclarative` 等）？ 3. 性能和渲染限制（如果没有加速）： 如果 NXP 没有为 i.MX8M Plus 提供 32 位专有 GPU 驱动程序，那么通过软件渲染（例如 LinuxFB、软件 Mesa/llvmpipe）运行 32 位 Qt GUI 是否被 NXP 正式推荐或认为适用于商业产品？ 4. 官方建议/解决方案： 如果不支持在 i.MX8M Plus 上运行硬件加速的 32 位 Qt，NXP 的官方声明和推荐的架构解决方案是什么？该方案适用于将传统 32 位应用程序/Qt 迁移到 i.MX8M Plus 平台的客户。 NXP 的正式声明将作为我们向客户提供的官方工程和架构基准。 期待你的答复！ 感谢并致意 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu 你好， 非常感谢您及时而清晰的解释！ 这完全阐明了 i.MX 8M Plus 电路板支持包。 在 32 位用户空间元器件和 GPU/多媒体加速方面的架构边界。 我们将遵循 NXP 的官方建议，推进为客户的 Qt 和应用程序堆栈部署原生 AArch64。 再次感谢您的支持！我已将您的回复标记为已接受的解决方案。 此致， Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu 嗨@DADAXIN 我们为 I.mx8mp 提供的 电路板支持包。 是 64 位版本。它专门针对 AArch64 编译和测试，涵盖 Vivante GPU 用户空间库（EGL/OpenGL ES/Vulkan）、VPU 和 Qt 6（通过 meta-qt6 提供）等元器件。在 i.MX 8M Plus 上使用 32 位 Qt 并启用硬件加速超出了 电路板支持包。版本范围，因此不属于受支持的配置。 我们建议将其重新编译为原生 AArch64 应用程序/Qt。 如果必须使用 32 位解决方案，请点击以下链接联系我们的专业服务团队： https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

关于 MCAL 支持 EB 的咨询 你好 我写信是为了咨询S32k3144微控制器的MCAL支持情况。请问该设备是否支持通过EB（Elektrobit）配置工具实现的MCAL，我能否将其用于生产环境，还是需要任何许可证？ 如果您能提供有关可用堆栈和兼容性的任何文档或指导，我们将不胜感激。 Re: Inquiry regarding MCAL support EB 你好， S32K344 / K314 受 NXP 实时驱动程序 (RTD) / AUTOSAR MCAL 支持，包括与 EB tresos Studio 集成，用于配置和代码生成。NXP 提供 RTD/MCAL 软件，该软件为标准软件，符合生产使用要求，并且免费提供。 请注意，EB tresos Studio 本身需要有效的 Elektrobit 许可证。EB tresos 的许可条款由 Elektrobit 管理，因此有关商业用途的详细信息，我们建议您联系 Elektrobit 或您当地的 恩智浦代表。 S32K3 RTD 软件包包括 MCAL 驱动程序、EB tresos 插件、文档和示例项目，以支持开发和集成。 顺祝商祺！ Peter

缺少 Std_Types.h 文件 我刚刚升级到 S32DS 版本 3.5，并且已经设置好了引脚和驱动器。 我已经生成了必要的文件，但是当我尝试编译时，出现以下错误信息： Std_Types.h: No such file or directory 该文件包含在生成的文件之一 Port_Ci_Port_Lp.h 中。 /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" 我做错了什么？ 3.5 版本感觉比 3.4 版本差远了，3.4 版本用起来超级方便。 😞 安迪 Re: Missing Std_Types.h 我只是在找类似这样的目录。 Re: Missing Std_Types.h 致未来可能读到这篇文章的任何人： 手动添加或许可以解决这个问题。 Re: Missing Std_Types.h 我不得不回退到DS3.4版本，搭配SDK RTM 4.0.2，才能得到一个基本能按预期运行的版本。然而，我越使用NXP SDK，就越讨厌它…… Re: Missing Std_Types.h 这件事有任何进展吗？ @ArkAndyFraser你解决 Std_Types.h 文件缺失的问题了吗？该文件是否包含在生成的RTD文件中？ 我找不到 Std_Types.h 文件。即使在 NXP 提供的示例中，文件也是如此。 Re: Missing Std_Types.h 3.6 情况也没有改善。这些家伙连回归测试都不做。

S32G3中KMS的可行性 能否通过 HSE Demo 应用程序中的自定义逻辑来实现 KMS 功能，还是必须使用HSE_FWTYPE = 9 / HSE_FWTYPE = 22 ？ Re: Feasibility of KMS in S32G3 你好， @Pranathi06 感谢分享。 演示应用程序中提到的 KMS 服务旨在使用自定义 HSE 固件，因此 HSE_FWTYPE = 9(22)。由于它是高级软件中包含的功能，我建议您联系当地的 恩智浦代表（如果无法联系，请通过 support.nxp.com 提交工单）以了解详细信息。 BR 陈银  Re: Feasibility of KMS in S32G3 你好， @Pranathi06 感谢您的回复。 抱歉，我不确定您的KMS实现指的是哪种标准/规范，我可能无法提供明确的确认，给您带来的不便敬请谅解。 依我之见，您首先可以查阅最新的标准 HSE 固件 API 文档（其中包含标准 HSE 固件支持的所有 API/服务，例如密钥导入/导出/生成等，这些内容可在 HSE 固件包中找到），以明确 HSE 固件支持的所有密钥管理服务。然后，根据您的加密协议栈/自定义应用程序，分析您 KMS 中定义的所有功能是否能够基于当前 S32G3 标准 HSE 固件正确实现。 BR 陈银   Re: Feasibility of KMS in S32G3 能否在 HSE Demo 应用程序[标准]中通过自定义逻辑实现 KMS 功能？

Inquiry regarding MCAL support EB hello I am writing to inquire about the MCAL support for the S32k3144 microcontroller. Could you please clarify as this device supports MCAL implementations through EB (Elektrobit) configuration tools can use for my production or need any license? Any documentation or guidance you can provide regarding the available stacks and compatibility would be greatly appreciated. Re: Inquiry regarding MCAL support EB Hello, The S32K344 / K314 is supported by NXP Real-Time Drivers (RTD) / AUTOSAR MCAL, including integration with EB tresos Studio for configuration and code generation. NXP provides the RTD/MCAL software as standard software that is qualified for production use and available free of charge. Please note that EB tresos Studio itself requires a valid Elektrobit license. Licensing terms for EB tresos are managed by Elektrobit, so for commercial usage details we recommend contacting Elektrobit or your local NXP representative. The S32K3 RTD package includes the MCAL drivers, EB tresos plugins, documentation, and example projects to support development and integration. Best regards, Peter

Feasibility of KMS in S32G3 Can KMS functionality be implemented through custom logic in the HSE Demo application, or is the use of HSE_FWTYPE = 9 / HSE_FWTYPE = 22 mandatory? Re: Feasibility of KMS in S32G3 Hello, @Pranathi06  Thanks for the post. The KMS service mentioned in the demo app is targeted for using the custom HSE FW, which is the reason for HSE_FWTYPE = 9(22), since it is function included in the premium software, I suggest contacting your local NXP representative(if not available, raising tickets via support.nxp.com) for details. BR Chenyin  Re: Feasibility of KMS in S32G3 Hello, @Pranathi06  Thanks for your reply. Sorry that I am not sure what kind of the standard/spec your KMS implementation referring to,  I may not be able to provide a clear confirmation of it, sorry for your inconvenience. From my opinion, you may firstly check the latest standard HSE FW API document(with all APIs/services that be supported in the standard HSE FW including key import/export/generate, etc., which could be found from the HSE FW package), to clarify all key management services that HSE FW supported, then based on your crypto stack/custom application, to analyze if the full functions defined in your KMS could be implemented correctly based on current standard HSE FW of S32G3 BR Chenyin   Re: Feasibility of KMS in S32G3 Can KMS functionality be implemented through custom logic in the HSE Demo application[standard]?

Std_Types.h が見つかりません 私はちょうどS32DSバージョン3.5にアップグレードし、ピンとドライバを設定しました。 必要なファイルは生成しましたが、コンパイルしようとすると次のエラーメッセージが表示されます。 Std_Types.h: No such file or directory このファイルは、生成されたファイルの一つである Port_Ci_Port_Lp.h に含まれています。 /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" 私は何が間違っているのでしょうか？ バージョン3.5は、非常に使いやすかった3.4から大きく後退したように感じます。 😞 アンディ Re: Missing Std_Types.h このようなディレクトリを探しています。 Re: Missing Std_Types.h FUTUREこれを読むかもしれない人へ: 手動で追加すれば、この問題は解決するかもしれません。 Re: Missing Std_Types.h 私はDS3.4のSDM RTM 4.0.2に戻って、ほぼ宣伝通りに動作するものを手に入れました。しかし、NXP SDKを使えば使うほど、ますます嫌いになってきました... Re: Missing Std_Types.h この件について何か進展はありますか？ @ArkAndyFraser さん、 Std_Types.h が見つからない問題は解決できましたか？生成されたRTDファイルに含まれるファイルですか？ Std_Types.h が見つかりませんでしたNXPが提供する例にもファイルが含まれています。 Re: Missing Std_Types.h 3.6　状況は改善しなかった。こいつらは回帰テストすらやろうとしない。

Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi NXP Technical Support Team, [Project Background] We are developing a production project based on the i.MX8M Plus platform. Our current software stack is: - Target SoC: i.MX8M Plus (Cortex-A53, ARMv8-A 64-bit) - BSP / Yocto Version: Yocto Project 5.0 (Scarthgap) / meta-imx - Linux Kernel: 6.6 (AArch64) [Customer Requirement] Our end-customer has raised a new requirement: they need to run both 32-bit Linux applications and 32-bit Qt GUI applications on this 64-bit Linux OS environment (due to legacy 32-bit dependencies/codebase from older platforms). To evaluate whether this requirement is commercially and technically feasible, could you please clarify NXP's official stance on the following points: 1. Feasibility of 32-bit Applications & 32-bit Qt: Does NXP officially support running 32-bit user-space applications—specifically 32-bit Qt GUI applications—on a 64-bit i.MX8M Plus kernel via Yocto Multilib or any other official mechanism? 2. Availability of 32-bit Hardware Acceleration & Qt Libraries: If this is feasible: a) Does NXP provide 32-bit user-space GPU acceleration binaries (e.g., a 32-bit version of `imx-gpu-viv` for EGL/GLES) and VPU binaries compatible with i.MX8M Plus on a 64-bit kernel? b) Does NXP provide official Yocto recipes, BSP support, or validated configurations for building a 32-bit Qt stack (`lib32-qtbase`, `lib32-qtdeclarative`, etc.) on the i.MX8 family? 3. Performance & Rendering Limitations (If Acceleration is Absent): If 32-bit proprietary GPU drivers are NOT provided for i.MX8M Plus, is running a 32-bit Qt GUI via software rendering (e.g., LinuxFB, software Mesa/llvmpipe) officially recommended or considered production-ready by NXP for commercial products? 4. Official Recommendation / Solution: If running hardware-accelerated 32-bit Qt on i.MX8M Plus is not supported, what is NXP's official statement and recommended architectural solution for customers migrating legacy 32-bit applications/Qt to the i.MX8M Plus platform? A formal statement from NXP will serve as our official engineering and architectural baseline for the customer. Looking forward to your reply! Thanks and regards i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi, Thank you very much for the prompt and clear explanation! This fully clarifies the architectural boundaries of the i.MX 8M Plus BSP regarding 32-bit user-space components and GPU/multimedia acceleration. We will follow NXP's official recommendation and push forward with the native AArch64 deployment for our customer's Qt and application stack. Thanks again for your support! I have marked your reply as the accepted solution. Best regards, Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu Hi @DADAXIN  Our BSP for the I.mx8mp is a 64-bit version. It is compiled and tested exclusively for AArch64, covering components such as the Vivante GPU user-space libraries (EGL/OpenGL ES/Vulkan), the VPU, and Qt 6 (provided via meta-qt6). Using 32-bit Qt with hardware acceleration on the i.MX 8M Plus falls outside the scope of the BSP release and is not a supported configuration. Our recommended approach is to recompile it as a native AArch64 applications/Qt. If a 32-bit solution is a hard requirement, please contact our Professional Services following below link： https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

S32K3 AES Key Provisioning after ADKP protection Hello Team, We have enabled SHE Based Secure Boot on S32K platform. Also we are protecting JTAG interface by programming ADKP password and Advancing Life Cycle to OEM.  May i know if I can re-provision AES keys (Key Catlog is already aligned for AES keys) to device with ADKP protection enabled with Life Cycle in OEM.  Or do we need to set Life Cycle to IN_FIELD? Also, do Specify what should be the OWNER type for KEY to be updated? Thank You, Bhushan Re: S32K3 AES Key Provisioning after ADKP protection Hi @Bhushan1312  The keys can be updated also in OEM_PROD or in IN_FIELD life cycle but it depends on user rights, Host Identity (HID) and key owner. In HSE firmware reference manual rev. 2.8, see please: Table 42. Key group owners 6.2.3.2  Key Selection This section is important: “• If the host is granted with Super User (SU) rights, the owner of the target key handle must match the host identity (HID) (see Execution Rights (Super User vs. User)) If the host has User rights, the owner of the target key handle must be HSE_KEY_OWNER_CUST if LC is CUST_DEL, or HSE_KEY_OWNER_OEM if LC is OEM_PROD” Then there are tables 47, 48 and 49 which explain if authentication and encryption is needed based on user rights when importing a key to empty slot or when updating a key. For example, if you elevate to super user rights using authorization key owned by CUST, you can import or update CUST keys also in OEM_PROD. But you can’t import keys owned by OEM before the life cycle is advanced to OEM_PROD. That’s because you don’t have OEM authorization key yet. Regards, Lukas

ADKP保護後のS32K3 AESキープロビジョニング こんにちは、チームの皆さん、 S32Kプラットフォーム上でSHEベースのセキュアブートを有効にしました。また、ADKPパスワードのプログラミングとOEMへのライフサイクル推進などでJTAGインターフェースを保護しています。 AESキー(Key CatlogはすでにAESキーにアライメントされています)を、OEMのライフサイクルでADKP保護を有効にしたデバイスに再プロビジョニングできるか教えていただけますか? それとも、ライフサイクルをIN_FIELDに設定する必要があるのでしょうか？ また、更新するキーの所有者タイプを指定してください。 ありがとうございました。 ブーシャン Re: S32K3 AES Key Provisioning after ADKP protection こんにちは、@Bhushan1312さん キーはOEM_PRODやライフサイクルIN_FIELD更新可能ですが、ユーザー権限、ホスト識別(HID)、キー所有者に依存します。 HSEファームウェアのリファレンスマニュアルでは、2.8を参照してください。 表42。主要なグループ所有者 6.2.3.2キー選択 このセクションは重要です。 「• ホストにスーパーユーザー(SU)権限が付与された場合、ターゲットキーハンドルの所有者はホストの識別子(HID)と一致しなければなりません(実行権(スーパーユーザー対ユーザー)を参照) ホストがユーザー権を持っている場合、LCがCUST_DELの場合はターゲットキーハンドルの所有者がHSE_KEY_OWNER_CUSTされ、LCがOEM_PRODの場合はHSE_KEY_OWNER_OEM」とされています。 次に、表47、48、49があり、キーを空スロットにインポートする際や鍵を更新する際にユーザー権限に基づく認証や暗号化が必要かどうかを説明しています。 例えば、CUSTが所有する認可キーを使ってスーパーユーザー権利に昇格した場合、OEM_PRODでもCUSTキーをインポートまたは更新できます。 しかし、ライフサイクルがOEM_PRODに進むまではOEM所有の鍵をインポートすることはできません。それは、まだOEM認証キーをお持ちでないためです。 よろしくお願いいたします。 ルーカス

Code compression MPC556 Hi there. I'm working on a legacy MPC556 microcontroller where I don't have an option to change it. I need any code compressor. Reading MPC555UM, I could find the following at 4.3.1: "Compression is done off line by a special compressor tool, using a fixed vocabulary instruction based algorithm, optmized for the PowerPC instruction set." I've searched for some compiler or even other tool to compress my C code but I've no idea which one I must use. I saw somebody mentioning about Squeezard compressor but I couldn`t find it to download or even buy it. Is there something I can do to compress my C code ? It can be any tool (compiler with a compression option or compressor software) even in case I need to buy it! My last option will be to develop by my own but I don't know how tough is that. Re: Code compression MPC556 Hi, colleague! Have you managed to find any information about the code compression mechanism? Please contact with me [email protected] Re: Code compression MPC556 Hi @juninholiveira90  I'm sorry but the tools and documentation for code compression are not available anymore. Also MPC555/556 are already in End Of Life status, the device is no longer manufactured, so it's not supported anymore. Regards, Lukas

コード圧縮 MPC556 やあ。私はレガシーのMPC556マイクロコントローラを扱っていて、変更オプションがありません。コード圧縮ツールが必要です。MPC555UMを読んでみると、4.3.1で次のような記述が見つかりました。「圧縮は、PowerPC命令セットに最適化された固定語彙命令ベースのアルゴリズムを使用する専用の圧縮ツールによってオフラインで行われます。」 Cコードを圧縮できるコンパイラや他のツールを検索しましたが、どれを使えばいいのか全くアイデアがありません。Squeezardコンプレッサーについて言及している人を見かけたのですが、ダウンロードも購入もできませんでした。Cコードを圧縮する方法はありますか?圧縮オプション付きのコンパイラやコンプレッサーソフトウェアなど、どんなツールでも使えますし、購入が必要になった場合にも対応できます! 最後の手段は自分で開発することですが、それがどれほど大変なことなのか分かりません。 Re: Code compression MPC556 こんにちは、同僚さん！コード圧縮の仕組みに関する情報は何か見つかりましたか？どうかお問い合わせください [email protected] Re: Code compression MPC556 こんにちは、@juninholiveira90 申し訳ありませんが、コード圧縮のためのツールやドキュメントはもう利用できません。 また、MPC555/556はすでにエンドサービス状態にあり、製造中でサポートされていません。 よろしくお願いいたします。 ルーカス

MCUXpressoツールチェーンはどこにありますか？ NXPユーザーの皆様へ、 MCUXpressoが最終的な組み込みファームウェアを構築するのと同じツールチェーンを使って、外部ライブラリ(埋め込みTLS)を構築しようとしています。 私はLinuxでMCUXpressoを実行し、同じコンピュータで組み込みTLSをビルディングしています。 embedTLSのライブラリ生成メイクファイルをMCUXpressoツールチェーンと連携させるのを手伝ってもらえますか? Re: Where is MCUXpresso toolchain こんにちは、 @s_hdl 投稿ありがとうございます！ Linuxのデフォルトツールチェーンパスは /usr/local/mcuxpressoide- /ide/tools/bin/ です。 使用している実際のバージョンに合わせて変更してください。例：mcuxpressoide-25.6.136 BR Re: Where is MCUXpresso toolchain ご協力いただき、誠にありがとうございました。

i.MX RT1176 eDMA：错误时停止机制设置的 CR[HALT] 无需任何软件写入即可清除。 你好， 我们正在调查运行在 PX4 飞行器上的 NuttX 的 i.MX RT1176（rev B0）的 eDMA 错误。 控制器板（fmu-v6xrt）。NuttX 中已找到并修复了错误的触发信号，但是 我们观察到一些eDMA行为，这些行为无法用参考手册解释，我们希望 理解它。 背景（公开报告）： https://github.com/apache/nuttx/issues/20881 修复已合并到 apache/nuttx 项目中： https://github.com/apache/nuttx/pull/20893 ＃＃ 配置 - eDMA（用于 LPSPI、LPI2C 和 LPUART；不是 eDMA_LPSR） - CR[HOE] = 1（出错时停止），CR[EDBG] = 1 - 已启用散射/聚集；已启用次级环路通道链接 (ELINK) - 使用的通道：LPSPI1/2/3、LPI2C1/2/3、LPUART3/4/5/6/8/10 ＃＃ 发生了什么 驱动程序错误导致在 LPUART 上执行有效的 TCD 后，将 TCD 与 CITER = BITER = 0（分散/聚集）关联起来。 TX通道。我们在错误中断处理程序中捕获了 eDMA 寄存器，然后清除它们。 错误信息： - ES[NCE] 已设置，故障通道 = LPUART TX 通道，TCD CITER = BITER = 0 - CR = 0x432（已设置 HALT） 稍后我们从线程上下文（中断之外）读取 CR 时，它是 0x412（HALT 清除）。 同一信道上出现了成对的错误。大多数配对中，两个错误都出现在同一位置。 毫秒，但在某些配对中，第二个错误发生在第一个错误之后 1-269 毫秒。在这些情况下 LPSPI 和 LPI2C 传输停止的时间几乎与两者之间的时间间隔相同。 错误（例如，268 毫秒间隙 / 270.2 毫秒中断）。 软件的功能 - CR 只在初始化时写入一次。之后没有代码会写入 CR[HALT] = 0。 - 在错误中断处理程序中，驱动程序会为通道写入 CERR，然后终止程序。 该通道上的传输：CEEI、CERQ、TCD CSR = 0、TCD DLASTSGA = 0。 参考手册（修订版）5) 将 CR[HOE] 描述为：“任何错误都会导致 eDMA 引擎写入 1 到 HALT 场。随后，eDMA 引擎会忽略所有服务请求，直到您写入为止。 将 0 设置为 HALT 场。我们的观察结果与此不符，因为 HALT 在没有任何任何变化的情况下就变成了 0。 软件编写。 ＃＃ 问题 1.当 CR[HOE] = 1 时，在什么条件下 CR[HALT] 会被清除而无需对 CR 进行软件写入？ 例如，写入 CERR 或 CERQ，或者激活或终止另一个通道。 2. 当 CR[HALT] = 1 时，如果一个子循环已经在执行，会发生什么？ 渠道，以及在此期间收到的服务请求？他们是迷路了吗？还是…… HALT 清除后是否需要继续维护？ 3.在错误处理程序将 CERQ 和 TCD CSR = 0 写入故障通道后，会发生什么？ 是否会在 1-269 毫秒后在同一通道上引发第二次 NCE？ 4. 对于多个外设共享 eDMA 的系统，NXP 是否建议 HOE = 0 或 HOE = 1？如果 HOE = 1，预期的恢复操作是否是在错误处理程序中写入 CR[HALT] = 0？ 我们在 i.MX RT1170 芯片勘误表（修订版）中没有找到关于此的勘误。1.6）。我们可以分享 如果需要，可以提供寄存器捕获方法以及测量的更多详细信息。 谢谢！ i.MXRT Re: i.MX RT1176 eDMA: CR[HALT] set by Halt-On-Error clears without any software write to C 嗨@宫胁， 感谢您的联系！您是否尝试过在RT1176 rev B0开发板上使用MCUXpresso SDK示例程序来重现此问题？我认为这是一种将 eDMA 行为与 NuttX 驱动程序和 PX4 工作负载分离的有效方法。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

代码压缩 MPC556 你好呀。我正在使用一款老旧的MPC556微控制器，没有办法更换它。我需要一款代码压缩器。阅读MPC555UM手册时，我在4.3.1节中找到了以下内容：“压缩是由一个特殊的压缩工具离线完成的，该工具使用基于固定词汇表指令的算法，并针对 PowerPC 指令集进行了优化。” 我一直在寻找一些编译器或其他工具来压缩我的 C 代码，但我不知道应该使用哪一个。我看到有人提到Squeezard压缩器，但我找不到下载或购买的地方。有什么办法可以压缩我的C代码吗？可以是任何工具（带有压缩选项的编译器或压缩软件），即使我需要购买它也没关系！ 我的最后一个选择是自己开发，但我不知道这有多难。 Re: Code compression MPC556 嗨，同事！你找到任何关于代码压缩机制的信息了吗？请联系我：[email protected] Re: Code compression MPC556 你好@juninholiveira90 很抱歉，代码压缩的工具和文档已不再提供。 此外，MPC555/556 已经停产，该设备不再生产，因此不再提供支持。 此致， Lukas

MC705J1ACDWE Need confirm COD Spoiler (Highlight to read) The MC705J1ACDWE product has reached its end-of-life (EOL). Please help confirm the wafer diffusion location (COD) for this product. Thank you. The MC705J1ACDWE product has reached its end-of-life (EOL). Please help confirm the wafer diffusion location (COD) for this product. Thank you. 回复： MC705J1ACDWE Need comfirm COD Thank you for your reply and support. Additionally, I obtained original label information from another source, which shows "Diffused In:TH". I can still use this to confirm the information, right? Re: MC705J1ACDWE Need comfirm COD Im sorry for the inconveniences this might cause you, there is no information available to share for this End of Life/Obsolete family Part Number. Best Regards. 回复： MC705J1ACDWE Need comfirm COD Could you help us to confirm your source? Could you please contact your product distributor for further information about this inquiry? As this can help you find the correspondent COD. Best Regards