NVMキーカタログに保存されているECC公開鍵のSHA-512に関する質問 NXPエキスパート様、 HSEの鍵マネジメント機能について質問があります。 私たちは HSE-B を搭載した S32K312 を使用しており 、 ECC公開鍵 を NVMキーカタログ に 保存しています 。 私たちのアプリケーションでは、NVMキーカタログに保存されているECC公開鍵の SHA-512ハッシュ を取得する必要があります。 キーを保存した後、 SHA-512ハッシュ を比較することで、キーが正しく保存されていることを検証します 。 例： Kを NVMキーカタログに格納されているECC公開鍵とする 。 SHA-512(K) の値を取得したいです 。 HSEは、NVMキーカタログに保存されているキーのSHA-512ハッシュを取得するためのAPIまたはメカニズムを提供していますか？ そうでない場合、カタログに保存されているキーのSHA-512(K)を計算または検証するための推奨される方法はありますか？ 再開まで今しばらくお待ちください。 Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog わかった。サポートありがとうございます Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog こんにちは、@NghiaLX308さん ユーザーがSHA-512をキーマテリアルに直接実行できるAPIはありません。 回避策として、ECC公開鍵をエクスポート(サービスHSE_SRV_ID_EXPORT_KEYを使い)、その後SHA-512操作(サービスHSE_SRV_ID_HASHを使って)実行できます。ECC公開鍵は秘密ではないため、平文でエクスポート可能です。暗号化または認証された形式でエクスポートする必要はありません。 よろしくお願いいたします。 ルーカス

PNEV5190Bは動作しません NFC CockpitのExtraタブにある「Load Secondary Firmware」オプションからNfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.binをロードした後、PNEV5190Bが反応せず、NFC Cockpitから操作できません。 アップデートログによると、ファームウェアのダウンロードはエラー報告もなく正常に完了しました。アップデートが完了した後、ボードが応答しなくなった。 このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 ファームウェアのアップデートが成功したにもかかわらず、なぜ基板が反応しなくなるのでしょうか? 私のボードまたはファームウェアのバージョンに対して、間違ったセカンダリファームウェアイメージを使用した可能性はありますか？ なぜセカンダリファームウェアをロードすると、NFCコックピットがボードと通信できなくなる状態になるのでしょうか? 再開まで今しばらくお待ちください。 Re: PNEV5190B does not work こんにちは、 @Miyazaki001さん あなたの調子が良いといいのですが。 あなたのセットアップについてもう少し詳しく教えていただけますか?どのような手順に従っていますか？ 私は以下の設定を試してみました。 - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - 「追加」タブ > 「セカンダリファームウェア」タブ > セカンダリファームウェアのロード - NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin を選択してください NFC Cockpitは、COMポートを閉じてから再度開くように指示するはずです。 EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png COMポートを再度開いた後、「Extra」タブでセカンダリファームウェアを起動できるようになります。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 私のシステム構成は以下のとおりです。 - PNEV5190B（B1チップ） - PN5190 FW v02.05 - NFC Cockpit v7.4 - 追加タブ → セカンダリファームウェア → セカンダリファームウェアのロード 選択済み: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次ファームウェアアップデートは正常に完了したようです。ログによると、ファームウェアのダウンロードはエラー報告なしに完了した。 ログの該当箇所を以下に示します。 20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png アップデート後、NFC Cockpitからボード接続を手動で閉じてから再度開くように指示されます。私はこの手順に従い、さらにCOMポートを手動で切断して再接続することも試しました。 しかし、接続を再開した後、ボードはどのコマンドにも応答しなくなった。ログには、NFC Cockpitがボードとの通信を試みた際にタイムアウトが発生したことが記録されている。 参考までに、関連するログファイルを添付しました。 何かアドバイスをいただけますか: PN5190 FW v02.05は、このセカンダリファームウェアと互換性がありますか？ NFC Cockpit v7.4とこのセカンダリファームウェアに関して、既知の問題はありますか？ このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、 この特定のセットアップで予期せぬ挙動が記録された例を見つけることはできませんでした。 NFC Cockpit v7.4.0は旧バージョンです。最新バージョン（v9.0.0）にアップデートし、PN5190のファームウェアアップデートを実行してください。その後、あなたの調査結果を教えてください。 設定を更新した後もこの症状が続く場合は、ジャンパーの設定と電源接続についてお知らせください（基板の写真も添付していただけると助かります）。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 お客様からのご意見に基づき、NFC Cockpitのバージョンを最新バージョンであるv9.0.0に変更いたしました。また、PN5190のファームウェアをv02.05からv02.0D（NXPのウェブサイトで入手可能な最新バージョン）にアップデートし、セカンダリファームウェアのアップデートを再試行しました。 しかし、結果は同じで、問題は依然として解決されていない。 画像.png画像.png画像.png画像.png画像.png画像.png画像.png画像.png 参考までに、ボードの写真も添付しました。 画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg 以下のジャンパー設定が使用されます。 J8：閉鎖 J9：2-3（外部電源） J12：閉鎖 J22：閉鎖 J23：閉鎖 このテストでは、電流制限が1Aの外部5V DC電源を使用します。 他に確認すべき設定や項目があればお知らせください。 Re: PNEV5190B does not work こんにちは、 ジャンパー設定と電源構成は問題ないようです。 もしかして、デモ用のアプリケーション(例:)をフラッシュして実行することはできますか?PN5190の NFCリーダーライブラリ で提供されているDiscoveryLoop?詳細 PNEV5190B評価ボードクイックスタートガイド、第5.3章を参照してください。 追加のテストとして、別のPCとシステム言語(ディスプレイだけでなく)を英語に設定してみていただけますか? よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、 評価ボードのクイックスタートガイドのセクション5.1 PNEV5190B述べているように、最新のNFCコックピットを使用してファームウェアの最新バージョンにアップデートすることが推奨されています。ファームウェアプログラミングには外部デバッガが必要であり、 これはNXP NFCコックピットユーザーガイド3.3節に記載されています。 残念ながら、ブートローダーバージョンとセカンダリFWバージョン間の正式な互換性マトリックスを提供する文書は存在しません。最も近い参照は 、VCOMソースパッケージ 内の バージョン変更ログ(NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h)です。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 ご提案いただいた方法を別途試してみます。 その間、弊社側でも追加のテストを実施し、以下の結果を得ました。 まず、J-Linkを介してNFC Cockpit v9.0.0に付属する以下のファームウェアをプログラムしました。 BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin その後、NFC Cockpitを使用して以下のセカンダリファームウェアをアップデートしました。 Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin この手順により、以前発生していたエラーは発生せず、アップデートは正常に完了しました。 この結果に基づき、ブートローダーとセカンダリーファームウェアのバージョン間に互換性の依存関係が存在する可能性があると推測されます。 以下の点について説明していただけますか? 1.NFC Cockpitのバージョンを変更する場合、セカンダリファームウェアだけでなく、ブートローダーも互換性のあるバージョンにアップデートする必要がありますか？ 2. NFC Cockpitを使用してブートローダーをアップデートする方法はありますか？ それとも、ブートローダーをアップデートするには、J-Linkのような外部デバッガー／プログラマーが必要なのでしょうか？ 3. 各NFCコックピットバージョンに付属するセカンダリファームウェアとブートローダーの互換性を説明するドキュメントはありますか? 例えば、どのバージョンのセカンダリファームウェアが同じブートローダーで使えるか知りたいです。 これらの疑問の背景には、私たちが解決したいと考えている別の問題も存在します。 私たちはNFC Cockpitではなく、COMポートを通じたシリアル通信を使って自社のアプリケーションからPNEV5190Bを制御しています。 NFC Cockpit v7.4.0に付属するセカンダリファームウェアを使用すると、アプリケーションはPNEV5190Bと正常に通信し制御できました。 しかし、NFC Cockpit v9.0.0に含まれるセカンダリファームウェアにアップデートした後、同じ通信方法で同じアプリケーションが通信エラーに遭遇します。 次の点についても説明していただけますか? 4. NFC Cockpit v7.4.0とv9.0.0に付属するセカンダリファームウェアの間で、初期化シーケンス、COM通信設定、通信プロトコル、コマンド仕様、または関連する動作に関して変更点はありますか？ これらの変更を説明したリリースノートやドキュメントがあれば、ぜひ共有していただけるとありがたいです。 Re: PNEV5190B does not work こんにちは、 VCOMファームウェアは、弊社のNFCコックピットツールとの併用を想定しています。別のツール用のカスタム実装を作成しようとしている場合は、 NFC Cockpit VCOMのソースコードを参考にして、ニーズに合わせて修正することを検討してください。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご説明いただきありがとうございます。 ブートローダーを含むファームウェアのプログラミングには、外部デバッガーが必要であることを理解しています。また、BootLoaderとセカンダリファームウェアのバージョン間には正式な互換性マトリックスがなく、VCOMソースパッケージ内のバージョン変更ログが最も近い参照であることも理解しています。 他に言及した問題については、BootLoaderとセカンダリファームウェアをNFC Cockpit v9.0.0.0に更新した後、アプリケーションが正しく通信できなくなったため、追加調査を行い、DTRの取り扱いに関する違いを発見しました。 念のため説明すると、 私たちのアプリケーションは以前、NFC Cockpit v5.3に含まれるBootLoaderとセカンダリファームウェアを使って動作しており、v7.4ではありませんでした。 NFC Cockpit v5.3にBootLoaderとセカンダリファームウェアが付属しているため、COMポートを開いた後もDTRを静的にONに保つだけで、DTRの状態移行を明示的に行わずに正常に通信できました。 しかし、NFC Cockpit v9.0.0.0 に含まれる BootLoader と Secondary Firmware では、DTR を ON にするだけでは不十分です。ボードは、DTRをLOWからHIGHに明示的に切り替えた後にのみ応答を返すことがわかりました。この移行は、通信セッションの開始時に少なくとも一度は必要となるようだ。 Wiresharkを使用してUcBalPCTestApp.exeによって生成されたUSB通信をキャプチャおよび分析することにより、このDTR操作を特定しました。 以下の点について説明していただけますか? PN5190 VCOM ファームウェアにおいて、DTRのLOWからHIGHへの遷移は、通信セッションの初期化や内部バッファプロセッシングなどの内部プロセッシングのトリガーとして使われていますか?もしそうなら、この挙動はどこかで記録されていますか? VCOMファームウェアのバージョン間で、このDTRの動作が変更された可能性はありますか？特に、NFC Cockpit v5.3とv9.0.0.0に含まれるバージョン間で、DTR処理に関して何か変更はありましたか？ ホスト側でDTRをLOWからHIGHに明示的に切り替えることなく通信を開始するための、公式に推奨されている方法はありますか？例えば、特定のIOCTL、ベンダー固有のコマンド、またはその他のメカニズムなどです。 改めてサポートありがとうございます。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご説明とサポートありがとうございます。 NFCコックピットとアプリケーションの両方で同じセカンダリファームウェアを使いたいと考えています。 したがって、NFCコックピットVCOMのソースコードを参照し、現在のVCOMファームウェア動作をサポートするようにアプリケーションを修正します。 改めてサポートありがとうございます。 よろしくお願いします、 宮崎

