Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
MPC8308CVMAGDA例外0055255 上記の部品番号の例外について説明できる人はいますか。MPC8308CVMAGDA が必要ですが、受け取った部品にはS PC8308CVMA F DA とマークされており、AF 部品番号の末尾は 333Mhz を示していますが、必要な部品番号は 400Mhz を示しています。デバイスの右上隅には、以前は見たことのない「M」マークも追加されていますが、これは例外の一部として追加されたのでしょうか?その部品は同じ機能を持ちますか? 受け取ったデバイスとラベリングの写真を添付しました。 Re: MPC8308CVMAGDA EXCEPTION 0055255 サプライヤーに COC 証明書があるかCAN尋ねることができます。COC 証明書を持つサプライヤーだけが真の正規サプライヤーです。 Re: MPC8308CVMAGDA EXCEPTION 0055255 偽造品を購入しました。すぐに返却してください。 これは詐欺です。 正しい画像をCANお送りします。当社のPCB工場では写真を撮ります。 Re: MPC8308CVMAGDA EXCEPTION 0055255 こんにちは、 私たちも同じ状況です。あなたはCASEをどのように進めましたか?NXPは、MPC8308CVMAGDAとS PC8308CVMA F DAが同一であることを確認しましたか? よろしくお願いします。
View full article
IMX95EVK M7 核心的刷写问题 你好, 我正在尝试运行一个 M7 应用程序 IMX95LPD5EVK-19 下列的 AN14748 ,但我无法刷机。 flash.bin 用 UUU。短暂检测到电路板后,SDPS 启动立即失败。 硬件: IMX95LPD5BB-19 修订版 A1 (2024 NXP BV) 启动开关(SW7[1:4]): 1001(序列号下载) 目标: eMMC 主持人: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 尝试过的 SDK(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 两者产生的结果相同。 命令: 光盘 IMX95LPD5EVK/版本_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo 呜呜呜 -b EMMC flash.bin   错误: 成功 0 失败 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: 启动 -f flash.bin   执行步骤(根据 AN14748): 在电路板断电的情况下,将 SW7 设置为 1001 将 USB 连接到主机 跑步 sudo uuu -b emmc flash.bin 电源循环板 每次 SDPS 启动都失败 请分享一下该版本板上 M7 内核的刷写步骤以及支持的电路板支持包。版本。 Re: Flashing Issue on IMX95EVK's M7 core 你好, A1 版本的最新支持 电路板支持包。 是 Linux 6.12.20。 另外,您还可以尝试从头开始构建整个二进制文件(Uboot+SPL+ATF+固件+M-SDK)。 ## ## Download and extract ARM GCC toolchain ## ## $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### 请注意使用最新支持的电路板支持包。版本。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin ## ## Build Uboot ## ## $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build ATF ## ## $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build SM ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (如果关联的 mx95evk.cfg 文件已更改,则此步骤可选的) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (MCUXpresso 测试配置) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=tcm DEBUG=1 (仅适用于 i.MX 95 A1) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept ## ## M7 SDK compilation ## ## $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For ITCM ## ## $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For DDR ## ## $ exit(这将关闭终端,请重新打开终端) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-启动.bin ./iMX95 $ cp ../uboot-imx/spl/u-启动-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 您可以使用生成的二进制文件来刷写您的 EVK,我们已经在独立组网 \(SA\) 模式下测试过,它可以正常工作。 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 如果从 EMMC 启动,则根据快速入门指南,SW7-3 应为 1。 IMX95LPD5EVK-19
View full article
i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, I'd like to report an issue I encountered with CST regarding RSA-PSS signature verification on an i.MX93-evk platform, which I believe is a bug. Below, I describe the steps that led me to this discovery. I'm currently implementing the secure boot procedure on an i.MX93-EVK platform and successfully got it working with the standard, documented procedure using CST v4.0.1. I then wanted to sign the various binaries outside of CST, using OpenSSL directly (note: this is not a PKCS#11 setup, I'm just using my own RSA key with the OpenSSL CLI/API). I came across the following procedure, which describes exactly what I wanted to achieve: Using HSM mode for code signing in AHAB devices.pdf This works well with keys generated using the ahab_pki_tree tool provided by the Code Signing Tool (CST), with the following parameters: use an existing CA key: n key type: rsa-pss key length: 4096-bit digest algorithm: sha384 However, the reason I want to sign binaries outside of CST is that I already have an RSA key that is used for signing various other artifacts. When I use this key to sign the various bin files and then try to reintegrate the signed hashes as described in the linked procedure, I get the following error (CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid After double-checking that everything was correct, I also tested verifying my signature using OpenSSL as follows: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK Expected vs actual: since OpenSSL confirms the signature is a valid PSS signature, I expected CST to accept it during reintegration as well. Instead, CST rejects it as invalid. I started digging into the CST source code and found why it was incorrectly reporting the signature as invalid, even though it was successfully verified by OpenSSL. When CST checks the signature, it does the following: Using OpenSSL API calls, it retrieves the "Public Key Algorithm" field from the public key. Based on this field, it uses another OpenSSL API call to essentially ask: "Does the given signature file correspond to the public key algorithm used?" When generating/using what the NXP documentation calls "RSA-PSS" keys, the "Public Key Algorithm" field is equal to rsassaPss and the checks above work correctly. However, when using a generic RSA key, the "Public Key Algorithm" field is equal to rsaEncryption, and CST wrongly assumes this means the signature format is PKCS#1 v1.5, even though it's entirely possible to sign using the PKCS#1 v2.1 (PSS) format. I confirmed this incorrect assumption by hardcoding into the CST source code that my signature was a PSS one, and I was then able to get my signature successfully verified and reinserted by CST into the final binary. It then worked as expected on my closed device. I'm happy to provide more details if needed, especially regarding the various OpenSSL function calls involved. Could you confirm whether this is a known limitation of CST, or if I might be missing something in how I'm generating/using the signature with a generic RSA key? As a side question, I also tried using SPSDK, which seems to be the new tool NXP is promoting for AHAB-based platforms, but I couldn't find a way to export the binaries to be signed, sign them manually, and then reinsert them, similar to the CST procedure. Do you know if this is feasible? Thanks in advance. Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, Actually the document that you are using is correct, is the aproach we suggest for customers that are still using CST. For AHAB, and specially new i.MX9 familly we suggest customers to move to the SPSDK as this is the tool we are using for enablement on security. Even so you can share the steps you have followed and the changes you made to the tool, so I can review and share with internal team if needed. Also, for the SPSDK you may have a look to the following: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html Hope this helps, Best regards/Saludos, Aldo.
View full article
i.MX93 AHAB 安全启动、RSA-PSS 签名和 HSM 模式 你好, 我想报告我在 i.MX93-evk 平台上使用 CST 进行 RSA-PSS 签名验证时遇到的问题,我认为这是一个 bug。下面我将描述我得出这一发现的步骤。 我目前正在 i.MX93-EVK 平台上实施安全启动程序,并已使用 CST v4.0.1 按照标准、有记录的程序成功使其工作。 然后,我想在 CST 之外对各种二进制文件进行签名,直接使用 OpenSSL(注意:这不是 PKCS#11 设置,我只是使用我自己的 RSA 密钥和 OpenSSL CLI/API)。我找到了以下步骤,它恰好描述了我想要实现的目标:在 AHAB 设备中使用 HSM 模式进行代码签名.pdf 这对于使用代码签名工具 (CST) 提供的ahab_pki_tree工具生成的密钥效果很好,参数如下: 使用现有 CA 密钥:否 密钥类型:rsa-pss 密钥长度:4096 位 摘要算法:sha384 但是,我想要在 CST 之外对二进制文件进行签名的原因是,我已经有一个 RSA 密钥,该密钥用于对各种其他工件进行签名。当我使用此密钥对各种 bin 文件进行签名,然后尝试按照链接中的步骤重新集成签名哈希值时,出现以下错误(CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid 在仔细检查确认一切无误后,我还使用 OpenSSL 测试了签名验证,步骤如下: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 预期与实际情况:由于 OpenSSL 确认该签名是有效的 PSS 签名,我预期 CST 在重新集成期间也会接受它。CST 却将其判定为无效并拒绝接受。 我开始深入研究 CST 源代码,并发现了它错误地将签名报告为无效的原因,即使 OpenSSL 已成功验证了该签名。 CST 检查签名时,会执行以下操作: 它使用 OpenSSL API 调用,从公钥中检索“公钥算法”字段。 根据该字段,它使用另一个 OpenSSL API 调用来询问:“给定的签名文件是否与所使用的公钥算法相符?” 当生成/使用 NXP 文档中称为“RSA-PSS”的密钥时,“公钥算法”字段等于rsassaPss ,并且上述检查工作正常。 然而,当使用通用 RSA 密钥时,“公钥算法”字段等于rsaEncryption ,CST 错误地认为这意味着签名格式为 PKCS#1 v1.5,即使完全可以使用 PKCS#1 v2.1 (PSS) 格式进行签名。 我通过在 CST 源代码中硬编码我的签名是 PSS 签名来证实了这个错误的假设,然后我成功地让 CST 验证了我的签名并将其重新插入到最终的二进制文件中。然后它在我的封闭设备上运行正常。 如有需要,我很乐意提供更多细节,特别是关于所涉及的各种 OpenSSL 函数调用。 能否确认这是否是 CST 的已知限制,或者我在使用通用 RSA 密钥生成/使用签名时是否遗漏了某些内容? 另外,我还尝试使用 SPSDK,这似乎是 NXP 为基于 AHAB 的平台推广的新工具,但我找不到导出要签名的二进制文件、手动签名,然后再重新插入的方法,类似于 CST 过程。你知道这是否可行吗? 先行致谢。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode 你好, 实际上,您正在使用的文档是正确的,这是我们建议仍然使用 CST 的客户采用的方法。对于 AHAB,特别是新的 i.MX9 系列,我们建议客户迁移到 SPSDK,因为这是我们用于启用网络安全的工具。 即便如此,您仍然可以分享您遵循的步骤以及您对工具所做的更改,以便我进行审核,并在需要时与内部团队分享。 另外,关于SPSDK,您可以参考以下内容: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html 希望这能帮到你。 此致敬礼/Saludos, 阿尔多。
View full article
ARA240(.dvm)用のカスタムONNX/TFLiteモデルをコンパイルする方法は?(搬送波はi.MX95 FRDMを使用しています) 私はi.MX95 FRDMのARA240 M.2アクセラレータを評価しています。 ランタイムは正常に動作しています。 ARA240はPCIe経由で検出されます。 nnapp は提供された .dvm を正常に実行しますモデル. ランタイムSDKs(rt-sdk-ara240)とPython DVAPIバインディングがインストールされています。 しかし、自分でMobileNetモデルを展開したいのですが、モデルを.dvmにコンパイルするためのツールチェーンが見つかりません形式。 私の質問は以下のとおりです。 カスタムONNX/TFLiteモデルを.dvmにコンパイルする際のサポートワークフローは何ですか?ARA240用ですか? Ara2コンバータ(またはdvconvert/dvnc)は公開されているのか、それともRuntime SDKsとは別に配布されているのか? NXPがサポートするカスタムCNNモデルを展開する方法はありますか(例:MobileNet) を ARA240 に移植する際に、私が見落としている点はありますか? どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) CNNモデルには、公式ウェブサイトからダウンロードできるAra2ランタイムパッケージが役立つかもしれません Ara240のランタイム環境を提供します。Ara240モジュール上で事前コンパイルされたCNNおよびGenAIモデルをダウンロードし実行するためのスクリプトを提供します。ご質問への回答は、下記のAIによる回答をご参照ください。お役に立てれば幸いです。 =========================================================================== まず、重要な背景説明から始めましょう。 ARA240(旧名:キナラ・アラ2).dvm= Kinara DNN 仮想マシンのバイナリモデル、このDNPU用の独自のコンパイルされたグラフ形式。 rt-sdk-ara2 (target runtime + DVAPI) ≠ コンパイラツールチェーン. i.MX95には推論ランタイムのみがインストールされています。オフラインモデルコンパイラは別のソフトウェアです。 1. サポートされているワークフロー: ONNX / TFLite → .dvm 公式なエンドツーエンドの流れ: PyTorch/TensorFlow → ONNX / TFLite → Ara2オフラインコンパイラ(dvconvert / dvnc、Ara2コンバーター) → 量子化(MobileNetのようなCNNではint8推奨) → 最適化された.dvmバイナリ → .dvm を i.MX95 FRDM にデプロイする → PCIe経由でARA240にDVAPI / nnapp / libaraclientをロードして実行する 重要な制約:コンパイルはi.MX95ターゲットボード上で実行できません。 コンパイラはホスト側のLinux x86_64ツールチェーンで、外部のPC/ワークステーション上で実行されます。 2. dvconvert / Ara2 Converterは公開されているのでしょうか? いいえ。コンバーターは一般にダウンロードできません。 NXP GitHubでホストされているrt-sdk-ara2 Debianパッケージには、ターゲットランタイム、DVAPI Pythonバインディング、事前構築済みのデモ.dvmのみが含まれていますモデル.コンパイラバイナリは含まれていません。 Ara2コンパイラスイート(dvconvert、dvnc)はNXPの制限付きソフトウェアアクセスのもとで別途配布されています。 このツールチェーンはキナラに起源を持ち、NXPがキナラを買収した後は、NXPの営業/CAS(お客様アプリケーションサポート)を通じてアクセス管理が行われました。 3. NXPが公式にサポートするカスタムCNN(MobileNet)の導入方法はありますか? はい、ただしAra SDKコンパイラへのアクセスを正式に申請する必要があります: コンバータを入手するための公式なルート お近くのNXP FAE / NXP CASサポートチケットにお問い合わせください: ハードウェア: FRDM i.MX95 + ARA240 M.2 DNPU リクエスト:カスタムONNX/TFLite CNNコンパイルを.dvmにするためのAra SDKオフラインモデルコンパイラ(dvconvert)へのアクセス 制限付きAraツールについてはNXPのソフトウェアライセンス契約に署名する必要があります。 NXPは当初、更新されたeIQ Toolkit(2026年中頃予定)と並行してより広範なリリースを計画していました。現在はサポートされている評価お客様向けにゲートされています。 ツールアクセスを待つ間の回避策と代替案 カスタム.dvmは生成できませんdvconvertを使用せずにローカルで実行します。ARA240.dvm用のオープンソースのサードパーティ製コンバーターは存在しません。 オプションA:早期アクセス評価の一環としてNXPのエンジニアリングサポートにモデルコンパイルを依頼する。 オプションB:一時的にワークロードを分散:未コンパイルのONNXをi.MX95オンボードeIQ Neutron上で実行し、Araコンパイラへのアクセスを待つ間に実行します(これはARA240へのオフロードなし)。 注意:i.MX95の内蔵Neutron NPU(.neutronモデル)と外部のARA240 DNPU(.dvm)を混同しないでください。彼らは完全に互換性のないバイナリフォーマットを使っています。 4. 避けるべき主な落とし穴 rt-sdk-ara2内にはPaddle2ONNX / ONNXコンバーターユーティリティはありません。 事前に構築されたデモ用.dvmファイルSDKに付属して配布されたファイルは、変換ロジックを抽出するためにリバースエンジニアリングすることはできません。 現在、ARA240用のウェブベースのモデルコンバーターは利用できません。 MobileNet v1/v2は、ツールチェーンを入手すればdvconvertによって完全にサポートされるアーキテクチャです。ONNXがクリーンアップされていることを確認してください(未使用のノードを削除し、入力形状を固定し、標準演算のみを使用する)。 NXPサポートチケットに直接送る提案文言 FRDM i.MX95上でARA240 M.2モジュールを評価しています。PCIe列挙、サンプル.dvmを提供実行、rt-sdk-ara2、DVAPIは機能します。カスタムMobileNet ONNXモデルを.dvmにコンパイルするには、Ara2オフラインコンパイラ(dvconvert/dvnc)へのアクセスが必要ですバイナリ。ホスト側のAra SDKモデル変換ツールチェーンを取得する手順を共有してください。
View full article
IMX95EVKのM7コアにおけるフラッシュの問題 こんにちは、 IMX95LPD5EVK-19 follow AN14748 でM7アプリケーションを実行しようとしていますが、フラッシュできません flash.binUUUと共に。ボードは短時間検出されるが、その後すぐにSDPSの起動に失敗する。 ハードウェア: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) ブートスイッチ(SW7[1:4]): 1001(シリアルダウンロード) ターゲット: eMMC ホスト: Ubuntu Linux うーん: libuuu_1.5.243-0-g230f1b1 試したSDKs(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 どちらも同じ結果を生み出す。 コマンド: CD IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo ううう -b emmc flash.bin   エラー: 成功 0 失敗 1 1:2-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   実施された手順(AN14748に基づく): ボードの電源をオフにした状態で、SW7を1001に設定します。 USBをホストに接続します 走る sudo uuu -b emmc flash.bin 電源サイクルボード SDPSの起動に毎回失敗する このバージョンのボードにおけるM7コアのフラッシュ手順とサポートされているBSPバージョンを教えてください。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 A1版向けに最新サポートされているBSPはLinux 6.12.20です。 また、バイナリ全体を一から作るのも手です(Uboot+SPL+ATF+Firmware+M-SDK)。 #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### あなたの場合は、サポートされている最新のBSPバージョンに注意してください。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ CD Uboot-IMX $ make -j $(nproc --all) きれいに $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ CD ... $ CD IMX-ATF $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ CD ... $ CD IMX-SM $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg(関連するmx95evk.cfgファイルが変更されている場合は任意) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (i.MX 95 A1 のみ) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --車載承認 $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --自動承認 #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit(これで端末が閉鎖されるSO、再開してください) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 生成されたバイナリを使用してEVKをフラッシュすることができます。スタンドアロンモードでテストしたところ、正常に動作しました。 よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core クイックスタートガイドによると、EMMCからブートする場合、SW7-3は1になるはずです。 IMX95LPD5EVK-19
View full article
lx2080(yocto镜像和调试) 我需要了解如何使用 Yocto 配置 LX2080A NXP 镜像版本,以及如果要使用自定义板卡,应该如何进行更改。 Re: lx2080(yocto image and debug) Layerscape Yocto 电路板支持包。 v26.06: 该版本包含源代码和预编译镜像,具体内容如下: 源代码版本文件位于https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk 分支: walnascar-lsdk Linux BSP 支持的开发板、功能、已知问题,请参阅版本说明 Layerscape Yocto软件开发工具包用户指南: UG10374.pdf Layerscape Linux SDK 用户指南: UG10381.pdf 请修改 RCW、u-boot、ATF 和 Linux dts 以适应您的定制板,并重新构建镜像。 移植步骤: 修改 rcw 并重新构建 rcw: $ bitbake rcw -c patch -f 请打开 rcw 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/,并根据您的自定义板修改 XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw。 $ bitbake rcw 修改并重新编译 u-启动: $ bitbake u-启动 -c patch -f 请进入 u-启动 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/,根据您的定制板修改 u-启动 源代码。 $ bitbake u-boot 修改并重新构建 atf: $ bitbake qoriq-atf -c patch -f 请前往 atf 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/,请根据您的定制板修改 atf 源代码。 $ bitbake qoriq-atf 修改Linux dts文件并重新构建Linux内核: $ bitbake virtual/kernel -c patch -f 请进入 Linux 内核文件夹 build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git,请根据定制板修改 dts 文件 arch/arm64/启动/dts/freescale/fsl-lx2160a-rdb.dts。 $ bitbake 虚拟/内核
View full article
How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) I'm evaluating the ARA240 M.2 accelerator on the i.MX95 FRDM. The runtime is working correctly: ARA240 is detected over PCIe. nnapp successfully runs the provided .dvm models. The Runtime SDK (rt-sdk-ara240) and Python DVAPI bindings are installed. However, I would like to deploy my own MobileNet model, and I'm unable to find the toolchain required to compile models into the .dvm format. My questions are: What is the supported workflow to compile a custom ONNX/TFLite model into .dvm for ARA240? Is the Ara2 Converter (or dvconvert/dvnc) publicly available, or is it distributed separately from the Runtime SDK? Is there an NXP-supported way to deploy custom CNN models (e.g. MobileNet) onto ARA240, that I am missing? Any guidance or documentation would be greatly appreciated. Thanks! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) For CNN model,Ara2 Runtime Package could be helpful which can downloaded from the official website Provides a runtime environment for Ara240.Provides scripts to download and run pre-compiled CNN and GenAI models on Ara240 modules. For your question, please refer to the AI generated answer as below, hope it helps  =========================================================================== First, critical background: ARA240 (formerly Kinara Ara-2) .dvm = Kinara DNN Virtual Machine binary model, proprietary compiled graph format for this DNPU. rt-sdk-ara2 (target runtime + DVAPI) ≠ compiler toolchain. You have only the inference runtime installed on i.MX95; the offline model compiler is separate software. 1. Supported workflow: ONNX / TFLite → .dvm Official end-to-end flow: PyTorch/TensorFlow → ONNX / TFLite → Ara2 Offline Compiler (dvconvert / dvnc, Ara2 Converter) → Quantization (int8 preferred for CNN like MobileNet) → Optimized .dvm binary → Deploy .dvm to i.MX95 FRDM → Load & run via DVAPI / nnapp / libaraclient over PCIe to ARA240 Important constraint: Compilation cannot run on the i.MX95 target board. The compiler is a host-side Linux x86_64 toolchain, executed on an external PC/workstation. 2. Is dvconvert / Ara2 Converter public? NO. The converter is NOT publicly downloadable. The rt-sdk-ara2 Debian packages hosted on NXP GitHub only contain target runtime, DVAPI Python bindings, prebuilt demo .dvm models. No compiler binaries included. The Ara2 compiler suite (dvconvert, dvnc) is distributed separately under NXP restricted software access. This toolchain originated from Kinara; after NXP acquired Kinara, access is managed via NXP sales / CAS (Customer Application Support). 3. Is there an official NXP-supported path to deploy custom CNN (MobileNet)? Yes, but you need to formally request access to the Ara SDK compiler: Official route to obtain the converter Contact your local NXP FAE / NXP CAS support ticket referencing: Hardware: FRDM i.MX95 + ARA240 M.2 DNPU Request: Access to Ara SDK offline model compiler (dvconvert) for custom ONNX/TFLite CNN compilation to .dvm You will need to sign NXP’s software license agreement for restricted Ara tooling. NXP originally planned wider release alongside updated eIQ Toolkit (previously scheduled mid-2026); at present, it remains gated to supported evaluation customers. Workarounds & alternatives while waiting for tool access You cannot generate custom .dvm locally without dvconvert. There is no open-source third-party converter for ARA240 .dvm. Option A: Ask NXP engineering support to perform model compilation as part of your early access evaluation. Option B: Split workload temporarily: run uncompiled ONNX via CPU/Neutron NPU on i.MX95 onboard eIQ Neutron while waiting for Ara compiler access (this does not offload to ARA240). Note: Do not confuse i.MX95’s built-in Neutron NPU (.neutron model) with external ARA240 DNPU (.dvm). They use completely incompatible binary formats. 4. Key pitfalls to avoid There is no Paddle2ONNX / ONNX converter utility inside rt-sdk-ara2. Prebuilt demo .dvm files distributed with the SDK cannot be reverse-engineered to extract conversion logic. No web-based model converter available for ARA240 today. MobileNet v1/v2 are fully supported architectures by dvconvert once you receive the toolchain; ensure ONNX is cleaned (remove unused nodes, fixed input shape, standard ops only). Suggested wording you can directly send to NXP support ticket We are evaluating ARA240 M.2 module on FRDM i.MX95. PCIe enumeration, provided sample .dvm execution, rt-sdk-ara2 and DVAPI are functional. We require access to the Ara2 offline compiler (dvconvert/dvnc) to compile custom MobileNet ONNX models into .dvm binaries. Please share procedure to obtain the host-side Ara SDK model conversion toolchain.
View full article
如何为 ARA240 (.dvm) 编译自定义 ONNX/TFLite 模型?(载板型号为 i.MX95 FRDM) 我正在评估 i.MX95 FRDM 上的 ARA240 M.2 加速器。 运行时运行正常: 通过 PCIe 检测到 ARA240。 nnapp 成功运行提供的 .dvm 文件模型。 已安装运行时 SDK (rt-sdk-ara240) 和 Python DVAPI 绑定。 但是,我想部署我自己的 MobileNet 模型,却找不到将模型编译成 .dvm 文件所需的工具链。格式。 我的问题是: 将自定义 ONNX/TFLite 模型编译成 .dvm 文件的受支持工作流程是什么?适用于 ARA240? Ara2 变流器(或 dvconvert/dvnc)是公开提供的,还是与运行时 SDK 分开分发的? NXP 是否支持部署自定义 CNN 模型(例如)MobileNet) 到 ARA240,我漏掉了什么吗? 任何指导或文件都将不胜感激。 谢谢您! Re: How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) 对于 CNN 模型,Ara2 运行时代码包,软件包可能很有帮助,可以从官方网站下载。 为 Ara240 提供运行时环境。提供脚本以下载并在 Ara240 模块上运行预编译的 CNN 和 GenAI 模型。关于您的问题,请参考下方人工智能生成的答案,希望对您有所帮助。 =========================================================================== 首先,需要一些关键背景信息: ARA240(原名 Kinara Ara-2).dvm= Kinara DNN 虚拟机二进制模型,此 DNPU 的专有编译图格式。 rt-sdk-ara2(目标运行时 + DVAPI)≠ 编译器工具链。 i.MX95 上只安装了推理运行时;离线模型编译器是单独的软件。 1. 支持的工作流程:ONNX / TFLite → .dvm 官方端到端流程: PyTorch/TensorFlow → ONNX / TFLite → Ara2 离线编译器(dvconvert / dvnc,Ara2 变流器) → 量化(对于像 MobileNet 这样的 CNN,首选 int8) → 优化后的 .dvm二进制 → 将 .dvm 文件部署到 i.MX95 FRDM → 通过 PCIe 经由 DVAPI / nnapp / libaraclient 加载并运行至 ARA240 重要限制:编译无法在 i.MX95 目标板上运行。 该编译器是主机端 Linux x86_64 工具链,在外部 PC/工作站上执行。 2. dvconvert / Ara2 变流器 是公开的吗? 不。该变流器不可公开下载。 NXP GitHub 上托管的 rt-sdk-ara2 Debian 软件包仅包含目标运行时、DVAPI Python 绑定和预构建的演示 .dvm 文件。模型。不包含编译器二进制文件。 Ara2 编译器套件(dvconvert、dvnc)根据 NXP 限制软件访问权限单独分发。 该工具链源自 Kinara;NXP 收购 Kinara 后,访问权限由 NXP 销售/CAS(客户应用支持)管理。 3. NXP 是否有官方支持的途径来部署自定义 CNN(MobileNet)? 是的,但您需要正式申请访问 Ara SDK 编译器: 获取变流器的官方途径 请联系您当地的 NXP FAE / NXP CAS 支持团队,并参考,引用: 硬件:FRDM i.MX95 + ARA240 M.2 DNPU 请求:提供 Ara SDK 离线模型编译器 (dvconvert) 的访问权限,以便将自定义 ONNX/TFLite CNN 文件编译为 .dvm 文件。 您需要签署 NXP 的受限 Ara 工具软件许可协议。 NXP 最初计划与更新后的 eIQ Toolkit(原计划于 2026 年年中发布)一同进行更广泛的版本;目前,它仍然只对受支持的评估客户开放。 等待工具访问期间的变通方法和替代方案 您无法生成自定义 .dvm 文件。本地不使用 dvconvert。目前没有适用于 ARA240 .dvm 的开源第三方变流器。 方案 A:请 NXP 工程支持部门执行模型编译,作为您早期访问评估的一部分。 选项 B:暂时拆分工作负载:在等待 Ara 编译器访问期间,通过 i.MX95 板载 eIQ Neutron 上的 CPU/Neutron NPU 运行未编译的 ONNX(这不会卸载到 ARA240)。 注意:不要将 i.MX95 内置的 Neutron NPU(.neutron 型号)与外部 ARA240 DNPU(.dvm)混淆。它们使用完全不兼容的二进制格式。 4. 需要避免的关键陷阱 rt-sdk-ara2 中没有 Paddle2ONNX / ONNX 变流器实用程序。 预构建演示 .dvmSDK 中分发的文件无法通过逆向工程提取转换逻辑。 目前还没有适用于 ARA240 的基于网络的模型变流器。 一旦您收到工具链,dvconvert 将完全支持 MobileNet v1/v2 架构;确保 ONNX 已清理(删除未使用的节点、固定输入形状、仅使用标准操作)。 您可以直接将以下措辞发送给恩智浦技术支持工单。 我们正在对 FRDM i.MX95 上的 ARA240 M.2 模块进行评估。PCIe 枚举,提供示例 .dvm执行方面,rt-sdk-ara2 和 DVAPI 功能正常。我们需要访问 Ara2 离线编译器 (dvconvert/dvnc) 来将自定义 MobileNet ONNX 模型编译成 .dvm 文件。二进制.请分享获取主机端 Ara SDK 模型转换工具链的步骤。
View full article
LX2080(Yoctoイメージとデバッグ) YOCTOを使ってLX2080a NXPイメージビルドの設定方法や、カスタムBORDを使いたい場合は変更方法について情報が欲しいです Re: lx2080(yocto image and debug) Layerscape Yocto BSP v26.06: 今回のリリースには、以下に示すソースコードとビルド済みイメージの両方が含まれています。 ソースリリースファイルは、 https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdkにあります。 ブランチ: walnascar-lsdk Linux BSP対応の基板、機能、既知の問題については、リリースノートをご参照ください Yocto用レイヤースケープソフトウェア開発キットユーザーガイド: UG10374.pdf Layerscape Linux SDK ユーザーガイド: UG10381.pdf カスタムボード用にRCW、u-boot、ATF、Linux dtsを改造し、イメージを再構築してください。 移植手順: rcwを変更し、rcwを再構築する: $ bitbake rcw -c patch -f rcwのソースコードフォルダbuild_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/git/lx2160ardb_rev2/を選び、カスタムボードに合わせてXGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcwを修正してください。 $ bitbake rcw u-bootを修正して再構築する: $ bitbake u-boot -c patch -f you-bootのソースコードフォルダ build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/にアクセスし、カスタムボードに合わせてu-bootのソースコードを修正してください。 $ bitbake u-boot atfを修正および再構築する: $ bitbake qoriq-atf -c patch -f atfのソースコードフォルダ build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/にアクセスしてください。カスタムボードに合わせてatfのソースコードを修正してください。 $ bitbake qoriq-atf Linux dts ファイルを修正し、Linux カーネルを再構築する: $ bitbake virtual/kernel -c patch -f Linux Kernelフォルダ build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git にアクセスしてください。カスタムボードに合わせてdtsファイルarch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dtsを修正してください。 $ bitbake virtual/kernel
View full article
Create a new model and configure it for NXP Hardware 1 Table of Contents • Introduction • Prerequisites • Creating a New Simulink Model • Configure the Model for NXP Hardware • Add Simulink Blocks • Build the Model • Flash and Run on Hardware • References • Conclusion 2 Introduction Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects. 3 Prerequisites Before starting, ensure the following tools are installed and correctly configured: MATLAB & Simulink NXP MBDT S32 Design Studio / EB tresos NXP RTD drivers USB / JTAG debugger (e.g., PEMicro) Target hardware (e.g., S32K344, S32K358) In addition to having the required tools installed, it is important to ensure that all components are properly integrated and compatible with each other. This includes matching the MATLAB/Simulink version with the supported release of the NXP MBDT, as well as aligning the RTD package with the selected microcontroller and AUTOSAR version. Environment variables, compiler paths, and licensing (for MATLAB, Simulink, and EB tresos) should also be verified prior to starting development. From a hardware perspective, make sure that the evaluation board or target ECU is correctly powered and that the debug interface (such as PEMicro) is functioning. Installing the appropriate USB drivers and checking connection through debug tools can prevent communication issues later in the workflow. Finally, it is recommended to validate the toolchain setup by running a simple example, such as a GPIO toggle or LED blink application, either directly in S32DS or through an existing Simulink example provided by MBDT. This step helps confirm that code generation, compilation, flashing, and execution on the target hardware are all working correctly before moving on to a more complex development. 4 Creating a New Simulink Model Step 1: Launch Simulink Open MATLAB Type simulink in the command window Select Blank Model Step 2: Save the Model Save with a clear naming convention, e.g. s32k344_led_blink.mdl 5 Configure the Model for NXP Hardware Step 3: Open Model Configuration Parameters Navigate to Model Settings ( Ctrl + E ) → Hardware Implementation Step 4: Select Hardware Board Set Hardware board to the appropriate NXP target For example, NXP S32Kxx Step 5: Select a Configuration Template Set Configuration Project Template to the appropriate NXP target For example, S32K344-Q172 S32 Config Tool If the board is not visible, ensure MBDT is properly installed. 6 Add Simulink Blocks Using the Library Browser, configure hardware peripherals. Step 6: Configure GPIO for LED Add a Dio block Configure: Function: Dio_FlipChannel Channel: e.g. DioLed0 Step 7: Add Level Variable Add Data Store Memory and Data Store Write blocks Connect the Dio block to the Data Store Write This will blink an LED because the Dio_FlipChannel function toggles the logical state of the selected GPIO pin every time it is executed. By connecting it to a Data Store Write, you are effectively allowing the system to store or propagate the updated state within the model. The blinking frequency is directly controlled by the task rate of your model, which makes it easy to adjust the LED behavior simply by changing the sample time, without modifying the core logic. In the Library Browser you will find numerous example projects that may be helpful (for example, s32k3xx_dio_s32ct ). 7 Build the Model Step 8: Generate Code Click Build Model ( Ctrl + B ) When you press the build button, Simulink automatically translates your model into C code and prepares it for execution on the target microcontroller. The generated files can be found in the project folder, where you can explore how each block was converted into embedded code. After generation, the toolchain creates an executable file and attempts to deploy it directly to the target board. 8 Flash and Run on Hardware Step 9: Connect Target Board Connect via debugger (USB / JTAG) Step 10: Deploy From Simulink (External Mode or Build & Deploy) Or manually via S32 Design Studio 9 References Quick Start Guide for S32K3X4EVB Board Model-Based Design Toolbox (MBDT) – How To 10 Conclusion Creating a new model and configuring it for NXP hardware involves: Setting up the Simulink model Configuring hardware-specific parameters Adding peripheral blocks Generating and deploying embedded code This workflow enables rapid prototyping and production-ready embedded development, especially in automotive systems leveraging AUTOSAR and NXP platforms. Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—often involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and AUTOSAR tools like EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects.
View full article
Functional Safety in Motor Control with AMMCLib and ASCLib When developing motor control for automotive and industrial systems, functional safety is a core requirement to ensure a motor does not produce unintended torque or speed. However, implementing complex algorithms like Field-Oriented Control (FOC) as a functionally safe component introduces severe architectural complexity, significantly increases development effort, and degrades overall performance. To solve this, NXP utilizes a safety decomposition approach that divides the application into a non-safety-related part (QM) and a safety-related part (ASIL). For this approach, NXP plans to provide the Automotive Safety Checker Library (ASCLib), which delivers ready-to-use safety checkers for the safety part. This enables high safety compliance without requiring a redesign of the QM motor control (MC) part. The Perfect Match: AMMCLib (QM) + ASCLib (ASIL) Many applications use highly optimized NXP's Automotive Math and Motor Control Library (AMMCLib) for the motor control part. While AMMCLib delivers exceptional performance, it is a Quality Management (QM) level library. Compliance with safety standards (such as ISO 26262) required teams to build custom safety mechanisms around the QM-level AMMCLib, consuming significant time and effort. NXP's ASCLib solves this by providing standardized, production-ready safety checkers. This eliminates proprietary safety software development and significantly reduces time-to-certification. How AMMCLib and ASCLib Fit Together The block diagram below illustrates a standard FOC system using this concept. The blue motor control blocks represents the QM-level AMMCLib functions, while the green blocks represent the ASCLib checkers that monitor key points to ensure safety. This architecture is based on the IEEE Low Complexity Safety Concept for FOC PMSM. This reference architecture shows that integrating ASCLib requires no changes to the existing QM motor control architecture. Full data-type compatibility allows ASCLib checkers to map directly to AMMCLib signals, ensuring seamless interconnection. The architecture assumes that Freedom from Interference (FFI) between the safety-related and QM software components is ensured. While standard FOC is a common use case, ASCLib is not limited to it. Thanks to its modular, independent blocks, the library supports alternative topologies and advanced techniques - including sensorless FOC and single-shunt current measurement. Inside ASCLib: A Layered Safety Architecture The ASCLib features a highly structured, layered software model organized hierarchically into Layers and Packages: The Service Layer (Top Layer) Exposes high-level functionalities directly to the safety application through two independent packages: High-Level Checkers (HLC): Wide range of application-level safety checkers tailored for various motor control systems. Fault Manager (FMG): Sophisticated fault-handling component managing error synchronization, configuration, and application notifications. The Core Layer (Foundational Layer) Provides the low-level building blocks utilized by the Service Layer. It consists of two essential packages: Low-Level Checkers (LLC): Delivers fundamental mathematical and verification functions. Fault-Debouncing (FDB): Provides generic fault debouncing algorithms. Developer Tip: The entire library is fully modular, isolated, and independent. If your application requires a unique checker, you can easily build your own custom checkers using the existing low-level blocks inside the LLC and FDB packages. Furthermore, the Fault Management (FMG) package is entirely optional—you are not forced to use it and can implement your own application-level error handling instead.   Not Just For Automotive Don't let the name fool you. While ASCLib has "Automotive" in its title and natively supports ISO 26262 workflows, its safety principles are universal. ASCLib applies perfectly to industrial systems complying with IEC 61508. To fit seamlessly into your existing development workflow, ASCLib features a dual-delivery option: Pure C Source Files: For direct integration into any bare-metal or RTOS-based embedded project. BAM (Bit Accurate Models): Ready-to-use blocks for Model-Based Design (MBD), allowing you to drag, drop, and simulate your safety architecture directly in MATLAB®/Simulink®. Key Benefits for Developers AMMCLib Remains QM: Keep using your existing, highly optimized AMMCLib code for core motor control. Model-Based development: Accelerate your design cycle by building and simulating your entire safety part using dedicated ASCLib BAM directly in MATLAB®/Simulink® before generating target C code. Accelerated Certification: Pre-designed safety checkers and integrated fault management significantly simplify your safety compliance and auditing processes. Get Started and Share Your Thoughts ASCLib is designed to be completely MCU-independent, giving you the flexibility to deploy it across various NXP hardware platforms. To accelerate your development, it is planned to be fully verified and ready to integrate with NXP’s automotive and industrial MCUs. By separating control from safety, you get the best of both worlds: maximum motor performance and uncompromising safety. Working on an upcoming ISO 26262 or IEC 61508 motor control project? Let’s discuss in the comments how the AMMCLib + ASCLib approach can simplify your design. We would also highly appreciate it if you could take a moment to fill out our quick survey below to share your insights with us! This project has received national funding from the MEYS and the funding from European Union’s Horizon Europe research and innovation framework programme under grant agreement No. 101112274. The ISOLDE project, nr. 101112274 is supported by the Chips Joint Undertaking and its members Austria, Czechia, France, Germany, Italy, Romania, Spain, Sweden, Switzerland. Building functionally safe motor control systems doesn’t have to mean sacrificing performance or redesigning your architecture. Discover how NXP combines AMMCLib and ASCLib to separate safety from motor control, reduce development effort, and accelerate certification—without compromising efficiency. Motor Control
View full article
FS26 LDO Off Issue Hello I am using the FS26 and S32K358. I am using the FS26's VLDO2 as the power supply for the MCU and the FS26's VLDO1 as the power supply for the CAN transceiver. When the MCU is left in a state of CAN communication, the FS26's VLDO turns OFF, cutting off the MCU's power. (This occurs randomly, approximately every 1 to 8 hours.) The VLDO is restored only after the FS26's power supply is cut off and then restored. This issue occurs on all boards, not just a single one, and does not occur when CAN communication is not in progress. The status when the issue occurs is as follows: Vpre 6V O VDIG 1.6V O VBOS 5V O VLDO2 X VLDO1 X VCORE X DFS is disabled via OTP. I would like to know the current state of the FS26 and what causes this to happen. Re: FS26 LDO Off Issue Hello kjy106906  Good day! Is the watchdog enabled? What are the values of: FS_STATES FS_GRL_FLAGS FS_OVUV_REG_STATUS M_REG_FLG M_STATUS immediately after failure? Have you checked if FS26 is not displaying any UV or OV flags? Also could you share your M_STATUS? I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: FS26 LDO Off Issue @RafaR  Thank you for the reply. Unfortunately, the MCU is receiving power from the SBC, but communication is not possible because the VLDO is OFF. You must cut off and resupplied the board power for the MCU to function. The watchdog window is infinite. Re: FS26 LDO Off Issue Hello kjy106906 Good day! Looks as if the FS26 analog front end is still powered, but the internal power-tree supplying the system has been disabled. One possible explanation is that a fault has been detected on one of the monitored regulators (VCORE, VLDO1, VLDO2), and the configured reaction disables the regulator outputs. FS26 documentation indicates that regulators can remain disabled after a fault depending on the configured fault-reaction settings. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: FS26 LDO Off Issue Please refer to PMIC initiailization process for debug. AN13431 NXP PMIC solution for TI TMS570 series MCU should be helpful Re: FS26 LDO Off Issue Thank you @RafaR  This is an important issue, so I would appreciate your response. I would like to check exactly what state FS26 is in and why it failed. When the issue occurred, I read the registers using an external tool. FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MIRRORCMD:0x1c]W:0x001d; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MIRRORDATA:0x1d]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [ID_VOTP:0x1D]R:0x00 FS26 [FS_WDW_DURATION:0x0b]W:0xd08b; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_NOT_WDW_DURATION:0x0c]W:0x2f74; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_FLG:0x07]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_MSK:0x08]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_FLG:0x05]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_MSK:0x06]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_FLG:0x03]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_MSK:0x04]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_FLG:0x09]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_MSK:0x0a]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_STATUS:0x02]R:0x5020; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_FLG:0x0b]R:0x0005; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_MSK:0x0c]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_OVUV_REG_STATUS:0x10]R:0x1544; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_INTB_MASK:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY1:0x14]R:0x03c3; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY2:0x15]R:0x0010; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_1:0x12]R:0xf000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_GRL_FLAGS:0x00]R:0x5000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_DEVICEID:0x00]R:0x65d8; CRC[MOSI:0x00; MISO:0x00] FS26 [M_PROGID:0x01]R:0x0105; CRC[MOSI:0x00; MISO:0x00] FS26 [M_STATUS:0x02]R:0x5020; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_FLG:0x03]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_MSK:0x04]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_FLG:0x05]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_MSK:0x06]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_FLG:0x07]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_VSUP_MSK:0x08]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_FLG:0x09]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_MSK:0x0a]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_FLG:0x0b]R:0x0005; CRC[MOSI:0x00; MISO:0x00] FS26 [M_COM_MSK:0x0c]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_SYS_CFG:0x0d]R:0x0001; CRC[MOSI:0x00; MISO:0x00] FS26 [M_TSD_CFG:0x0e]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_CFG:0x0f]R:0x0002; CRC[MOSI:0x00; MISO:0x00] FS26 [M_WIO_CFG:0x10]R:0x0202; CRC[MOSI:0x00; MISO:0x00] FS26 [M_REG_CTRL1:0x11]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_AMUX_CTRL:0x13]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG1:0x14]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG2:0x15]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CFG3:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_LDT_CTRL:0x17]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MEMORY0:0x18]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [M_MEMORY1:0x19]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_GRL_FLAGS:0x00]R:0x5000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_WDW_DURATION:0x0b]R:0xd08b; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_NOT_WDW_DURATION:0x0c]R:0x2144; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_WD_TOKEN:0x0e]R:0x5ab2; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_ABIST_ON_DEMAND:0x0f]R:0x0040; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_OVUV_REG_STATUS:0x10]R:0x1544; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_1:0x12]R:0xf000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_SAFE_IOS_2:0x13]R:0x035f; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY1:0x14]R:0x03c3; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_DIAG_SAFETY2:0x15]R:0x0010; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_INTB_MASK:0x16]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_STATES:0x17]R:0x0009; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_LP_REQ:0x18]R:0x0000; CRC[MOSI:0x00; MISO:0x00] FS26 [FS_LDT_LPSEL:0x19]R:0x0000; CRC[MOSI:0x00; MISO:0x00] I am attaching the waveform when an issue occurs. Blue VSUP / Red VBOS / Green RSTB / Yellow VDIG Blue VSUP / Red VPre / Green Vcore / Yellow RSTB
View full article
T1024 QorIQ Bare-Metal BSP for CodeWarrior PA10.5 We need official QorIQ T10xx bare-metal BSP package matching CodeWarrior Power Architecture v10.5. Required content: 1. Complete bare-metal startup BSP for T1024 2. RCW, reset, L1/L2 cache, DDR, interrupt, PCIe low-level driver source 3. CodeWarrior PA10.5 stationary project templates 4. Reference bare-metal demo project for T10xx RDB board Background: We are developing bare-metal firmware on T1024 using CodeWarrior PA10.5, LSDK 2.0 Linux SDK only provides U-Boot & Linux source, missing official CodeWarrior bare-metal BSP. Please provide the official BSP archive or download link. Thanks. Re: T1024 QorIQ Bare-Metal BSP for CodeWarrior PA10.5 We don't have Bare-Metal BSP for T1024 platform. You could require NetComm software for other platform to have reference. https://www.nxp.com.cn/products/processors-and-microcontrollers/power-architecture/qoriq-communication-processors/p-series/netcomm-software-resources:NetComm_Software
View full article
GUI Guider 2.0におけるSpangroupウィジェットの利用可能性とFUTUREロードマップに関する問い合わせ こんにちは、NXPコミュニティの皆さん、 現在、プロジェクト開発においてGUI Guider 2.0を使用しています。 バージョン2.0への移行中に、以前のGUI Guider 1.xで利用可能だったSpangroupウィジェットが削除されていることに気づきました。基盤となるLVGLライブラリは依然としてSpangroupをサポートしているため、最新リリースでこの欠落がなぜか気になりました。 このウィジェットはUIデザインに非常に役立ちました。ぜひ教えていただけませんか: 今後のGUI Guiderのリリースで、Spangroupウィジェットを再導入する予定はありますか? もしSOなら、次のリリーススケジュールの大まかなスケジュールやロードマップを共有してもらえますか? この件に関して何かご意見やご助言をいただければ大変ありがたいです。 サポートありがとうございます! よろしくお願いいたします。 Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap こんにちは、 @mastergbc さん、 既にGUI Guider開発チームに評価を依頼しており、進展があれば随時ご報告いたします。 その間、実用的な回避策としては、主要なUI設計とコード生成にはGUI Guider 2.0を使用し、必要なLVGLネイティブspangroup実装を手動で生成プロジェクトに追加することです。 GUI Guiderウィジェットパレットに直接公開されていないLVGL機能については、カスタムコードで統合できます。 お役に立てば幸いです。 BR セレステ Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap 最新情報のご提供ありがとうございます。 私たちのユースケースについて少し説明すると、プロジェクトでは Spangroup ウィジェットを使って異なるフォントスタイルや言語をシームレスに混ぜ、特に英語と韓国語のフォントを1つのテキストブロック内で混同しています。 現在、Spangroupを使用して構築されたUIオブジェクトは約12個あります。このウィジェットは、先行する子要素のテキストや長さが変更された場合、後続の子要素のテキストが自動的に再配置され、整列を維持しながらスムーズに折り返されるため、非常に重要な役割を果たしています。 GUI GuiderでSpangroupウィジェットを再実装する長期的な計画がない場合、このマルチフォント/マルチスタイルのテキスト巻き取り動作を実現するための推奨の代替案や回避策をご提案いただけますか? ご協力いただき、改めて感謝申し上げます。 よろしくお願いいたします。 Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap こんにちは、 @mastergbc さん、 投稿ありがとうございます。 現在、 SpanGroupウィジェット はGUI Guider 2.0で利用可能ではなく、近い将来に追加する計画もありません。 しかし、お客様の要望をよりよく理解し、要望を評価したいと考えています。SpanGroup Widgetで達成しようとしている機能について、もう少し詳しく教えていただけますか?例えば、具体的なユースケース、期待される動作、使用頻度、そしてこの機能がプロジェクトにとってどれほど重要かなどです。この情報は、リクエストを評価し、必要に応じてGui-Guiderチームに転送するのに役立ちます。 さらに、現在どの製品を使っているのか(MCUかMPUモデルか)教えていただけますか?これにより、あなたのアプリケーション状況をよりよく理解できます。 良い1日を。 BR セレステ
View full article
Support Period for Yocto Linux BSP Hello, Could you please provide information regarding the following? We are planning to use the Yocto Linux BSP provided by NXP for a board based on the i.MX 8M Plus. Could you please answer the following questions regarding the BSP? 1. How long are updates provided after a BSP is released? 2. When a new Yocto LTS release becomes available, how long does it typically take for the BSP to be updated to incorporate the new Yocto LTS version? 3. We understand that security updates are available through "BSP Lifecycle Maintenance: Keeping Your Linux® BSP Secure." Could you please let us know: - the maximum support period available, and - the approximate cost of this service? Thank you for your support. We look forward to your response. Best regards,
View full article
使用软件1.9.1时无法添加新图片(无法添加图片) 前几天我使用它的时候,像往常一样添加了新的图片(PNG 格式),但是加载时间很长,而且在那段时间里我无法使用其他功能。见图2。 关闭并重新启动软件后,我发现之前上传的图库中的所有图片都消失了,而且我也无法上传新图片。见图1。 当我在某次使用的时候,像往常一样添加新的图片(PNG格式),却加载了很久,期间也无法使用其他功能。请看图二 当我把软件关闭重启后,发现之前上传的图片库里面的图片全部丢失了,而且也无法上传新的图片。请看图一
View full article
MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 我正在使用MCUXpresso IDE v25.6.136开发FRDM-IMXRT1186,从官网下载最新的IDE安装之后,安装最新的SDK(26.06),导入一个frdmimxrt1186_rled_blinky_cm7示例工程之后点击mex无法打开,于是我升级了配置工具,这时mex文件可以打开了,但是点击调试无法连接到开发板,如图所示,怎么办? (已经尝试升级linkserver版本,没用) #FRDM-IMXRT1186 #MIMXRT1180 MCUXpresso-IDE  LINKERSERVER  回复: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 感谢来信。 请您在 MCUXpresso IDE 的 Preferences → MCUXpresso IDE → Debug Options → LinkServer Options 中确认当前 IDE 实际使用的 LinkServer 路径。 请进入该路径对应的 LinkServer 安装目录,执行下面命令,确认该 LinkServer 是否可以识别板载调试器:linkserver probes 请注意,建议在该目录下执行命令,而不是直接在任意命令行窗口执行,以避免调用到系统 PATH 中其他版本的 LinkServer。 如果您单独安装了其他版本的 LinkServer,也可以尝试勾选 Custom path ,并指定到对应的 LinkServer 安装目录,避免 IDE 仍然调用旧版本或异常路径下的 LinkServer。 回复: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 都试过了,还是不行 Re: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 Hi @breeze_i , 感谢您关注 NXP RT 系列产品并使用 NXP 社区。 关于您的问题我建议您检查下面几点: 1:首先检查防火墙或杀毒软件是否拦截 IDE / LinkServer / redlinkserv 的 localhost 通信; 2:不要在原 workspace 上继续试,新建一个空的 workspace,然后重新导入demo; 3:在 IDE 中执行 Clean Up Debug ,然后关闭 IDE,拔掉开发板/调试器,重新连接后再尝试 Debug。 请先按以上步骤排查。 Best  Regards May
View full article
asoc-simple-card: parse error after upgrading to kernel 6.18.x Hi, here is my working DT for Kernel 6.6.52: / { codec: max98357a@0{ compatible = "maxim,max98357a"; #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&sdmode_en>; sdmode-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; status = "okay"; }; sound { compatible = "simple-audio-card"; simple-audio-card,name = "SAI3 MAX98357A"; simple-audio-card,format = "i2s"; simple-audio-card,widgets = "Speaker","Speakers"; simple-audio-card,routing = "Speakers","Speaker"; simple-audio-card,bitclock-master = <&cpu_dai>; simple-audio-card,frame-master = <&cpu_dai>; cpu_dai: simple-audio-card,cpu { sound-dai = <&sai3>; clocks = <&clk IMX8MP_CLK_SAI3>; clock-names = "mclk"; //system-clock-frequency = <&clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; dai-tdm-slot-num = <2>; dai-tdm-slot-width = <32>; }; codec_dai: simple-audio-card,codec { sound-dai = <&codec>; //clocks = <&clk IMX8MP_CLK_SAI3>; }; }; }; &sai3{ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>; #sound-dai-cells = <0>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; assigned-clocks = <&clk IMX8MP_CLK_SAI3>, <&clk IMX8MP_AUDIO_PLL1>, <&clk IMX8MP_AUDIO_PLL2>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL2_OUT>, <&clk IMX8MP_AUDIO_PLL1_OUT>; // Try common MCLK rates that divide well to 48 kHz multiples // Option A: 24.576 MHz (very common for MAX98357A + 48 kHz) assigned-clock-rates = <24576000>, // PLL2 for 48 kHz <22579200>; // PLL1 for 44.1 kHz // Option B (if 44.1 kHz needed later): use PLL1 + 22579200 //assigned-clock-rates = <22579200>; fsl,sai-asynchronous; fsl,sai-mclk-direction-output; status = "okay"; }; After moving to kernel 6.18.20 SAI3 is not probing and I got no sound-card. The boot log shows: platform sound: deferred probe pending: asoc-simple-card: parse error What changes in the DT syntax from kernel 6.6.52 to 6.18.x? I didn't find anything relevant. How can I investigate the parse error? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x Hello, Could you please share your dmesg log? Best regards. Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x Hi Jorge, dmesg log and running device tree (./dtc -I fs -O dts /proc/device-tree > /tmp/running.dts) attached. Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x Hi, I have moved one step forward. After enabling the kernel configuration option CONFIG_IMX_AIPSTZ=y, the sound card device is now available. Because  sai3 node is a sub node of aips5 I also had to enable aips5 in my devicetree: &aips5 { status = "okay"; }; Now I got the following error messages: [ 13.081746] fsl-sai 30c30000.sai: ASoC error (-110): at snd_soc_dai_hw_params() on sai-tx-rx [ 13.090223] sai-tx-rx-HiFi: ASoC error (-110): at __soc_pcm_hw_params() on sai-tx-rx-HiFi speaker-test -c 2 -r 48000 -t sine 2>&1 | head -20 [ 31.368187] fsl-sai 30c30000.sai: ASoC error (-110): at snd_soc_dai_hw_params() on sai-tx-rx [ 31.376682] sai-tx-rx-HiFi: ASoC error (-110): at __soc_pcm_hw_params() on sai-tx-rx-HiFi Unable to set hw params for playback: Connection timed out speaker-test 1.2.11 Playback device is default Stream parameters are 48000Hz, S16_LE, 2 channels Sine wave rate is 440.0000Hz Rate set to 48000Hz (requested 48000Hz) Buffer size range from 24 to 131072 Period size range from 12 to 16383 Periods = 4 Setting of hwparams failed: Connection timed out Re: asoc-simple-card: parse error after upgrading to kernel 6.18.x I got it, sound is working. My kernel configs: CONFIG_SND_IMX_SOC=m CONFIG_SND_IMX_SOC=m CONFIG_SND_SOC_FSL_SAI=m CONFIG_SND_SOC_FSL_UTILS=m CONFIG_IMX_AIPSTZ=y The devicetree part: /{ codec: max98357a@0{ compatible = "maxim,max98357a"; #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&sdmode_en>; sdmode-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>; status = "okay"; }; sound { compatible = "simple-audio-card"; status = "okay"; simple-audio-card,name = "SAI3 MAX98357A"; simple-audio-card,format = "i2s"; simple-audio-card,widgets = "Speaker", "Speaker Ext"; simple-audio-card,routing = "Speaker Ext", "Speaker"; simple-audio-card,bitclock-master = <&cpu_dai>; simple-audio-card,frame-master = <&cpu_dai>; cpu_dai: simple-audio-card,cpu { sound-dai = <&sai3>; clocks = <&clk IMX8MP_CLK_SAI3>; clock-names = "mclk"; //system-clock-frequency = <&clk IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>; dai-tdm-slot-num = <2>; dai-tdm-slot-width = <32>; }; codec_dai: simple-audio-card,codec { sound-dai = <&codec>; }; }; }; &sdma2 { status = "okay"; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin"; }; &aips5 { status = "okay"; }; &audio_blk_ctrl { status = "okay"; assigned-clocks = <&clk IMX8MP_AUDIO_PLL1>, <&clk IMX8MP_AUDIO_PLL2>; assigned-clock-rates = <393216000>, <361267200>; }; &sai3{ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai3>; #sound-dai-cells = <0>; assigned-clocks = <&clk IMX8MP_CLK_SAI3>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK2>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK3>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3"; dmas = <&sdma2 4 2 0>, <&sdma2 5 2 0>; dma-names = "rx", "tx"; fsl,sai-asynchronous; fsl,sai-mclk-direction-output; status = "okay"; }; The devicetree base is imx8mp.dtsi
View full article
Flexioを特殊なSPIとして、同時に20ビットMOSI出力として動作させたい。 csとclkは共有されます。 20本のMOSIラインが20本のDACチップに接続されていますが、この環境下でFlexio Muilt-BeatはCAN動作しますか? 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 私が使用したチップはMCN947です。 FlexIOを使用して、24ビットDACを20個SPI制御するシミュレーションを行う必要があります。 これら20個のDACのCSおよびCCKパラメータは共通ですが、各チップはそれぞれ独立したMOSIを備えています。MISOは存在しません。したがって、厳密に言えばSPIではなく、20個のMOSIを備えたSPIと言えます。 出力が生成されるたびに、20個のDACの値が同時に更新される。 私の考えは、20個のDACから1ビットずつSHIFBUFに格納し、8個のSHIFBUFでそれぞれ8ビットを格納するというものです。 1回のDMA転送で、20個のDACに対する8ビットデータの更新が完了する。 DMA処理では、24ビットのデータを3回同期および更新します。最後に、チップセレクト信号が立ち上がります。 アイデアはあったものの、Flexioのサンプルコードを見ても、どこからコードを書き始めればいいのか分からなかった。 関連する事例をお持ちかどうか分かりません。また、私のやり方が最適かどうかも分かりません。 Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは@justdomyself 質問についてもう少し詳しく説明していただけますか? お知らせください: どのMCUを使っているのか教えてください。 ソフトウェアの設定方法。 どのような問題が発生していますか? 問題の理解に役立つ可能性のある追加情報があれば教えてください。 中国語で問題を説明していただいても構いません。 よろしくお願いします。 BR アリス
View full article