Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
RPMsg-Lite (3.1.2) ライブラリと 6.18 カーネルバージョンの互換性 こんにちは、 私はプロジェクトの一つでimx8 Nanoを使っており、M7コアにはRPMsg-Lite(3.1.2)が搭載されています。現在、A53コアのLinuxカーネルを6.18にアップグレードしています。RPMsg-Lite(3.1.2)はこのLinuxカーネルバージョン6.18と互換性がありますか?それともRPMsgライブラリファイルの更新が必要ですか? 敬具 ヤドゥナート・R Re: RPMsg-Lite (3.1.2) lib compatability with 6.18 Kernel version こんにちは @Yadunath。 NXPサポートにご連絡いただきありがとうございます! 問題なく動作するはずです。しかし、すべてのBSPとMCUXpresso SDKsの組み合わせを確認できる内部互換性マトリックスは持っていません。 どのBSPバージョンとMCUXpresso SDKのバージョンを使っているのか教えていただけますか?自分の側でこれを正当化しようとCAN努力します。 よろしくお願いします、 チャビラ
記事全体を表示
RTC電力計算 こんにちは、NXPさん。 RT1176のSNVS電源ドメインに必要なアクティブ電流とスリープ電流を用いて、RTCのバッテリー寿命を計算しています。 ただし、データシートIMXRT1170BIEC - 表13、35ページを参照してください。スリープ電流のみが記載されています。 SNVS電力領域における有効電流に影響を与える要因と、有効電流に関連する各種計算についてお知らせください。 Re: RTC Power Calculation こんにちは、 @specneeraj さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます! VDD_SNVS_INはSNVS/RTCドメインに電力を供給します。このドメインは常時オンの低消費電力ドメインで、主に32 kHzのRTC、SNVSロジック、関連するウェイクアップおよびセーフティ機能を維持します。現在の消費量はCM7/CM4の活動状態/睡眠状態とは弱い相関しかありません。したがって、表13に示されたSNVSモードのVDD_SNVS_IN値は「スリープのみ」のデータではなく、RTCバックアップシナリオで使用できるベースライン値です。 コイン型電池が主電源の故障時のみ電力を供給する場合 → SNVSモードの電流推定値を直接使用する。 システムがアクティブな間、コイン型電池が VDD_SNVS_IN にも電力を供給する場合、アクティブ/SNVSデューティサイクルに基づいて平均電流を計算します。 SNVS電流に影響を与える主な要因としては、温度、 VDD_SNVS_IN 電圧、プロセスばらつき、32kHz RTC水晶発振器/基板からのリーク電流、SNVS関連ピンからの外部リーク電流、およびデバイスが実際にSNVSモードに入っているかどうかなどが挙げられます。詳細については、 AN13104を参照してください。 よろしくお願いします、 ギャビン
記事全体を表示
IMX95ブートカウント管理 こんにちは、 最近、imx95 19x19 EVKボードの開発に取り組んでいて、ディストリビューションのアップデート/リカバリーにブートカウント マネジメントの仕組みを実装したいと考えています。 TRMを調べてみたところ、GPR(汎用レジスタ)はBBNSM内にあり、SCMIプロトコル(M33上で動作するSMへのリクエスト)を介してアクセスできることがわかりました。u-bootでは、arch/arm/mach-imx/imx9/scmi/soc.cで親切にAPIを用意しており、scmi_set_bbnsm_gpr scmi_get_bbnsm_gpr bootcount_store()/_load()を問題なく実装できました。 しかし、カーネルにはそのようなAPIは存在しません!(成功した起動後にLinuxユーザー空間からブートカウントをリセットしたいと思っています。) さらに、あなたのドキュメントでCyber Resilient Recovery Module(CRRM)を見かけたのですが、ディストリビューションアップデートのために自己管理のブートカウントが本当に必要かどうか疑問に思っています。 そこで、あなたに以下の質問があります。 なぜカーネル内でGPRアクセス用のSCMI APIをサポートしていないのですか?CRRMがGPRの一つを使っているからですか? CRRMを使用する場合、ディストリビューションのアップデート管理にブートカウントを設けるのは理にかなっていますか?はいの場合、GPR以外でブートカウントを保存する場所として推奨される場所はありますか?(またはGPRにアクセスする他の方法など) どんな回答でも大変ありがたく思います。 SoC: i.MX 95 (19x19 LPDDR5 EVK) BSP: LF6.18.20_2.0.0 ありがとうございました。 アブデル Re: IMX95 bootcount managment こんにちは、 @Chaviraさん 貴重なご説明をありがとうございました。 GPRの使用は問題ありませんが、NXPのカーネル側でGPRアクセスを追加する公式ドライバはありますか? カーネルソースのドライバ/ファームウェア/arm_scmi/ベンダーズ/IMXの項目でimx-sm-bbm.cが確認できますGPRコマンドを定義しますが、実装はしません!! enum scmi_imx_bbm_protocol_cmd { IMX_BBM_GPR_SET = 0x3、 IMX_BBM_GPR_GET = 0x4、 IMX_BBM_RTC_ATTRIBUTES = 0x5、 IMX_BBM_RTC_TIME_SET = 0x6、 IMX_BBM_RTC_TIME_GET = 0x7、 IMX_BBM_RTC_ALARM_SET = 0x8、 IMX_BBM_BUTTON_GET = 0x9、 IMX_BBM_RTC_NOTIFY = 0xA、 IMX_BBM_BUTTON_NOTIFY = 0xB、 };   リストされているコマンドはすべて実装するが、GPRコマンドだけは実装しないという決定には、何か理由があるのでしょうか?私は、独自の実装に頼る前に、NXPが意図するアプローチに沿うことを好みます。   よろしくお願いいたします。 アブデル Re: IMX95 bootcount managment こんにちは、 @Abder さん。 詳細な調査をありがとうございました。 簡単に言うと、CRRMとROMリカバリはブートカウント機構を置き換えるものではありません。破損や無効なブートイメージからの復旧は助けますが、Linuxやアプリケーションが正常に起動したかどうかは判別できません。OTAアップデートソリューションの場合、アップデートの失敗を検出し、自動的にロールバックを実行するために、ブートカウント機能が引き続き推奨されます。 BBNSM GPRに関しては、U-BootはNXP固有のSCMI関数を通じてアクセスを提供しますが、Linuxは現在同等のインターフェースを公開していません。これらのレジスタにLinuxでアクセスが必要な場合は、カスタムカーネルドライバーやSCMIベンダー拡張が必要になるでしょう。 あなたのユースケースでは、すでにU-Bootで動作しているBBNSM GPRをブートカウントストレージとして使い続けることをお勧めします。CRRMのリカバリーとブートカウント管理は異なる目的を果たしており、代替案ではなく補完的なメカニズムとみなすべきです。 よろしくお願いします、 チャビラ
記事全体を表示
電気自動車のパワートレイン設計エンジニアになるには? EVパワートレイン設計エンジニアとして、どのようにすればより良く、雇用に適しているか、どんなツールに慣れておけばいいでしょうか?学んだことをよりよくアピールするためにポートフォリオを作るなど、できることはありますか? 理解や練習に役立つオンラインの練習課題や教材はありますか? 私の経歴:私は電気自動車業界に全くの初心者で、ゼロからスタートします。私にとってはキャリアチェンジです。機械工学の学位を持っています。しかしここ数年は別のキャリアをしており、エンジニアとして働いたことはなく、EVにはずっと情熱を持っていました。 SO、戻ってギャップを埋めるために EVデザインについてもっと学ぶためのコースを受講しています。タイトルは「Evパワートレインデザインと検証の修士課程」です。主にMATLAB Simulinkを使ったモデリングで、EVに関する実地試験はごくわずかです。 オルタネータ・レギュレータ
記事全体を表示
RD33771CNTREVM + FreeMASTER 项目 您好, 我目前正在评估 RD33771CNTREVM(高压电池管理系统)参考设计板。 根据用户手册(UM11310),该板通过 CAN0 接口(连接器 J12)输出原始寄存器数据。虽然我可以使用标准的 CAN-USB 接口读取原始十六进制消息,但我正在寻找一种更有效的实时可视化电池电压和温度的方法。 我注意到,对于类似的硅组合(S32K144 + MC33771C),NXP 在 BCC 软件驱动程序代码包,软件包中提供了 BCC_S32K144_FreeMASTER 示例项目。 在开始修改引脚布线并将这个通用示例移植到 RD33771CNTREVM 的特定硬件布局之前,我想问一下: NXP是否有专用的FreeMASTER项目(.pmp / .pmpx)?以及相应的 .elf 文件专为RD33771CNTREVM板定制的固件? 感谢您的支持。 Re: RD33771CNTREVM + FreeMASTER project 嗨,马文, 我找到了应用团队对另一位客户的回复,该客户曾询问RD33771CNTREVM 的 FreeMASTER 示例。很遗憾,我们目前没有 FreeMASTER 示例,只有 EvalGUI。请查看以下回复。您可以从MC33771C 产品页面下载 EvalGUI,它是公开提供的。 给您带来的不便,敬请谅解。 说明 很遗憾,情况确实如此,示例代码附带的 FreeMaster 接口仅适用于单个节点。目前来看,它不支持 4 个节点,只有第一个节点会被初始化和监测。 对于这个分布式平台,唯一可用于多个节点的 GUI 是 EvalGUI 5.15。 最诚挚的问候, 约瑟夫 Re: RD33771CNTREVM + FreeMASTER project 嗨,约瑟夫, 谢谢你的回答。我试用了 EvalGUI 5.15,但它在 Windows 11 上运行缓慢,而且只能通过 COM 端口工作。RD33771CNTREVM 具有 CAN 输出…… 我看看能不能从PCB板上获取RX和TX信号。然后我可以修改开发套件的原始固件,使其具有 EvalGUI 5.15 所期望的相同输入/输出消息。 但我仍然希望开发套件能采用 PC SW 或 FreeMASTER 项目。那将非常有帮助。 Re: RD33771CNTREVM + FreeMASTER project 嗨,马文, 目前除了MC33771C和RD33771CNTREVM产品页面中提供的软件外,没有其他软件。由于 MC33771C 是一款老产品,虽然仍在生产,但可能不会有新的软件。我们有更新的BCC。对于新设计,我更推荐您选择 24 通道或 26 通道的 BCC。BMA7x2x系列。这些是BCC的最新元器件。 https://www.nxp.com/products/product-selector:PRODUCT-SELECTOR?category=c40_c328&page=1&nrnd=false 最诚挚的问候, 约瑟夫
記事全体を表示
如何进行 Blob FLUSH S32E288-975EVB 您好,我们公司正在考虑将这款芯片用于我们的新产品。 我在将代码构建为版本并通过 micro-USB UART 接口烧录到板上时遇到了问题。我已成功将 RTD 代码包,软件包中预编译的“Hello world”打印二进制文件写入开发板并测试其工作正常,所以我知道这是可行的,但当我想要使用自己的代码执行此操作时,我却找不到任何相关说明。 RTD 的所有示例中,Project_setting/Linker_files/ 目录下都没有 linker_flash 文件,手册中也没有提到如何创建这些文件。我应该以 JTAG 调试 RAM 模式版本并手动使用 IVT 吗?具体流程是什么? 如何创建一个可用于 UART 闪存的版本文件? 如果有人能指点我一下,我将不胜感激。 我在这个论坛上找到了这个: https://community.nxp.com/t5/S32Z-E/creating-a-Blob-Image-using-IVT-S32Z2/mp/2362406#M322 我不确定这是否有效,因为这个问题还没有关闭,但我会尝试一下。如果有人能支持这个板,那就太好了。 Re: How to Blob FLUSH S32E288-975EVB 你好, pyc 关于如何创建 Blob,从启动 Flash 开始,您可以参考以下内容。 1.我们建议的推荐启动方法是像 GreenVIP 那样,从 SMU 开始,然后进行到 R52。详情请参考GreenVIP网站。在 GreenVIP 中,还有关于如何创建 Blob 以及如何销毁 Blob 的说明。 S32ZE_GreenVIP_1.3.x/doc/UG_S32ZE_GreenVIP.pdf 设计:产品信息:汽车软件 - S32Z/E - 车辆集成平台 (GreenVIP) 2. 要直接从 R52 开始,您需要修改链接脚本和启动文件。这有点复杂。您可以参考以下链接,其中提供了类似情况的帮助。 无需调试探针即可在 S32Z280-594EVB 上为 R52_0_0 内核创建 IVT Flash 映像的指南。 如何减小 S32Z2 中的二进制文件大小 3.关于 S32E288-975EVB 的 QSPI 启动模式设置,您可以参考 S32E288-975EVB 用户指南中的这张图片。 S32E288-975EVB 评估板解决方案(适用于 S32E2 系列微控制器)用户指南 BR 乔伊 Re: How to Blob FLUSH S32E288-975EVB 你好, pyc 感谢您与我们联系。 你们网站上的设计文件也缺少原理图,所以我这边无法进行检查。非常感谢您的帮助。 您可以在官方网站界面上找到 S32E288-975EVB 的设计文档和入门指南,如下图所示。 S32E288-975EVB 评估板 | 恩智浦半导体 BR 乔伊 Re: How to Blob FLUSH S32E288-975EVB 您好,示例二极管代码试图切换 D12,而您网站上的 S32E288-975EVB 入门指南使用的是 S32E288-400EVB 的信息。你们网站上的设计文件也缺少原理图,所以我这边无法进行检查。非常感谢您的帮助。 Re: How to Blob FLUSH S32E288-975EVB 简要更新。我对 Dio 示例尝试了完全相同的步骤,并且成功创建了 blob 文件。我把它贴到电路板上了,但是LED灯没有闪烁。刷新过程肯定是正确的,因为我能够刷新掉在 IDE 文件夹中找到的一些预版本产物。有人在NXP验证过这个流程是否真的适用于这个开发套件吗?
記事全体を表示
ブロブフラッシュの方法 S32E288-975EVB こんにちは、NXPについてはこのチップを新製品に使うことを検討しています。 マイクロUSB UART経由でコードをビルドしてボードに書き込むのに苦労しています。RTDパッケージに付属している既製の「Hello World」プリントバイナリをボードにフラッシュして動作をテストできましたが、自分のコードでやりたいときは手順が見つかりませんでした。 RTDのどのサンプルにも、Project_setting/Linker_files/にlinker_flashファイルは存在せず、マニュアルにもその方法に関する記述はありません。JTAGデバッグRAMモードでビルドして、IVTを手動で使用する必要があるのでしょうか?手順はどうなっていますか? UARTで書き込めるファイルを作成するにはどうすればよいですか? もし誰か正しい方向を教えていただけるなら、とてもありがたいです。 このフォーラムでこれを見つけました。 https://community.nxp.com/t5/S32Z-E/creating-a-Blob-Image-using-IVT-S32Z2/mp/2362406#M322 これがうまくいくかどうかは分かりません。まだクローズされていないので。でも試してみます。もしこの掲示板へのサポートがあれば、ぜひ教えてください。 Re: How to Blob FLUSH S32E288-975EVB こんにちは、 pyc Blobの作り方については、Flashを起動する際の以下の内容を参照してください。 1. 私たちが推奨するスタートアップ方法は、GreenVIPのようなもので、SMUからR52まで進みます。詳細はGreenVIPをご覧ください。GreenVIPには、Blobの作成方法とBlobの書き込み方法に関する説明も含まれています。 S32ZE_GreenVIP_1.3.x/doc/UG_S32ZE_GreenVIP.pdf 設計:製品情報:オートモーティブソフトウェア - S32Z/E - 車載統合プラットフォーム(GreenVIP) 2. R52から直接起動するには、リンクスクリプトと起動ファイルを変更する必要があります。少し複雑です。以下のリンクを参照してください。同様の状況をサポートしています。 デバッグプローブなしでS32Z280-594EVB上のR52_0_0コア向けIVTフラッシュイメージを作成するためのガイダンス。 S32Z2のバイナリサイズを縮小する方法 3.S32E288-975EVBのQSPIブートモード設定については、S32E288-975EVBの画像フォームユーザーガイドを参照してください。 S32E2ファミリーマイクロコントローラ向けS32E288-975EVB評価ボードソリューションユーザーガイド BR ジョーイ Re: How to Blob FLUSH S32E288-975EVB こんにちは、 pyc お問い合わせいただきありがとうございます。 あなたのウェブサイトの設計ファイルにも回路図がないため、私自身の視点から確認できません。どんなご協力でもありがたいです。 >>>S32E288-975EVBのデザイン図書とスタートガイドは、公式ウェブサイトのインターフェースで以下の写真でご覧いただけます。 S32E288-975EVB評価ボード |NXPセミコンダクターズ BR ジョーイ Re: How to Blob FLUSH S32E288-975EVB こんにちは、例示ダイオードコードはD12を切り替えようとしており、あなたのウェブサイトにあるS32E288-975EVBの入門ガイドはS32E288-400EVBの情報を使っています。あなたのウェブサイトの設計ファイルにも回路図がないため、私自身の視点から確認できません。どんなご協力でもありがたいです。 Re: How to Blob FLUSH S32E288-975EVB 簡単なアップデートです。Dioの例でも全く同じ手順を試したところ、ブロブファイルを作成することができました。基板にフラッシュしたのですが、LEDが点滅しません。フラッシュ手順は間違いなく正しく、IDEフォルダ内で見つけたプリビルドのアーティファクトをフラッシュできました。NXP社内で、この手順が実際にこの開発キットで機能するかどうかを確認した人はいますか?
記事全体を表示
RPMsg-Lite (3.1.2) 库与 6.18 内核版本的兼容性 您好, 我正在使用 imx8 Nano 开发一个项目,其中我的 M7 内核运行的是 RPMsg-Lite (3.1.2)。现在我正在将 A53 内核的 Linux 内核升级到 6.18。RPMsg-Lite (3.1.2) 是否与 Linux 内核版本 6.18 兼容?或者是否需要更新 RPMsg 库文件? 问候 亚杜纳特·R Re: RPMsg-Lite (3.1.2) lib compatability with 6.18 Kernel version 你好@Yadunath , 感谢您联系恩智浦技术支持! 应该可以正常运行。但是,我们没有内部兼容性矩阵来确认所有电路板支持包和 MCUXpresso SDK 的组合。 请问您使用的是哪个 电路板支持包。版本和哪个 MCUXpresso SDK 版本?我可以尝试从我这边验证一下。 此致, 查维拉
記事全体を表示
MCUXpresso IDE路线图 大家好, MCUXpresso IDE 还受支持吗? 近几年,MCUXpresso IDE 大约每 4 个月就会进行一次升级。自 2025 年 6 月起,不再进行升级。这是否意味着MCUXpresso IDE未来将不再升级? 非常感谢 比夫拉 Re: MCUXpresso IDE roadmap 你好@biafra , 感谢你的帖子。 目前还没有新的 MCUXpresso IDE 路线图计划。我们主要关注和推荐的开发环境是MCUXpresso for Visual Studio Code | NXP 半导体 。 不过,最新的 MCUXpresso IDE v25.06 仍在积极维护中,您可以继续导入和使用新设备的 SDK,而不会遇到任何问题。 请注意,如果您使用集成配置工具来配置较新的产品,请务必手动更新配置工具代码包,软件包。有关详细说明,请参阅:在 MCUXpresso IDE 中更新配置工具 - NXP 社区。 希望对您有所帮助。 BR 塞莱斯特
記事全体を表示
IMX95启动计数管理 您好, 我最近一直在研究imx95 19x19 EVK板,我感兴趣的是为我们的发行版更新/恢复实现一个启动计数管理机制。 查看 TRM 后,我发现 GPR(通用寄存器)位于 BBNSM 中,可通过 SCMI 协议(向在 M33 上运行的 SM 发出请求)访问。在 u-启动 中,scmi_get_bbnsm_gpr() 和 scmi_set_bbnsm_gpr() API 已提供(在 arch/arm/mach-imx/imx9/scmi/soc.c 中),因此我能够毫无问题地实现我的 bootcount_store()/_load()。 然而,内核中并不存在这样的 API!(我希望在Linux启动成功后,从Linux用户空间重置启动计数。) 此外,我在您的文档中看到了网络弹性恢复模块 (CRRM),现在我甚至怀疑是否有必要对发行版更新进行启动计数的自我管理。 所以我有几个问题想问你: 为什么内核不支持通过 SCMI API 进行 GPR 访问?是因为 CRRM 使用了某个 GPR 吗? 使用 CRRM 时,设置启动计数来管理发行版。更新是否有感知?如果可以,除了 GPR 之外,您建议将启动计数存储在哪里?(或者还有哪些其他方法可以访问探地雷达) 任何回答我都非常感激。 SoC:i.MX 95(19x19 LPDDR5 EVK) 电路板支持包。LF6.18.20_2.0.0 谢谢! 阿布德尔 Re: IMX95 bootcount managment 嗨@Chavira 感谢您提供的宝贵澄清。 那么使用GPR是可以的,但是NXP是否会在内核端提供官方驱动程序来添加GPR访问权限呢? 我可以在内核源代码的 drivers/firmware/arm_scmi/vendors/imx 目录下看到 imx-sm-bbm.c 文件。定义了探地雷达(GPR)命令,但没有实现它们! enum scmi_imx_bbm_protocol_cmd { IMX_BBM_GPR_SET = 0x3, IMX_BBM_GPR_GET = 0x4, IMX_BBM_RTC_ATTRIBUTES = 0x5, IMX_BBM_RTC_TIME_SET = 0x6, IMX_BBM_RTC_TIME_GET = 0x7, IMX_BBM_RTC_ALARM_SET = 0x8, IMX_BBM_BUTTON_GET = 0x9, IMX_BBM_RTC_NOTIFY = 0xA, IMX_BBM_BUTTON_NOTIFY = 0xB, };   做出这个决定(即实施所有列出的命令,唯独不实施 GPR 命令)有什么原因吗?在采用任何自定义实现之前,我更倾向于遵循 NXP 的既定方案。   顺祝商祺! 阿布德尔 Re: IMX95 bootcount managment 嗨@Abder , 感谢您进行的详细调查。 简单来说,CRRM 和 ROM 恢复并不能取代启动计数机制。它们可以帮助从损坏或无效的启动映像中恢复,但它们无法确定 Linux 或您的应用程序是否已成功启动。对于 OTA 更新解决方案,仍然建议使用启动计数来检测更新失败并执行自动回滚。 关于 BBNSM GPR,U-启动可通过 NXP 特有的 SCMI 功能提供访问,但 Linux 目前没有公开等效接口。如果您需要在 Linux 系统中访问这些寄存器,则可能需要自定义内核驱动程序或 SCMI 供应商扩展。 对于您的使用场景,如果 BBNSM GPR 已经在 U-Boot 中正常工作,我们建议您继续使用 BBNSM GPR 进行启动计数存储。CRRM 恢复和启动计数管理用途不同,应视为互补机制,而不是替代机制。 此致, 查维拉
記事全体を表示
RPMsg-Lite (3.1.2) lib compatability with 6.18 Kernel version Hi, I am using imx8 Nano for one of my project ,where my M7 core has RPMsg-Lite (3.1.2).Now i am upgrading the linux kernel of the A53 core to 6.18. Is the RPMsg-Lite (3.1.2) compatible with the this linux kernel version of 6.18 or is it required to update the RPMsg lib files Regards Yadunath R Re: RPMsg-Lite (3.1.2) lib compatability with 6.18 Kernel version Hi @Yadunath, Thank you for contacting NXP Support! It should work without any issues. However, we do not have an internal compatibility matrix to confirm all BSP and MCUXpresso SDK combinations. Could you please let me know which BSP version and which MCUXpresso SDK version you are using? I can try to validate this on my side. Best Regards, Chavira Re: RPMsg-Lite (3.1.2) lib compatability with 6.18 Kernel version Hi @chavira While porting the kernel from 5.15 to 6.18  # dmesg -T | grep -Ei 'rpmsg|rproc' [Tue Oct 8 15:42:28 2024] imx rpmsg driver is registered. [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: error -ENOENT: Failed to enable clock [Tue Oct 8 15:42:29 2024] imx-rproc imx8mn-cm7: probe with driver imx-rproc failed with error -2 [Tue Oct 8 15:42:29 2024] remoteproc remoteproc0: releasing imx-rproc I am getting this error.When i searched this error online i was asked to add dummy clock in the dts as below  imx8mn-cm7 {     compatible = "fsl,imx8mn-cm7";     rsc-da = <0xb8000000>;     clocks = <&clk IMX8MN_CLK_DUMMY>;     mbox-names = "tx", "rx", "rxdb";     mboxes = <μ 0 1                                    μ 1 1                                    μ 3 1>;     memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;     status = "okay";   } Could u please let me is this the only the change required. What is the reason for this change. Regards Yadunath R
記事全体を表示
MCUXpresso IDE ロードマップ こんにちは、皆さん MCUXpresso IDEはまだサポートされているのでしょうか? ここ数年は約4ヶ月ごとにMCUXpresso IDEのアップグレードがありました。2025年6月以降、アップグレードは行われません。これはFUTUREにMCUXpresso IDEがアップグレードされないということでしょうか? どうもありがとうございました ビアフラ Re: MCUXpresso IDE roadmap こんにちは、 @biafra さん、 投稿ありがとうございます。 現時点では、新しいMCUXpresso IDEロードマップの計画はありません。私たちの主な焦点であり推奨される開発環境は、 Visual Studio Code のMCUXpressoです。NXP Semiconductors。 しかし、最新のMCUXpresso IDE v25.06は現在も活発にメンテナンスされており、新しいデバイス向けにSDKsのインポートや使用は問題なく続けられます。 新しい製品で 統合された Config Tools を使う場合は、必ず手動でConfig Toolsパッケージを更新してください。詳細な手順については、以下をご覧ください: MCUXpresso IDEの設定ツールの更新 - NXPコミュニティ。 お役に立てば幸いです。 BR セレステ
記事全体を表示
ntag424的Originality Signature 你好: 我司已经签署保密协议,但是不知道如何使用natg424 uid与公钥,Read_Sig获取的56字节签名在嵌入式硬件平台实现ECDSA验证。文档上an11350没有详细步骤实现ECDSA verification(secp224r1),能否告诉我申请哪些资料来实现,谢谢。 Re: ntag424的Originality Signature 你好@qinzhi 希望你一切都好。 非常抱歉,用作 NTAG 签名验证参考,引用的应用笔记 (AN11350) 适用于其他具有 32 字节签名和不同曲线的 NTAG 产品。 NTAG 424 DNA 和 NTAG 424 DNA TagTamper 特性和提示第 7.2 节描述了非对称签名验证的可用程序。但是,由于 ECDSA 验证程序是在卡片之外进行的,因此没有关于 ECDSA 验证的具体信息。 对于给您带来的不便,我再次深表歉意。 问候, 爱德华多。
記事全体を表示
UWB Single beacon + AoA for doorway inside/outside detection advice I'm building a wall-mounted single-anchor UWB system (doorway exit-detection use case) that needs to determine whether a tag is inside or outside a doorway using AoA — including doors that are already open, so I can't gate on a door contact sensor. Background: I was running Qorvo QM33120W/DW3000 (2-antenna PDoA) and hit a hard architectural wall; with the anchor mounted ~7ft up facing straight down, walking/circling under it produces false "outside" angle commits even on clean, strong signal. My plan was to have the UWB antennas face directly down toward the ground so that I can capture both positive and negative angles (inside and outside) signals to determine when a tag moves from inside to outside (exit detection). Currently with the Qorvo devices, if I hold the tag in the optimal straight forward/antenna on top, everything is fine but when moving/rotating the tag (DW3000), I start seeing different AoA values even when standing in the same place. Sign convention issue: My expectation is a consistent convention — positive angle while inside, negative once the tag crosses to outside. In practice, while unambiguously still inside, I'm seeing both positive and negative angles, correlated with the tag being rotated and moved in random directions/speeds — not with actual crossing of the doorway. This is the specific symptom I'm trying to design around before committing to new hardware. I'm now evaluating a move to NXP silicon and would appreciate community input: Qorvo 2D AoA boards use an RF switch to capture the UWB PDoA between the two antennas. Will switching to the NXP SR150 dual rx chain solve my AoA jumping issues? For a single overhead-mounted anchor with a tag moving through a doorway below it, is SR150's 2D/software-assisted-3-antenna-3D AoA mode sufficient to resolve front/back ambiguity, or does this really need SR250's 3 simultaneous RX chains for a true second baseline? Any recommended antenna geometry/mounting orientation for this specific top-down overhead use case? Any real-world experience with SR150's antenna-switched 3rd-antenna mode vs. SR250 in ambiguity-prone geometries like this? Thanks. Re: UWB Single beacon + AoA for doorway inside/outside detection advice Hello, Hope you are doing well. For a single overhead-mounted anchor doing inside/outside doorway detection with a freely rotating tag, the Trimension SR250 is the right platform and is our recommended UWB product for IoT and Industrial anchor designs. The core reason for this recommendation is hardware architecture. The SR250 integrates 3 simultaneous RX paths for one-shot 3D AoA with no external RF switches required, delivering both azimuth and elevation from a single ranging frame. The SR250 also brings additional capabilities that are valuable for this use case: 360° AoA support with antenna diversity up to 9 antennas On-chip UWB radar (OCPD) for presence detection, a useful complementary layer alongside ranging-based crossing detection FiRa 4.0 and Aliro 1.0 ready, ensuring interoperability with the broader UWB ecosystem Where to Start Dev kit: SR250 Development Board, Arduino-compatible, integrated PCB antennas, plug-and-play demos for ranging, AoA, and radar out of the box Software: SR250 UWBIOT for Zephyr OS Partner modules & kits: TrueSense (ETNA TS 250 DevKit), MobileKnowledge (MK UWB Kit Mobile edition 2.0), Amotech (SR250 Integrated 3D Antenna Module), all available via the NXP Partner Marketplace Hope this helps. Best Regards, Ricardo Re: UWB Single beacon + AoA for doorway inside/outside detection advice Thanks Ricardo, appreciate the detailed response. Update: I've ordered both the Murata Type2BP (SR150) dev board and the NXP SR250UWBSHIELD dev board. Unfortunately, the SR250UWBSHIELD is showing a 14-week backorder on my end, so I'll be starting bench work on SR150 in the meantime and moving to SR250 once it arrives. A few follow-ups while I wait: 1. SR150 vs. SR250 for my specific application: given that I only need azimuth (inside/outside), not elevation, what benefit would I actually see moving from SR150 to SR250 beyond the architecture difference (true 3 simultaneous RX chains vs. SR150's 2 native chains + switched 3rd antenna)? Is the accuracy/stability improvement meaningful enough for a single-axis use case to justify the wait, or would SR150 likely get me there on its own once I have my mounting/multipath mitigations in place? 2. RF switching and tag rotation: one specific symptom I'm trying to root-cause, on the Qorvo hardware, if I stand in exactly the same spot and just rotate the tag on the X plane (no position change at all), the AoA value jumps around noticeably even appearing to flip polarity. Qorvo's 2D AoA uses an RF switch to time-multiplex the two antennas rather than sampling them simultaneously. Do you think that switching architecture is a likely contributor to this rotation-correlated instability, or is this more consistent with something else (tag radiation pattern/polarization sensitivity as it rotates, multipath, etc.)? Trying to understand whether SR150/SR250's simultaneous RX sampling would be expected to resolve this specific symptom or if it's a separate issue I'd need to address regardless of chip. 3. 2D vs. 3D AoA for my use case: since I only need to know inside vs. outside (azimuth), and elevation isn't meaningful for my application, is there any accuracy or reliability benefit to running full 3D AoA anyway, or would I be better off configuring azimuth-only and ignoring elevation? Specifically wondering if the elevation measurement helps discriminate reflected/NLoS signals from valid ones even if I don't use elevation for the actual inside/outside decision. 4. Power draw, 2D vs. 3D: this will be a battery-powered install. Is there a meaningful current draw difference between running 2D-only vs. full 3D AoA on SR250, given it's 3 simultaneous RX chains either way? Or is the power cost basically fixed once all 3 chains are active regardless of which axes I use in software? 5. Multipath mitigation for my specific install: the beacon will be wall-mounted above a doorway with a nearby glass door and a ceiling roughly 5ft above the unit. I've been seeing what looks like reflection-driven angle instability on my current Qorvo hardware (correlates with tag rotation, worse in higher-ceiling rooms, worse with the glass door closed). Any recommended mounting practices, antenna beamwidth/pattern choices, or firmware-side filtering (FOM/NLoS thresholds) specifically for suppressing near-field reflections off glass and adjacent walls? Or are there any features on either the NXP SR150 or SR250 that would suppress this issue? 6. Radar-based motion gating for battery savings: I'd like to use SR250's on-chip radar (OCPD) purely as a low-power wake trigger: stay in radar mode, only spin up full ranging/AoA once motion is detected. With the anchor mounted above a ~2m-high doorway, antennas facing straight down, roughly what motion detection range/coverage should I expect directly below the unit? Trying to size the radar's effective "wake zone" against the doorway footprint. I would want to detect movement as the person is walking toward and away from the doorway. Thanks again for the help.
記事全体を表示
EZH-VのユースケースIMXRT700 こんにちは、NXPチームの皆さん! IMXRT700の仕様から、プレスリリース、製品ニュース、コンピュート、センスの3ドメインに分類されており、チップ上の各コアが動作するためにそれぞれ独立したイメージを必要とするとされていました。しかし、EZH-Vコアの使用例に関する文書は非常に少ないようです。 アプリケーションノートAN14614、AN14618、AN14654は読みましたが、このコアやRT700のグラフィカルプロセッシングにおける役割に関する情報はまだほとんどありません。SmartDMAエンジンの実装に使われると言われていましたが、他のMCXファミリのMCUではこのコアの存在が記載されておらず、スマートDMAはmcuxpresso SDKが提供するAPIを通じてArm CM33コアで直接利用可能です。 今は非常に混乱しています。iMXRT700でsmartDMAを直接使うことはできますか?それともAN14614指示に従ってLLVM経由でEZH-Vのイメージを構築しなければならないのでしょうか?ただし、IPC通信はCpu0によって直接制御されるはずなのに、RPMsgに頼らざるを得ないというのは、非常に直感に反するように思えます。 さらに、NXPがこのEZH-Vコアを明示的に活用した実際のデモやユースケースを提供した例は私の知る限りありません。入手可能なソースヘッダーの一部も確認しましたが、ごく基本的な操作しか提供されていませんでした。EZH-Vの用途を教えていただけますか? Re: EZH-V use case for IMXRT700 さて、簡単なアップデートです。メインラインのZephyrにあるSmartDMAドライバを見て、状況が理解できました。 スマートDMAは常に、独自のコアを持つスタンドアロンのサブシステムとして計画されてきましたが、完全に独立したRISC-Vコアとして提示されたことはありません。 現在の例では、smartDMAはカスタムファームウェアのインストールパスに実際には一切触れておらず、わずかに特殊なDMA IPとしてのみ使用されています。 さて、今度は昔ながらのスマートDMAを使い続けられるかどうかに軸足を移すべきです。複雑なIPC設定を行う代わりにCM33経由で直接呼び出しされるもので、執筆時点でスマートDMAのIPは公式管理mimxrt700_evkのサポートIPとしてまだ公開されていません。 Re: EZH-V use case for IMXRT700 こんにちは@mayliu1 迅速な返信ありがとうございます。つまり、スマートDMAはもはやCM33コアと結合されておらず、EZH-Vコア経由で使わなければならないということですか? NXPの他のMCUファミリであるMCXでは、スマートDMAはCM33と連結されており、API経由で直接呼び出すことができます。これらのユースケースを文書化したアプリケーションノートAN14172、AN14916、RISC-Vコアのスタンドアロンイメージビルディングには関わりません。 では、i.MXRT700の現在のアーキテクチャはどのようなものですか?EZH-Vに関する資料はどれも非常に曖昧で、EZH-Vの使い方を網羅的に解説したデモやガイドは今のところ見当たりません。 NXPはスマートDMAのアーキテクチャを改訂し、もはやコアのCM33システムの一部から外し、RISC-Vのコンパニオンコアにグループ化したのでしょうか?CM33経由でスマートDMAを直接呼び出すことはCANか? Re: EZH-V use case for IMXRT700 こんにちは、 @TomC818 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 AN14614および i.MX RT700リファレンス・マニュアルによると、私の理解では、i.MX RT700のSmartDMA機能は、eDMAのような従来のDMAペリフェラルではなく、EZH-V RISC-Vコアを通じて実装されているようです。 一般的に、eDMAは標準的なメモリ転送操作において依然として推奨されており、CM33コアから直接設定可能です。しかし、特定のグラフィックス/データ後処理やデータフォーマット変換タスクなどのSmartDMA関連プロセッシングは、通常EZH-Vコア上で動作するファームウェアによって実装されます。 AN14614に基づき、CPU0はEZH-Vファームウェアのロードと起動を担当し、その後実際のプロセッシングはEZH-Vによって行われます。この観点から見ると、EZH-Vは従来のDMAエンジンよりもプログラム可能なコプロセッサのように振る舞います。 したがって、RT700上のSmartDMAは、CM33のみで直接駆動される従来のDMAペリフェラルよりも、EZH-Vコア上で動作するプログラム可能なプロセッシングエンジンとして見るべきです。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: EZH-V use case for IMXRT700 あの、あの...もしNXPが実際に準備やサポート計画を持たなかった場合、"EZH-Vの支援により、Cortex-M33コアは他の作業に自由に使える。EZH-Vが割り当てられたタスクを実行する間、CM33コアは他のタスクを並列実行できます。" 説明のリファレンス・マニュアルによると、RT700のドキュメントや例はまだ非常に未完成で散漫なため、STやInfineonとは別の選択肢を追求しようと思います。このMCUのマーケティングされている独特な機能のサポートは非常に少なく、ほとんどありません。このような複雑で異種混在のアーキテクチャでは、このようなわずかな例やガイドは全く役に立たない。
記事全体を表示
S32K3 待机 + FIRC + 看门狗 你好, 我正在尝试按照 NXP 社区帖子中提供的示例,为 S32K3 系列 (K312) 实现待机模式。 我的项目在正常运行期间使用外部时钟源,并配置看门狗定时器。 根据文档/示例,我的理解是,在进入待机模式之前,我必须切换到使用 FIRC。 如果在进入待机状态之前切换到 FIRC 模式,看门狗定时器会触发信号,从而 RESET MCU。这是预期行为吗?此外,如果我禁用看门狗,MCU 会进入低功耗状态,但不会从唤醒源 RESET。 同时,如果我直接进入待机状态而不切换到 FIRC,看门狗不会触发信号 RESET,MCU 将进入低功耗状态,并会从唤醒源 RESET,正如人们对待机状态的预期一样。 显然,乍一看,方法 2(不切换到 FIRC)似乎有效,但我想澄清一下,因为我观察到垫子保持方面存在一些奇怪的行为。 如果在进入待机状态之前将一个焊盘切换为高电平(方法 2),无论该焊盘是否启用或禁用保持功能,MCU 进入待机状态后,该焊盘仍保持高电平。这让我怀疑MCU是否真的进入了待机状态,还是处于某种中间状态。 我知道这篇帖子写得比较笼统——请告诉我还需要提供哪些背景信息。 此致敬礼, 哈里什 Re: S32K3 STANDBY + FIRC + Watchdog 你好@Hareesh_S , 首先,在进入待机状态之前,必须将系统时钟源更改为 48 MHz 的 FIRC,因为 PLLDIG 在待机模式下不可用。如果不按此顺序操作,可能会导致时钟行为出现意外或无法预料的情况。 如果在进入待机状态之前切换到 FIRC 模式,看门狗定时器会触发信号,从而 RESET MCU。这是预期行为吗?此外,如果我禁用看门狗,MCU 会进入低功耗状态,但不会从唤醒源 RESET。 默认情况下,POR_WDG 已启用,用于监控备用机进入/退出序列,以防出现卡顿情况: 社区提供的示例也会出现这种现象吗?您是否使用RTD API来更改时钟源? S32K3 低功耗管理 AN 和演示 示例 S32K312 在待机状态下通过 CAN-0-RX 和 GPIO 开关 DS3.5 唤醒 RTD300 [RTD600 IP] S32K312EVB-Q172 待机 RAM GPIO 唤醒 如果在进入待机状态之前将一个焊盘切换为高电平(方法 2),无论该焊盘是否启用或禁用保持功能,MCU 进入待机状态后,该焊盘仍保持高电平。这让我怀疑MCU是否真的进入了待机状态,还是处于某种中间状态。 1.待机模式下,所有引脚将保持其在运行模式下的最后设置状态。 2. 默认情况下,RESET事件后所有引脚都将恢复到其默认状态。 PadKeeping 配置会影响引脚状态 在 K3 的唤醒复位和用户端口初始化之间,存在待机退出序列,在此期间引脚可能进入不可控状态: 此致, 朱利安
記事全体を表示
i.MX8MP S错误。远程进程启动 M7 核心并录制 plughw:wm8962audio,0 您好, 在 FRDM-i.MX8MP (Linux 6.12.34-lts-next) 上,在通过 remoteproc 启动 Cortex-M7 之前,wm8962 上的 ALSA 捕获工作正常。任何 M7 固件启动后,arecord 都会触发信号内核崩溃。   摘要: - 没有 M7:记录正常 - 启动 M7 后:fsl_sai_runtime_resume 出现 panic → regmap_write (SError 0xbf000002) - 使用电路板支持包。官方固件复现: - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf 所以这看起来并不局限于我们定制的M7应用程序。   复制: 1)启动Linux,保持M7停止运行。 2) arecord -Dplughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav→ 确定 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) 相同记录 → 内核崩溃 (SError)   恐慌路径(缩写): snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   已尝试: - 从 imx8mp-cm7 DT 节点中移除可选的“音频”(AUDPLL)时钟 → 仍然失败 - 在我们的 M7 clock_config 中禁用 AudioMIX 所有权/音频 PLL 初始化 → 仍然无法使用默认的 hello_world 程序运行。   问题: 1) i.MX8MP 是否支持同时使用 Linux SAI/wm8962 和 M7 remoteproc? 2) SDK BOARD_BootClockRUN() 将 AudioMIX 映射到 M7 是否与 A53 音频功率域冲突? 3) 是否有针对 AudioMIX / fsl_sai 运行时恢复 SError 的 6.12 版本已知修复方案? 4) 当音频必须由 Linux 控制时(M7 仅支持 UART/RPMSg),推荐的 M7 时钟配置是什么?   谢谢。   ------------------------- imx8mp-cm7 dts 节点 -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7" ;         rsc-da = < 0x55000000 >;         clocks = < & clk IMX8MP_CLK_M7_DIV >;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         clock-names = "core" , "uart4" ;         mbox-names = "tx" , "rx" , "rxdb" ;         mboxes = < & mu 0 1               & mu 1 1               & mu 3 1 >;         memory-region = < & vdevbuffer >, < & vdev0vring0 >, < & vdev0vring1 >, < & rsc_table >, < & m4_reserved >;         状态= "正常" ;         fsl,启动延迟毫秒= < 500 >;     };   ------------------ 崩溃日志 ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [58.448085]CPU0上的SError中断,代码0x00000000bf000002——SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448109] 已污染:[C]=CRAP,[O]=OOT_MODULE [ 58.448111] 硬件名称:NXP FRDM-IMX8MPLUS (DT) [58.448113]pstate:20000005(nzCv daif-PAN-UAO-TCO-DIT-SSBS BTYPE=--) [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [58.448138]x29:ffff8000854e3670 x28:ffff8000854e3c30 x27:0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 00000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 00000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] 内核崩溃 - 未同步:异步 SError 中断 [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448217] 已污染:[C]=CRAP,[O]=OOT_MODULE [ 58.448221] 硬件名称:NXP FRDM-IMX8MPLUS (DT) [ 58.448223]调用跟踪: [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] panic+0x168/0x360 [ 58.448258] 添加污点+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [58.448269]do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [ 58.448458] SMP:停止辅助 CPU [ 58.448464] 内核偏移:已禁用 [ 58.448466] CPU 特性:0x00,00000080,00200000,4200420b [ 58.448469] 内存限制:无 [ 58.762124] ---[ 内核崩溃结束 - 未同步:异步 SError 中断 ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 嗨@humm Q1. 是的,但前提是两者不能争夺相同的音频资源。 Q2. 是的,会有冲突。在 Linux 控制音频的情况下,M7 端必须移除 AUDIOMIX 映射以及与开机和 SAI PLL 初始化相关的代码,将 AUDIOMIX 完全交给 A53/Linux 的 audiomix_pd 管理。 Q3. 不——因为这不是 fsl_sai 驱动程序中的错误,而是资源所有权配置问题。 Q4.M7 SDK BOARD_RdcInit() — 最关键的一步:移除 SAI3/SDMA3/I2C3 的 M7 (DID1) 分配。移除分配给 DID1 的 RDC_PDAP_SAI3、RDC_MDA_SDMA3*、RDC_PDAP_SDMA3 和 RDC_PDAP_I2C3,同时保持 A53 可以访问这些资源。 B.R
記事全体を表示
PN7642 RF Debug signal如何设置 您好,请回复一下https://community.nxp.com/t5/NFC/PN7642-RF-Debug-Signals如何设置/m-p/2399084中的疑问(按照提示在CTS_TESTBUS_Signals.png中找到了模拟信号,但是并未找到数字信号,请问有完整的映射表可以提供吗?),谢谢。
記事全体を表示
CONFIG_FIT_CIPHER=y のみで hab_status が発生します サポートの皆さん、こんにちは。 CONFIG_FIT_CIPHER=yのみを設定すると、i.MX8M Plus EVK (OPENモード) でhab_statusがHAB_INV_SIGNATURE/HAB_INV_ASSERTIONを報告する。 ボード:i.MX8MP LPDDR4 EVK、オープン/非フューズ(HAB構成:0xf0、HAB状態:0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB署名:それ以外は正しく動作する — CST署名imx-boot(SPL CSF + FIT CSF)、両方の埋め込みオフセットでCSFタグバイトを検証し、不一致があればビルド失敗(必ず合格)するカスタムビルドタイムタスク 通常のHAB署名済みimx-bootでhab_status「HABイベント情報 Found!」と報告するというクリーンなベースラインがあります。最近、カーネルFITイメージ署名+AES-256暗号化を追加しました(HABとは別の仕組みで、U-Boot独自のbootmが署名済みカーネルFITの検証・復号を行い、鍵はu-boot.dtbに埋め込まれています)。SRKヒューズとは無関係です。これを有効にした後、hab_status毎回の起動で4つのイベント情報を報告し始めました: HAB 構成:0xf0、HAB 状態:0x66 HABイベント情報1:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報2:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報3:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HABイベント情報4:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY 私は、実際のハードウェアで確認しながら、一度に1つの変数ずつ、独立した再構築+再フラッシュテストを実施して、この問題を体系的に二分しました。 1. ベースライン(既存のHAB署名imx-boot、カーネルFIT作業なし):イベント情報0 2. 完全なカーネルFIT機能を有効にし(FIT pubkey/AESキーDTB埋め込み+私自身のcmd/bootm.cパッチ + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000):4つのイベント情報 3. FIT pubkey/AESキーDTB埋め込みのみ無効化:イベント情報が依然存在し、同一 4. また、私のコマンド/bootm.cも削除しましたパッチ:イベント情報は依然として存在し、同一です 5. CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000を完全に除去(真のプレカーネルFITベースライン):イベント情報0、クリーン 6. 復活は CONFIG_SYS_BOOTM_LEN=0x8000000(CONFIG_FIT_CIPHERなし):0イベント情報、クリーン 問題は正確には CONFIG_FIT_CIPHER=y に限定されており、他の要因は関係ありません (私の bootm.c)パッチ、FIT pubkey/AESキーのDTB埋め込み、CONFIG_SYS_BOOTM_LEN)単独または組み合わせでマター;CONFIG_FIT_CIPHER=yだけが0イベント情報からこの4 hab_statusに切り替わります。 私自身の CSF 計算に問題がないことを二重に確認しました。私のビルド時の署名タスクは、署名直後に両方の埋め込みオフセットの CSF タグバイトを検証し、不一致があればビルドを失敗させます。CONFIG_FIT_CIPHER の有無にかかわらず、すべてのビルドは正常にパスし、この構成に関係なく、計算された SLD hab ブロック アドレス/FIT CSF オフセットはすべてのテストビルドでバイト単位で同一です。 私の推測ではCAAMジョブリングの競合が原因です。CONFIG_FIT_CIPHER CONFIG_AESを引く(このU-Bootバージョンでは別のバックエンドシンボルは不要です)、このSoCのランタイムDMESGはCAAMが他のAES/SHAで実際に使われていることを確認しています。私が見つけた最も関連性の高いドキュメントは、doc/imx/habv4/guides/mx8m_secure_boot.txtですv4.4.0以前のHABがクローズド設定でジョブリング/DECOマスターIDレジスタをロックする点に注意が必要ですが、これはこのオープンモードのCONFIG_FIT_CIPHER特有のケースを直接説明しているわけではありません。 質問: 1.i.MX8M Plus上のCONFIG_FIT_CIPHERとHABv4のCSF認証の間に既知のやり取りがあるのでしょうか?これはCAAMリソースに関連する問題でしょうか、それとも別の問題でしょうか(例えば、コンパイルされたバイナリのサイズやレイアウトによってFIT CSFコンポーネントの境界がずれてしまい、私の自己チェックでは検出できないようなずれが生じているなど。自己チェックはROMが独自に導出したオフセットではなく、私が計算したオフセットに対して検証を行うため)。 2. このSoC上では、CONFIG_FIT_CIPHERをHABv4 CSF署名と組み合わせても安全性が確認できるのでしょうか、それともこれは実際の制限事項なのでしょうか? 3. もしそれが根本原因だった場合、正しいCAAMジョブリングの割り当て/ロック解除手順を示すヒントはありますか? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 解決済みとして投稿します。誰かが二分を省く助けになるCASEからです。実際の修正は[https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756]に感謝します。私が見つけた直後に直接適用されました。 症状:通常のHAB署名済みimxブートで、hab_status "HABイベント情報なし!"と報告するベースラインはクリーンです。CONFIG_FIT_CIPHER=yを有効にして(AES-256で暗号化されたカーネルFITイメージをU-Bootで復号するU-Bootをサポートするためで、HABとは別の仕組みでSRKヒューズとは無関係)、hab_statusは毎回のブートで4つのイベント情報(2× HAB_INV_ASSERTION、2× HAB_INV_SIGNATURE)を報告し始めました。 二分割:変更した変数を一つずつ分離し、実際のハードウェアで毎回リビルド+リフラッシュ+hab_statusを行いCONFIG_FIT_CIPHERました。(FIT pubkey/AESキーのDTB埋め込みを無効にし、無関係なcmd/bootm.cを削除)まで変更しましたパッチや保持・落CONFIG_SYS_BOOTM_LEN――どれもマターではありませんでした。CONFIG_FIT_CIPHERだけがそうした)。 根本原因+修正:手動HAB署名ワークフローを移植したカスタムYoctoタスクでimx-bootを構築しました(SPL IVTを解析し、print_fit_hab.shでFITコンポーネントブロックを計算します。CSTで署名して自動ビルドステップに組み込む。そのタスクは、mkimage_imx8 自身のビルドによってビルドステージング ディレクトリに残された DTB コピーが既に正しく 16 バイト境界にアラインされていることを前提としていましたが、すべての構成で保証されているわけではありません。CONFIG_FIT_CIPHER U-Boot本体のコンパイルされたDTBサイズを変更し、私たちの場合は非アラインサイズに設定します。ずれたDTBは計算print_fit_hab.shすべてのFITコンポーネント境界を静かにシフトするため、CSTは誤ったバイト範囲に符号化します。我々が独自に構築時に行う自己チェック(計算したオフセットにCSFタグバイトが存在するかどうかの確認)は毎回問題なく合格していた。これはROMが独自に正しく定義する境界値と照合していたわけではなかった。本物のハードウェアだけがそれを捉えた。 修正:他のThreadでうまくいったことをミラーリングします。つまり、FITコンポーネントブロックを計算する直前にDTB上で明示的にpad_image.sh(imx-mkimage独自のスクリプト)を実行し、ステージングディレクトリの既存状態を信頼するのではなく、実際にパディングされていたこと(何もしない操作ではなかったこと)が確認され、hab_statusは再びクリーンな状態になり、フル機能が有効になりました。
記事全体を表示
Secure debug on i.MX93 with NXP keys The current version of the nxpdebugmbox tool from the SPSDK has a parameter --nxp-keys that is described as "Use the ROM NXP keys to authenticate." Does this mean that NXP can unlock secure debug on all devices? If yes, is there any fuse to restrict secure debug to the OEM SRK keys? Security Re: Secure debug on i.MX93 with NXP keys But if you have control over the ELE, you have access to the DDR memory and can monitor the inputs and outputs of all crypto operations requested by the OEM domain from the ELE domain. You can decrypt all ELE blobs and have therefore access to all secret data stored on the device. And unless writing to DDR memory is prevented, you can inject code into the OEM domain. Re: Secure debug on i.MX93 with NXP keys Hello, No, NXP cannot unlock secure debug on OEM devices with --nxp-keys. The --nxp-keys flag only authenticates the NXP/ELE internal debug domain (using ROM-embedded NXP keys). The OEM SoC debug domain (Cortex-A55, M33, etc.) is completely separate and can only be unlocked with the OEM's own SRK keys. No additional fuse is needed to enforce this, it is architectural by design. Once the device is in OEM_CLOSED lifecycle with the OEM SRK hash fused, the ELE hardware enforces that NXP keys have zero authority over the OEM debug domain. Best regards/Saludos, Aldo.
記事全体を表示