PTP over SJA1110 您好， 我们正在调试通过 SJA1110 交换机连接的 PolarFire SoC GEM 上的 PTP。 我们观察到： 交换机接收到二层 PTP (ptp4l -2) 数据包（入口计数器增加），但未转发（出口计数器不增加）。 通过 UDP 的 PTP（ptp4l）通过同一桥接路径正确转发。 正常的以太网流量（ICMP/ARP）也能正确转发。 SJA1110 是否需要特殊处理或额外配置才能通过桥接端口转发第 2 层 PTP 帧（目标 MAC 01:1B:19:00:00:00）？对二层点对点传输协议（PTP）的转发是否存在任何已知的限制？ 另外，PolarFire SoC GEM 是否完全支持并推荐使用 PTP over UDP (ptp4l)，还是只支持/推荐使用 第 2 层 传输？ 任何指导都将不胜感激。 Re: PTP over SJA1110 你好@Ankur_pixl ， 在典型的 gPTP/时间感知桥接应用场景中，交换机无需将所有 gPTP 帧透明地转发为普通组播流量。通常的流程是，交换机从主控服务器接收 gPTP 帧，通过运行在内部 Cortex-M7 上的 gPTP 协议栈进行处理，然后生成带有相应时间戳的 gPTP 帧，发送给连接的下游设备。   SJA1110 通常配置为第 2 层汽车配置文件，其中 PTP 目标 MAC 地址为 01:80:C2:00:00:0E。此地址用于 802.1AS/gPTP 风格的第 2 层传输，此类帧通常由交换机的 PTP/gPTP 功能处理，而不是简单地作为常规组播流量进行桥接。   你观察到入口计数器增加，而出口计数器没有增加，这表明交换机接收到了第 2 层 PTP 帧，但没有通过正常的桥接路径转发。一个可能的解释是，所使用的 PTP 组播 MAC 地址与 SJA1110 配置相匹配，例如在通用参数表、DPI 配置、L2 查找表或其他与 PTP/trap 相关的配置项中，因此帧被捕获到主机端口，很可能是内部 Cortex-M7 主机，而不是转发到预期的外部出口端口。   这也解释了为什么 PTP over UDP 和 ICMP/ARP 等普通以太网流量能够正确转发。这些帧不符合相同的第 2 层 PTP/gPTP 分类规则，因此按普通桥梁交通处理。   请检查您的 SJA1110 配置中的以下几点：   1. 交换机中配置了哪个 PTP 目标 MAC 地址，尤其是在常规参数表中。 2. PTP/gPTP 帧是否配置为捕获到主机端口。 3. 内部 Cortex-M7 主机是否正在运行 gPTP 协议栈或接收捕获的 PTP 帧。 4. 使用的目标 MAC 地址是 01:1B:19:00:00:00 还是 01:80:C2:00:00:0E。 5. L2 查找表或组播转发配置中是否包含将此目标 MAC 转发到所需外部端口的条目。 6. 此流量的入口端口和出口端口是否在同一个 VLAN 和转发功能域中。   如果您打算将 SJA1110 用作 gPTP/时间感知桥接器，那么预期的配置通常不是简单地透明转发原始 gPTP 帧。交换机应参与 gPTP 时序域，并向连接的设备生成相应的 gPTP 消息。   如果您打算仅将 SJA1110 用作普通的以太网桥，用于原始的二层 PTP 帧，则必须禁用或避免此流量的 PTP 捕获/特殊处理，并且必须在二层转发配置中明确允许相应的组播目标 MAC 地址。   关于 PolarFire SoC GEM，我无法就该设备推荐或完全支持的 PTP 传输模式做出明确的声明。从 SJA1110 的角度来看，如果桥接路径允许，则 PTP over UDP 可以作为普通的 IP/UDP 流量转发。然而，这并不一定意味着 PolarFire GEM 驱动程序支持或推荐使用 UDP 传输进行硬件时间戳。请参考 PolarFire SoC GEM 文档或咨询 Microchip 支持部门，确认支持的 PTP 传输和时间戳模式。   顺祝商祺！ 帕维尔 Re: PTP over SJA1110 你好， 目标 MAC 地址为 01:1B:19:00:00:00。我们正在使用带有 Linux DSA 桥接器的交换机，并且无法控制或配置 Cortex-M7 内核。 在 L2 配置中，我们如何允许此流量通过？我们使用了桥接 mdb，但它不起作用；条目已安装，甚至显示为已卸载，但帧仍然无法在端口之间转发。这是否需要在 Cortex-M7 内核上显式设置？ 关于我们设置的其他信息： 我们的MAC地址/端口配置如下： bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent 这些在 bridge -d mdb show 中显示为已卸载，但到达一个端口的 L2 PTP 帧不会从另一个端口转发出去。 重要的是，其中一个交换机端口没有可用的 CPU 端口；它纯粹作为两个端口之间的路由（端口到端口转发）运行，该路径上没有主机/CPU 端口。由于保留的多播 01:1b:19:00:00:00 默认似乎被捕获到管理/CPU 路由，而该路由在此处不可用，因此我们怀疑帧被丢弃而不是转发。 请问如何配置交换机，使其能够在两个用户端口之间通过硬件转发此保留的 PTP 组播 MAC 地址，而无需依赖 CPU/管理端口？ ——安库尔 Re: PTP over SJA1110 你好@Ankur_pixl ， 目标 MAC 地址 01:1B:19:00:00:00 是 IEEE 1588 二层 PTP 组播地址。这与 802.1AS / 汽车配置文件 gPTP 目标 MAC 地址 01:80:C2:00:00:0E 不同，后者通常用于 SJA1110 gPTP 汽车配置文件。   根据您的描述，这看起来不像是一个标准的 Linux 网桥 MDB 问题。MDB 条目可能已正确安装，甚至报告为已卸载，但帧仍然可能无法到达正常的组播转发路径。   一个可能的解释是，SJA1110 硬件或 SJA1110 DSA 驱动程序在应用正常的 L2 组播转发决策之前，将此目标 MAC 分类为 PTP/控制帧。在这种情况下，帧可能会被重定向到 CPU/管理路径，而不是直接在两个用户端口之间转发。   这可以解释观察到的现象：   - 入站计数器增加，表示交换机已接收到该帧。 MDB条目已安装并显示为已卸载， 但出口计数器不会增加，因为帧很可能在应用正常的端口到端口转发之前就被困在了 CPU/管理路由中。   如果 CPU/管理路由在端口到端口的转发路径中不可用，则捕获的帧可能会被有效地丢弃。   关于 Cortex-M7：如果您通过 Linux DSA 网桥使用交换机，并且您没有在内部 Cortex-M7 上运行或控制 gPTP 协议栈，那么这通常不应该是 Cortex-M7 应用程序配置的内容。在这种情况下，相关的配置由 Linux DSA 驱动程序和该驱动程序编程的交换机硬件配置所有。   但是，如果针对 01:1B:19:00:00:00 激活了专用的 PTP/控制帧陷阱规则，则“桥接 mdb”可能不够用。要通过硬件直接在两个用户端口之间转发此流量，交换机配置需要确保：   1. 针对此流量，01:1B:19:00:00:00 的 PTP/控制帧陷阱已被禁用或绕过，并且 2. 存在指向所需用户端口的 01:1B:19:00:00:00 的有效 L2 组播转发条目。   此时，如果 SJA1110 DSA 配置中存在激活的较低级别的 PTP/控制帧陷阱规则，我预计仅使用标准的 `bridge mdb` 命令无法覆盖该规则。   下一步，请检查您的 SJA1110 DSA 驱动程序或 BSP 是否启用 PTP 硬件时间戳，或者是否为 01:1B:19:00:00:00 安装任何 MAC 过滤器/PTP 陷阱规则。如果存在这样的规则，则解决方案可能需要驱动程序级别的更改或交换机静态配置更改，而不仅仅是运行时 Linux 网桥 MDB 命令。   请问您能否提供以下信息？   - Linux 电路板支持包。/内核版本， - SJA1110 DSA 驱动程序源基线， - “bridge -d mdb show”的完整输出， - 相关DSA端口名称和物理交换机端口号， - SJA1110 DSA 驱动程序中是否启用了 PTP 硬件时间戳功能， - 如果可能的话，在 DSA 主/CPU 接口上进行数据包捕获，以确认第 2 层 PTP 帧是否被捕获到 CPU 路径。   有了这些信息，我们可以进一步检查帧是否被 PTP/控制陷阱路径消耗，或者是否存在其他 L2 组播转发限制。 顺祝商祺！ 帕维尔

AB_SWAPアップデート失敗時のフォールバックメカニズム こんにちは、 私たちは、S32K342のHSEファームウェアのAB_SWAPメカニズムを利用してOTAアップデートを行うアプリケーションを開発しています。現在、フラッシュメモリのパッシブ領域への書き込みが完了した時点で、パッシブブロックをアクティブ化するように設定しています。 起動元イメージが破損していないか確認できるフォールバックの仕組みがあるのか、またリセット後にパッシブ領域になった「既知の有効」領域にフォールバックできるのか知りたいです。 これは、時にはリセットを出さずにパッシブ領域を上書きし、途中でプロセッサをリセットしてしまい、フラッシュの映像が破損してしまうことがあるためです。 Re: Fallback mechanism for failed AB_SWAP update やあ、 @lukaszadrapa 、 ご説明ありがとうございます。私たちはまだ、アプリケーションでどのタイプのセキュアブート戦略を使うべきかを理解しようとしています。高度なセキュアブートは、SMRとCRをインストールする必要があるため、少し複雑に思える。 一方、ベーシックセキュアブートはインストールがやや容易なようだが、具体的な実装方法やインストール手順は不明瞭なようだ。 これらの選択肢について何かアドバイスをいただけませんか?私はHSE Bリファレンス・マニュアルを指しており、これに関して参照すべき追加ドキュメントがあるかどうかも知りたいです。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update こんにちは、 @Shiv_peak さん。 数日前に非常によく似た質問に回答しましたので、そちらをご覧ください。 https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125 さらに詳しい情報が必要な場合は、遠慮なくお申し付けください。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update 下記の私のコメントをご覧ください。 イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 はい。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 はい。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 UTESTは、設定属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDサービスを呼び出す際にHSEによってプログラムされます。共通の問題は、フラッシュブロック0とUTESTが同じ読み取りパーティション内にあることに注意することです。この属性をプログラムする際、フラッシュブロック0からはコードが実行できません。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 はい。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 はい。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? はい、ADKPが設定されるまでライフサイクルを進めることはできません。ライフサイクルが進んだらセキュアデバッグが有効になるので、接続を確立するためにデバッガの設定が必要です。この投稿をご覧ください: https://community.nxp.com/t5/S32K/S32K3-HSE/m-p/2066312/highlight/true#M47070 ライフサイクルの状態はDCMモジュールのレジスタDCMLCCから読み取ることができます。 AppBLは、Basic Secure BootにおけるIVTと同じものですか？ AppBLとIVTは同じ方法で署名・検証されます。IVとGMACもIVTに付録されています。それは「表118」で見ることができます。 HSEファームウェアリファレンスマニュアルの「IVT構造」と記載されています。 IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか？ IVTを検証する場合は、前述のとおりIVとGMACをIVTに追加する必要があります。セキュアリカバリイメージを使用する場合は、イメージへのポインタとイメージの長さをIVTに追加する必要があります。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update ルカスさん、返信ありがとうございます。おかげでよく分かりました！Basic Secure Bootの実装を始め、ご質問やご不明点があればご連絡いたします。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 「2.6.1.3」の項をご覧ください。HSEファームウェアのリファレンスマニュアルに記載されている「リカバリーモード」と記載されています。2.7. つまり、2つのモードがあります。 JTAGベースのリカバリーモードでは、デバイスはRAM上で無限ループにハングする(このコードはSBAFによってRAMにロードされます)。ユーザーがデバッガに接続していくつかのリカバリーステップを実行できます。 セキュアリカバリーモード - これは属性 HSE_SECURE_RECOVERY_CONFIG_ATTR_ID によって有効にする必要があります。これはUTESTメモリにプログラムされたOTP属性であることに注意してください。これによりリカバリイメージが起動しますが、まずこれを検証する必要があります。つまり、基本的なセキュアブートに似ています。検証に失敗した場合は、JTAGリカバリモードに移行します。 セキュアリカバリモードは実行時のリカバリーやロールバックに使用できます。しかし、パッシブパーティションからこれを実行することはお勧めしません。すべてのコードはアクティブパーティションから実行される必要があります。ABスワップモードでは、いずれにせよ両方のパーティションにセキュアリカバリイメージのコピーが存在します。 別の選択肢としては、十分な空き容量があれば、このコードをデータフラッシュメモリに保存する方法もあります。 Re: Fallback mechanism for failed AB_SWAP update 私たちはこのアプリケーションノートを提供します: https://www.nxp.com/webapp/Download?colCode=AN13465   Secure Bootアプリケーションノートの最新バージョンv0.1.1.0です(AN744511)2021年にリリースされ、以下からダウンロード可能です: https://www.nxp.com/products/S32K3 申請書はこちらでご覧いただけます: ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511) 関連するデモプロジェクトはこちらからダウンロードできます: Design Resources - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310) ソフトウェアは更新されていないので、 興味があれば前述SW745310を使ってください。 セキュアブートの他の例は、HSEデモ例(推奨)で見つけることができます: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 高度なセキュアブート、基本的なセキュアブート、およびSHEセキュアブートの3つのモードすべてについて例があります。 一般的に、高度なセキュアブートモードが推奨されます。はい、このモードでセキュアブートを設定するのは簡単な作業ではありません。しかし、最高の保護性能と設定の柔軟性を提供します。利点は、好きな署名方式を選べ、複数の地域をカバーでき、セキュアブートが失敗した場合に異なる制裁を設定できることです。 一方、基本的なセキュアブートモードは常にGMACタグのみを使用し、これはADKPから派生したキーで計算され、1つの地域のみをカバーできます。失敗した場合、デバイスは直接リカバリーモードに移行します。 HSE DemoExamplesに掲載されている以下のプロジェクトを学習することをお勧めします。 S32K344_アドバンストセキュアブート S32K344_ベーシックセキュアブート これらは、それらにリンクされたアプリケーションS32K344_SecureBootBlinkyを保護するための構成プロジェクトです。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update なるほど、これでよく分かりました。ありがとうございます！ 私の理解では: イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? AppBLは、Basic Secure BootにおけるIVTと同じものですか？ IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか？ 実装と基板上でのテストを開始する前に、これらの点についてもう少し明確な情報を得たいと思っています。ご連絡いただき、疑問を解消してくださり本当にありがとうございます! よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update ルーカスさん、分かりやすく説明してくれてありがとう。 I will look into the アプリケーションノート and the HSE demo examples and revert back in case of any queries. よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 基本的なセキュアブートが失敗した場合に「デバイスがリカバリーモードに入る」とはどういう意味か、もう少し詳しく教えてもらえますか?これはつまり、コアはリセットから解放されず、フォールバックやリカバリーも存在しないということですか? セキュアブートが失敗した場合に、別のイメージ（おそらくパッシブバンクにあるイメージ）を起動する機能を持たせたいので、この質問をしています。

S32K3 快速备用唤醒失败 你好， 在一个快速备用示例项目中，我定义了一个数组 编曲 在 .standby_data 虽然代码中包含这个数组，但它在代码中并没有被使用。然而，如果我注释掉这个数组定义，设备就无法从快速待机状态唤醒；如果我保留它，唤醒功能就能正常工作。此外，我还注意到优化级别也会影响设备的行为： -O0 优化失败，唤醒失败，但正在更改为 -Os 这样就能解决问题。为什么在……中定义变量会起作用？ .standby_data 该部分是否会影响唤醒功能？为什么优化级别会产生如此大的影响？ Jason22_0-1785895168596.png S32K312 RTD400 S32DS BR， 杰森 Re: S32K3 fast standby wake up fail 嗨@Senlent 非常感谢您的回复。将地址更改为 0x20408000 后，之前失败的案例现在可以正常工作了。 顺便说一下，关于我的另一个帖子（S32K3 ADC Optimize DMA Streaming），我用公司邮箱注册的新账号（Jason07）回复了你——回复的时候我忘记切换账号了。 Re: S32K3 fast standby wake up fail 嗨@ Jason22 程序中是否注释掉“arr”数组会影响__BSS_SRAM_START的值，该值将用作快速唤醒后MSP的初始值。 如果这个值太小，可能会导致堆栈溢出。 在我们的示例项目中，我们建议将此值设置为 0x20408000，这是备用 RAM 的结束地址。

S32K144のPWM周波数が周期的に変化する問題について。 現在、NXP S32K144 の開発を行っており、問題が発生しました。EB 構成ツールを使用して、FTM0 の 4 つの出力チャネルを構成し、コード内で `PWM_Init();setdutycycle(8129)` を呼び出しました。構成では、中央揃えモード、デッドタイムなし、他のチャネルとのバインディングなしを選択しました。周期は 0.00125 に設定され、各チャネルは独立モードとなり、結果として 250µs%的方波，这显然不对，我希望是25% のデューティサイクルが 20% になりました。そこで、デューティサイクルを `setdutycycle(16339)` に変更しましたが、結果として波形が正しくなくなりました。チャネルは、デューティサイクル 66% の 150µs の矩形波と、デューティサイクル 50% の 100µs の矩形波を交互に出力します。なぜこのようなことが起こるのでしょうか。これが実際の波形です。 実際、私には2つの問題があることは明らかです。1. なぜPWMデューティサイクルが正しく動作しないのか？ 2. なぜPWMサイクルが常に変化するのか？ Re: 关于S32k144的pwm频率会周期变化的问题 こんにちは S32K1用リアルタイムドライバのどのバージョンをテストしているのか、またはS32K1デバイス用AUTOSAR MCALのどの以前のバージョンをテストしているのか教えてください。 MPC5xxxおよびS32K1xxデバイスに対するMCALのサポートは終了いたしましたのでご注意ください。今後のサポートにはマーケティングチームの承認が必要となりますので、NXPの営業担当者までお問い合わせください。 よろしくお願いします、 ロビン Re: 关于S32k144的pwm频率会周期变化的问题 お使いのソフトウェアのバージョンがわからないのですが、読み込みポイントの設定に注意してください。以下の2つのディスカッションを参照してください。 FTM_PWMの周期とデューティサイクルを変更する S32K116のPWM出力の問題

Feedback on UI editor bugs in GUI Guider v2.0.0 I encountered several bugs while using GUI Guider v [your version number] that affected development efficiency, and I would like to report them to the development team: Drag and drop layouts, resulting in layout loss: When I drag controls in the UI editor to adjust the layout, the operation occasionally fails, and the latest layout changes are lost, causing the interface to revert to its previous state. Duplicate and unremovable control names: During operation, sometimes multiple controls with identical names may appear, and these controls cannot be deleted via the right-click menu or the Delete key. The only solution is to log back into the software; only then will these "ghost" controls disappear.

无法下载 S32K3 标准软件 无法下载 V1_0-1785824291602.png Re: Not able to Download S32K3 Standard Software 你好， 我刚刚下载好了，没有任何问题。尝试使用不同的浏览器，清除cookies等等…… 下载本身在NXP端运行正常。 顺祝商祺！ Peter

LPC5514JBD64E 用于 WS2812。 您好， LPC5514JBD64E 适合初学者使用 WS2812 吗？如果适合，我可以在哪里找到代码和其他详细信息？ 谢谢！ LPC55xx Re: LPC5514JBD64E Use for WS2812. 嗨@Kishore02 感谢您的帖子！ 目前尚无关于 LPC551x 上 WS2812 实现的信息，您可以使用可编程逻辑单元 (PLC) 来实现。在其他设备中，有使用 FlexIO 模块的示例，例如 MCXA366 的应用代码中心： https://mcuxpresso.nxp.com/appcodehub ?search=an-emulating-ws2812-bus-with-flexio-on-mcx366 此外，一位同事还发布了一篇关于如何在 Kinetis 开发板上实现该协议的文章： NXP FlexIO Generator for the WS2812B LED Stripe Protocol 希望这些信息对您有所帮助。

S32DSライセンスのアクティベーションID こんにちは。S32DSを開いたところ、以下の情報が表示されました。 Arm用のS32 Design Studio アクティベーションID: 1A99-90A8-2F06-339B 評価期間：14日間 機能バージョン: 2.2 機能ステータス：評価中（14日間） 免許証の有効期間を延長するには、どのような手続きが必要ですか？ビジネスの成功をお祈りしています！ 回复： S32DS license ActivationId アクティベーションID: 1A99-90A8-2F06-339B 利用期間の延長と有効化にご協力をお願いいたします。ありがとうございます。 Re: S32DS license ActivationId こんにちは、 お客様のS32DSライセンスが延長されました。以前のコードを使用して、S32DSを再度有効化してください。

S32K3標準ソフトウェアをダウンロードできません ダウンロードできません V1_0-1785824291602.png Re: Not able to Download S32K3 Standard Software こんにちは、 問題なくダウンロードできました。別のブラウザを試したり、Cookieを削除したりするなどしてみてください。 ダウンロード自体はNXP側で正常に動作しています。 よろしくお願いいたします。 ピーター

GUI Guider v2.0.0におけるUIエディタのバグに関するフィードバック GUI Guider v [お使いのバージョン番号]の使用中に、開発効率に影響を与えるいくつかのバグに遭遇しましたので、開発チームに報告したいと思います。 ドラッグアンドドロップによるレイアウトの消失：UIエディタでコントロールをドラッグしてレイアウトを調整すると、操作が時々失敗し、最新のレイアウト変更が失われ、インターフェースが以前の状態に戻ってしまいます。 重複した削除不可能なコントロール名：操作中に、同じ名前のコントロールが複数表示されることがあります。これらのコントロールは、右クリックメニューやDeleteキーでは削除できません。唯一の解決策は、ソフトウェアに再度ログインすることです。そうすれば、これらの「ゴースト」コントロールは消えます。 Re: 关于GUI Guider v2.0.0的UI编辑器Bug反馈 こんにちは、 @CN10086さん 貴重なご意見をお寄せいただき、誠にありがとうございます。 スクリーンショット、動画、再現手順などの追加情報があれば大変ありがたいです。 BR ハリー

LPC5514JBD64EはWS2812用です。 こんにちは、初心者LPC5514JBD64E WS2812の扱いに適していますか?もしそうなら、コードやその他の詳細はどこで入手できますか? よろしくお願いします。 LPC55xx Re: LPC5514JBD64E Use for WS2812. こんにちは、@Kishore02さん 投稿ありがとうございます！ LPC551x向けのWS2812の実装については情報がありませんが、プログラマブルロジックユニットを使うことができます。他のデバイスでは、アプリケーションコードハブのMCXA366 https://mcuxpresso.nxp.com/appcodehub?search=an-emulating-ws2812-bus-with-flexio-on-mcx366  また、Kinetisボード向けに実装した同僚の投稿もあります:NXP FlexIO Generator for the WS2812B LED Stripe Protocol( LED Stripe Protocol) この情報が参考になれば幸いです。

「MPC5777C-1b+2b_RAM_ECC_error_injection GHS614」のサンプルコードについて こんにちは。現在、MPC5777C MCUを基に開発中です。 開発プロセスに関して質問があります。 「MPC5777C-1b+2b_RAM_ECC_error_injection GHS614」というサンプルコードを基に、ECCチェックを実行するコードを設計しました。 通常の状況下では、このコードはECCチェックを正しく実行します。 しかし、MCUに接続されたTrace32のようなデバッガでECCチェックコードを実行すると、ビット誤りが検出されないエラーが頻繁に発生します。 「GHS614」例コード全体が、Trace32のようなデバッガに接続したときに正しく動作しない可能性はありますか? よろしくお願いします。 Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 Trace32デバッガが接続されていてダンプウィンドウが開かれ、カスタムアプリケーションコードが実行されていると仮定すると、GHS614を参照して設計されたECCチェック機能内でビットエラーが検出されないケースが発生する可能性はありますか? Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 あなたのシステム構成がどのようなものかは分かりませんが、トレースで開いているダンプウィンドウは常にメモリを読み取っており、ECC障害が検出されるとすぐに発生することに注意してください。 破損していないアドレスでは、ECCエラーは決して発生しません。ECC機構もEDCによって保護されている。それは到底不可能なことだ。 よろしくお願いいたします。 ピーター Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 ソフトウェアまたはデバッガによって読み取られるアドレスが破損している場合、例となるソフトウェアやその他の影響に関係なく、ECCは常に上昇します。 よろしくお願いいたします。 ピーター Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 状況をもう少し詳しく説明します。 私のECCチェックコードの実行手順は以下のとおりです。 (void)FCCU_ClearNCF(); /* 1ビットRAMデータエラー注入 */ GenerateRam1bitEccError(); uiErmSR0 = ERM.SR0.R; uiErmSR1 = ERM.SR1.R; uiErmSR2 = ERM.SR2.R; /// 4. RAM 1ビットECCエラーが発生した場合は、以下を実行します。 if((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR)) { /// 4.1.ERM EARレジスタに格納されている値が、エラーが発生したアドレスと同じである場合は、以下の手順を実行してください。 if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R)) { ucStatus = OK; } /// 4.2.ERM EARレジスタに格納されている値が、エラーが発生したアドレスと一致しない場合は、以下の手順を実行してください。 そうでなければ、(UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R) の場合 { ucStatus = OK; } そうでない場合、 { ucStatus = NOT_OK }; } /// 5.RAM 1ビットECCエラーが発生しなかった場合は、以下の手順を実行してください。 そうでない場合、 { ucStatus = NOT_OK }; この構造は、1ビットのRAMデータエラーを強制的に挿入し、ECCエラーが正常に発生したかどうか、および発生アドレスが正確に検出されたかどうかを確認します。 上記のコードが実行中にTrace32のメモリダンプウィンドウを有効にした場合、ECCチェックの結果が異常に実行される可能性はありますか?（つまり、ECCエラーの検出失敗、またはECC発生アドレスでのエラー） よろしくお願いします。

S32K396 および FS26 REG_CORRUPT 皆様 FS26 の「REG_CORRUPT」フラグを解消しようとしています。添付の 2 枚のスクリーンショットは、関連するすべてのレジスタの読み取り結果を示しています。 最初の「AE」読み込みコマンドの直前に、ウォッチドッグのファーストキックを成功させてFSの状態をINIT_FSから外し、フェイルセーフレジスタの状態の正しさを評価しました。0x28回答から、REG_CORRUPTビットが設定されたデバッグモードに入っていることがわかります。 ウォッチドッグのキックが成功したことは間違いありません。キック直後にFS_DIAG_SAFETY1を読み取ったところ、戻り値は0x0103で、エラーフラグはなく、ABIST1_OKとLBIST_STATUS = OKでした。 0xAE コマンドの後、0xAF コマンドを発行してレジスタに 0x1800 を書き込んで OTP_CORRUPT ビットと REG_CORRUPT ビットをクリアし、その後レジスタ 0x41 から順に 12 個の FS レジスタすべてを読み取ります (シフトするとコマンドは 0x82 になります)。 これらのレジスタから返された値を確認しましたが、返された値に一貫性の問題は見当たりません(もちろん、書き込みしてはいけないビットや保持・保留・0/1のビットを考慮して)。 最後に読んだ『FS_STATES』を見ると、まだREG_CORRUPTが設定されていることがわかります。 こんな直接的な質問をして申し訳ないのですが、何か見落としている点があるのでしょうか？ よろしくお願いいたします。 Andrew Snip1.pngSnip1.png Snip2.pngSnip2.png    Re: S32K396 and FS26 REG_CORRUPT こんにちは！ REG_CORRPUT ビットについては、以下のようにアサートされます。これは、FS レジスタが構成される場合、NOT レジスタを XOR ルールとともに構成する必要があることを意味します。 ErikaC_0-1785954434399.pngErikaC_0-1785954434399.png このビットがアサートされる原因となっている、規則に従っていないレジスタ設定がないか確認してください。 Re: S32K396 and FS26 REG_CORRUPT エリカ様、 ご回答ありがとうございます。すでに何度も確認済みですので、最初の投稿でレジスタの状態を画像として掲載しました。これらの設定方法に問題があると思われる場合は、お知らせください。 私の知る限り、レジスタは正しい(データシートで書き込み可能なビットのみを考慮して)正しいようです。チップ自体が読み取り専用ビットが有効な状態であることを管理しているものと想定し、また「0」または「予約済み」と指定されているビットは書き込み不可であると想定します。 それらのビットのいずれかに書き込みをすると、REG_CORRUPTビットがアサートされたままになる可能性はありますか? よろしくお願いいたします。 Andrew Re: S32K396 and FS26 REG_CORRUPT 皆様、 自分の質問に答えて、将来誰かの助けになればと思っています..... データシートの抜粋を投稿するつもりはありません。なぜなら、それは私がこの製品データ情報にアクセスするために署名したNDAに違反するためです。ただし、製品情報で「0」または「予約」と定義されているビットはよくご確認ください。私の問題の解決策は、「RESERVED」と定義されている部分に関係していました。REG_CORRUPTビットが設定されるのを防ぐために、ソフトウェアがこの場所に「1」を書き込むことが不可欠です。 必要なビット状態を明確にし、ソフトウェアが何をすべきかを正しく定義するためにデータシートを修正することをお勧めします。これは他の類似ビットと同様にです。 よろしくお願いいたします。 Andrew

S32DS 许可证激活 ID 您好，当我打开S32DS时，我看到了以下信息： ARM 版 S32 设计工作室 激活ID：1A99-90A8-2F06-339B 评估天数：14天 功能版本：2.2 功能状态：评估中（14天） 延长许可证有效期需要哪些手续？祝您生意兴隆！ 回复： S32DS license ActivationId ActivationId: 1A99-90A8-2F06-339B 请帮忙激活并延长使用，谢谢 Re: S32DS license ActivationId 你好， 您的S32DS许可证已延期。请使用您之前的激活码重新激活S32DS。

S32DS ARM 2018 R1 License Extension Request Hello, my license has expired, so I would like to apply for an extension. zhangtr_0-1785825418457.png Re: S32DS ARM 2018 R1 许可证延期申请 Hello, It is extended now. Best regards, Peter Re: S32DS ARM 2018 R1 许可证延期申请 Thanks

iMX937的深度睡眠模式 我正在使用 iMX95lpddr5 evk，触发了深度睡眠模式，想知道 A55、M7 和 M33 中已暂停和未暂停核心的状态、时钟频率和功耗。 Re: Deep Sleep Mode of iMX937 在 i.MX95 LPDDR5 EVK 上，“深度睡眠”对应于 i.MX 95 Suspend / DSM 风格的低功耗模式。A55 处于挂起/断电状态；M33 未运行应用程序工作负载，通常显示为时钟门控/空闲状态；M7 的状态取决于您是否也将其挂起或将其保留为唤醒/实时核心。AN14449 中的功耗数据是SoC 轨/组的总功耗，而不是每个核心的功耗。 低功耗外壳 Cortex-A55 状态/频率 Cortex-M33 状态/频率 Cortex-M7 状态/频率 DDR状态 报告功率 DSM 系统中的系统 暂停；时钟检测不到 时钟门控；时钟无法检测 暂停；未提供时钟 保留 25.65 mW GROUP_SOC_FULL 总计 Linux 挂起 + CM7 WFI 暂停 / 0 时钟门控或空闲 / 0 WFI / 400 MHz 保留 178.48 毫瓦GROUP_SOC_FULL 总计 Linux 暂停 + CM7 CoreMark (TCM) 暂停 / 0 时钟门控或空闲 / 0 CoreMark / 400 MHz 保留 197.24 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + CM7 FlexCAN 事务 暂停 / 0 时钟门控或空闲 / 0 FlexCAN / 800 MHz 活跃，6400吨/秒 659.71 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + CM7 网络/以太网 暂停 / 0 时钟门控或空闲 / 0 NETC / 800 MHz 活跃，6400吨/秒 956.17 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + WoL A55 停运 M33 空闲/低功耗上下文 具备唤醒功能的配置；检索到的数据块中没有精确的核心表。 取决于 WoL 设置 342.72 毫瓦GROUP_SOC_FULL 总计 一些解读说明： i.MX 95 参考手册将Suspend描述为最大程度节省功耗的模式，其中不必要的时钟/电源被关闭，Cortex-A55 CPU 完全断电，可以断电的 PHY 被关闭，VDD_SOC 降低到挂起电压。 在DSM 系统中，AN14449 明确指出CA55=挂起，CM33=时钟门控，CM7=挂起，DDR=保持，并指出由于 CA55 和 CM33 不工作，因此无法检测到时钟。 对于 M7 保持活动的 Linux 挂起，未挂起的核心是 CM7 ；其时钟频率在 WFI/CoreMark 保持情况下为400 MHz ，在 FlexCAN/NETC 情况下为800 MHz ，而 A55 和 M33 在案例表中显示为0 MHz 。 已公布的功率数据并非针对每个 A55/M7/M33 核心单独列出的。AN14449 报告了诸如 GROUP_SOC_FULL 和 GROUP_DRAM 之类的轨/组测量结果；例如，DSM 报告 vdd_arm 为 0 mW，vdd_soc 为 3.85 mW，GROUP_SOC_FULL 总和为 25.65 mW，但这仍然是轨级功耗，而不是单个核心功耗。 结论：如果 M7 也处于挂起状态，则 DSM 功耗约为 25.65 mW；如果 M7 在 Linux 挂起期间保持运行，则 SoC 总功耗会从 400 MHz 时的约 178–197 mW 上升到 800 MHz 时的约 660–956 mW，具体取决于外围设备的工作负载。 Re: Deep Sleep Mode of iMX937 对于 I.Mx95，有几种电源模式，包括运行模式、低功耗运行模式、空闲模式、挂起模式和电池备份安全模块模式。有关详细的功耗数据，请参阅 IMX95AEC 数据表。对于 i.Mx937，该设备目前处于预生产阶段，目前只有产品说明书可供参考。 不太清楚测试数据的来源，以及你提到的深度睡眠模式是什么……

IMX8MP オンチップRAMメモリアクセス こんにちは、 OCRAMにアクセスしてデータを読み込み、メモリに取り込む方法を学びたいです。 Linux Cortex A-53でそれを実現するにはどうすればいいか、誰かアドバイスをいただけませんか? オンチップRAM - OCRAM (576 KB) 開始アドレス: 0x00900000 => ROM用に予約済み 開始アドレス: 0x00918000  =>OCRAMフリーエリア 終了アドレス: 0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM ご回答をお待ちしています。 IMX8MPLUS i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access こんにちは、ロマン・ルースさん。 このアドバイスはあなたにとって効果がありますか？ よろしくお願いいたします。 ステファノ・ジリ Re: IMX8MP On chip RAM memory access こんに ちは、@Roman_Loz、compatible = "shared-dma-pool"を含めるといいですよ;そして、それはうまくいくはずです。 ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 ご提案いただいた方法でOCRAMを使おうとしているのですが、memcpyを実行しようとするとカーネルパニックが発生します。 私が何を間違っているのか、あるいは見落としているのか理解する手助けをしてもらえますか? dtsi: resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... モジュール初期化: // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } コピー： memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 なお、NXPは他のドライバーが使用する448KBのOCRAM空間に対するノードの変更を推奨していません。 互換性のある=「shared-dma-pool」プロパティを用いて、0x970000後にメモリ領域をDMAサポートに利用できます。 ありがとうございます。よろしくお願いいたします。 サンケット・パレク Re: IMX8MP On chip RAM memory access こんにちは、 @Sanket_Parekh さん。 ご回答ありがとうございました。大変参考になりました！ もしユーザーアプリケーションで使えない場合、448KBのOCRAM空間内でDMAをサポートするようにデバイスツリーを変更することは可能でしょうか? よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 お元気でお過ごしでしょうか。   OCRAMやLinuxカーネルで自分専用にどれだけのメモリが割り当てられているかは、socのdtsiファイル(予約済みメモリノード)を調べることで判断できます IMX8MPの場合は448KBです。   resmem: 予約メモリ { #address-cells = <2>; #size-cells = <2>; 範囲; ocram: ocram@900000 { 地図なし; reg = <0 0x900000 0 0x70000>; };   ..... .....   }   ここで0x70000(448K)バイトがLinux使用用に予約されています。そして、no-mapプロパティで指定されているユーザースペースに仮想的にマッピングすることはできません。 さらに0x7000バイトを経て、他のアプリケーションにも使えます。 ただし、OCRAMを使わないM7コアアプリケーションは必ず確認する必要があります。これは特定のアプリケーションのリンカースクリプトを調べることで判別できます。   ありがとうございます。よろしくお願いいたします。 サンケット・パレク   Re: IMX8MP On chip RAM memory access こんにちは、サンケットさん。 Linuxがどれだけのメモリを消費し、残りはユーザーアプリケーションに使えるか確認することは可能でしょうか? もし可能なら、どうやって同じことを検証し、残りのメモリをアプリケーション用に割り当てればいいのでしょうか。 よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 お元気でお過ごしでしょうか。 OCRAM Firstにアクセスするには、ATFが使用している地域にアクセスしようとしないように注意する必要があります。 U-Bootの場合、md/mwコマンドを使ってOCRAMに直接アクセスできます。 Linux自体がOCRAMを使用しているため、ユーザースペースでのOCRAM使用は推奨されません。 ありがとうございます。よろしくお願いいたします。 サンケット・パレク

AAOS 15を使用したimx8qmでのディスプレイ解像度設定 チームの皆さん、こんにちは。 i.MX8QM MEK 上で AAOS 15.0.0_2.1.0 を 使用して い ます 。ボードに ファームウェアを書き込んだ 後 、 物理 ディスプレイの 解像度 は 常に 1024x600 に 設定されて います が 、 ディスプレイ を 1920x1080 で 動作させ たい と考えてい ます 。 また、マルチディスプレイのセットアップで、Androidのメインデフォルトディスプレイと乗客用のディスプレイがあります。 サポートされている 表示 モード で 1920x1080 が 利用可能 で ある こと を確認しました が 、 起動 後 の アクティブ な 表示 モードは 1024x600の ままです 。Android の 優先 表示 モード を 1920x1080 に 設定 してみました が、 再起動 後 も 表示 は 1024x600 の ま まです 。 CAN you please advise: 起動 時に デフォルト の 物理 ディスプレイ 解像度 を決定する要因は 何ですか ？ 起動 後に 物理 的なディスプレイ 解像度 を 1920x1080@60Hzに強制 するには どう すればいい ですか? ro.boot.displaymode に 必要な 設定 は あり ます か ？HAL、 HWC3、 または DRM を表示して 、 1920x1080を デフォルト の アクティブ モード に します か？ 何か アドバイスを いただけれ ば幸い です 。 Re: Display resolution setup on imx8qm with AAOS 15 こんにちは、 こちらで入手可能なAndroid オートモーティブのドキュメントをご参照ください。 https://www.nxp.com/docs/en/user-guide/UG10176.pdf 特に第8.3.4章を参照してください。上記ドキュメントのプライマリディスプレイ解像度を設定します。 よろしくお願いいたします。 アルド。