为了模拟 imx95lpddr5 evk 的满载情况 如何模拟 i.MX95 LPDDR5 EVK 板上的满载运行条件。是否有可用的镜像文件或预编译的应用程序？我正在使用Linux多媒体镜像。 Re: To simulate full load condition on the imx95lpddr5 evk 你好， 您可以参考这份应用笔记： https://www.nxp.com/docs/en/application-note/AN14449.pdf 实现高CPU负载测试有多种不同的使用场景。 我建议你看看： CA55 CoreMark eIQ 基准测试（GPU） eIQ 基准测试（NPU） 顺祝商祺！ 

SL3S1206FUD2/HA 良好なダイ識別ドキュメント/ウェハーマップの要請 サプライヤー様、 ウェハー上で「Good Die」と「NG Die」を区別するドキュメントや刻印をご提供いただいているか確認したいと思います。 具体的には、以下の人材を求めています。 ウェハマップ（どのダイがテストに合格/不合格だったかを示す）、 検査結果報告書、または 使用可能なダイを明確に識別するための、ウェーハ表面上の物理的なマーキング（例：インクドット、レーザーマーキング）。 顕微鏡でウェハーを調べましたが、目に見える物理的痕跡は見つかりませんでした。これは、良品ダイと不良品ダイを確実に区別できない可能性があるという懸念を引き起こす。 そのような情報が出荷に含まれているかどうか、または製造元からこれらの資料を受け取るのを手伝っていただけませんか?このデータは次のプロセッシングステップに必要です。 ご親切なご協力に感謝いたします。ご返信をお待ちしております。

MC9S08QG8コンパイラ、このチップ用のCコンパイラはどうすれば入手できますか？ 実は、MC9S08QG8チップを使った製品を開発しています。C言語のコードをいくつか変更する必要があります。私はWindows 11を使用しています。チップのデバッガを生成するにはどのソフトウェア製品を使うべきでしょうか。私は製品のチップにPCのUSBポートからWiztronicsのインターフェースボードを使っています。8つの異なるソフトウェアパッケージを試しましたが、どれも最終的なデバッガが動作していません。デバッグにおすすめのソフトウェイジパッケージは何ですか?私はあなたの開発センターで迷子になってしまいました。 Re: MC9S08QG8 COMPILER, how do i get the c compiler for this chip Hello CodeWarriorツールバージョン11.1はWindows 11でサポートされており、このツールはさまざまな接続に対応しています[P&E USB Multilink Universal / USB Multilink、P&E Cyclone、オープンソースBDM、P&E Full chip simulation] このツールはこちらのリンクからダウンロードできます: CodeWarrior® for MCUS (Eclipse IDE) v11.1 MC9S08QG8というデバイスを探していたのですが、このバージョンが見つかりました。 敬具、ルイス

I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT 错误 您好，NXP团队： 我们正在尝试使用 .wic 文件对 i.MX93 开发板进行烧录。图片文件由我们团队提供。我们有两块硬件版本相同的 i.MX93 板（ SCH-96411 REV_B2 ）。 在一块电路板上，我们能够成功地刷写 .wic 文件。图像。但是，当尝试将相同的图像刷入第二个板时，我们遇到了错误。 我们已经对两者进行了测试： emmc_all（用于 eMMC 刷写） sd_all（使用 SD 卡） 两种情况下，第二个电路板上都会出现同样的问题。 我们希望您能协助我们排查并解决此问题。如果您需要任何其他日志、错误信息或电路板信息，请告知我们。 Providing both uuu command and debugProviding both uuu command and debugProviding both uuu command and debug同时提供 uuu 命令和调试 uuu supported listuuu supported listuuu supported listuuu 支持的列表 i.mx93 usb identifiedi.mx93 usb identifiedi.mx93 usb identifiedi.mx93 USB 已识别 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error 您好， 感谢您对恩智浦半导体产品的关注， 有原理图识别信息固然好，但我建议还是确认一下 i.MX 93 的顶部标记。确认他们获得最高分。 请从Linux下载最新的预编译镜像版本。 最后，您尝试通过串口下载方式对它们进行刷写，它们的熔丝是否熔断了？ 此致 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error 你好 请查看附件图片。我们注意到集成电路零件编号发生了一些变化。 我们也尝试过从外部刷写 SD 卡，然后再将其插入 i.MX93 板，但仍然遇到同样的问题。 此外，我们想提醒您，eMMC 中已经存在一个映像，并且该板能够从该映像成功启动。但是，当我们尝试刷入新镜像时，却遇到了错误。 请查看下方附件中的调试日志。一个观察结果是，板子自带的预装镜像显示的是U-Boot SPL 2025.04 版本。而我们尝试使用的图像显示的是U-Boot SPL 2024.04 。 我们下载了最新的Linux 6.18.20_2.0.0 (i.MX93 EVK, FRDM)版本。然而，我们只能找到14x14 EVK WIC 图像，而无法找到11x11 FRDM WIC 图像包。请问14x14的图像是否适合我们的电路板，或者是否有单独的11x11 FRDM图像可用？ SD卡启动： U-Boot SPL 2024.04+gde16f4f1722+p0（2024年9月2日 10:44:35 +0000） SOC：0xa1009300 LC：0x2040010 PMIC：PCA9451A PMIC：过驱动电压模式 DDR：3733MTS DDR：3733MTS M33 准备就绪 eMMC启动： U-Boot SPL 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） PMIC：PCA9451A PMIC：过驱动电压模式 DDR：找到 3733MTS 动态随机存取存储器(DRAM) 2CS_2GB 动态随机存取存储器(DRAM) 匹配 M33 准备就绪 普通启动 尝试从 BOOTROM 启动 启动阶段：主启动 图像偏移量 0x8000，页面大小 0x200，ivt 偏移量 0x0 通过 ROM_API 从 0x57800 加载镜像 注意：TRDC 初始化完成 通知：BL31：v2.12.0（版本）：lf-6.18.2-1.0.0 通知：BL31：建造时间：2026年2月10日 07:53:18 /********************************************************/ 关于熔丝熔断的问题，请问我们如何验证电路板上的熔丝是被编程熔断还是已经熔断？ 谢谢。 Issue board - imx93Issue board - imx93问题板 - imx93 Working board - imx93Working board - imx93工作板 - imx93 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error 我也有类似的问题，据我了解，FRDM系列背后的中国制造商更换了DDR内存芯片。这需要重新训练 DDR 并更新 u-boot，板载软件已经完成，并提交到了 nxp 的 u-boot 仓库，但是网站上的 BSP、Yocto 层和二进制镜像还没有更新。 基本上，较新的板只能使用内置的 u-boot，你的开发人员使用 BSP（以及 2024 年及以后的 u-boot）构建的所有内容都将无法启动，因为 DDR 配置无效。 你可以通过从板载 u-boot 启动，使用键盘停止它，然后手动从 SD 卡加载你的自定义 linux 内核和 DT 来确认这个问题。

SPD 1.0.3 — eMcem.xdm XDMスキーマのバグ（717行目）（EB Tresosインポート失敗） S32K3 セーフティ ペリフェラル ドライバ(SPD)バージョン1.0.3のバグを報告しています。具体的には、eMcemモジュールのXDM設定ファイルにあり、Elektrobit（EB）Tresos Studioへのインポートを妨げています。 環境 ┌───────────────────┬─────────────────────────────────────────┐ │ アイテム │ バージョン / 経路 │ ├───────────────────┼─────────────────────────────────────────┤ │ MCU │ S32K344(S32K3XX) │ ├───────────────────┼─────────────────────────────────────────┤ │ SPD │ S32K3_SPD 1.0.3 (S32K3_SAF_1.0.3_D2306) │ ├───────────────────┼─────────────────────────────────────────┤ │ RTD │ SW32K3_RTD 4.4 R21-11 3.0.0P01 │ ├───────────────────┼─────────────────────────────────────────┤ │ EB Tresos │ 29.0.0(C:\EB\tresosに設置)│ ├───────────────────┼─────────────────────────────────────────┤ │ S32 Design Studio │ 3.6.0│ └───────────────────┴───────────────────────────────────────┘ 問題の説明 EB TresosプロジェクトにeMcemモジュール（eMcem_TS_T40D34M10I3R0）をインポートしようとすると、XDMパーサーが次のエラーをスローします。 ▎「タグ 'a' の属性 'a' が無効です」config/eMcem.xdm の 717 行目 これにより、eMcemモジュールがEB Tresosプロジェクトに完全にインポートされることが防止されます。 根本原因分析 ファイル C:\NXP\S32K3_SPD_1.0.3\eclipse\plugins\eMcem_TS_T40D34M10I3R0\config\eMcem.xdm の RecoveryTimeoutEnabled パラメータブロックの 715 ～ 718 行目に、無効な XDM スキーマ構造が含まれています。 バグのあるコード（715～718行目）： VariantPreCompile 問題は、 です。XDMスキーマ(http://www.tresos.de/_projects/DataModel2/08/attribute.xsd)によれば、要素は存在しません 子供の頃に別の要素を含むこと。 同じファイル内の他のすべての箇所（例えば、684～687行目のReactionTypeパラメータ）で使用される正しい構造は次のとおりです。 正しいコード: VariantPreCompile これは、eMcem.xdm ファイル全体の中で、この不正なネスト構造が見られる唯一の箇所です（他の 20 個以上の IMPLEMENTATIONCONFIGCLASS ブロックは正しく構成されています）。これは明らかに、SPDパッケージングプロセスにおけるコピー＆ペーストのエラーです。 認証 - 同じSPD 1.0.3パッケージのBistモジュール(Bist_TS_T40D34M10I3R0)とSafetyBaseモジュール(SafetyBase_TS_T40D34M10I3R0)にはこのバグ(.xdm)はありませんファイルは正しく構造化されており、問題なくEB Tresosにインポートされます。 エラー。 - Bist.xdm ファイルには、ネストされた name="IMPLEMENTATIONCONFIGCLASS"> がまったくないことを確認しました。 なぜこれが行き詰まりなのか メタ・インフ/クリプトマニフェストです。MFとMETA-INF/CRYPTOMANIFESTSIG。eMcem プラグイン内の MF ファイルには、キープラグインファイルに対する DSA 暗号署名(キー ID: Freescale、プロバイダー: dreisoft.tresos.launcher2.CryptoKeyProvider)が含まれています。 config/eMcem.xdm..xdmへのいかなる変更もファイルの変更（たとえ1行の修正であっても）によってDSA署名検証が破綻し、EB Tresosがライセンス/整合性エラーでモジュールを拒否する原因となります。 これにより回復不能な膠着状態が生じます: - バグでインポートできない — XDMスキーマ検証に失敗 - バグを修正できない — DSA署名検証失敗→ライセンスエラー - 署名を削除できない — EB Tresosが起動に失敗(プラグインの整合性チェック) 要求 以下のいずれかをご入力ください。 1.当社の環境と互換性のあるSPDのホットフィックスリリース（または少なくとも、更新されたCRYPTOMANIFEST署名を含む修正済みeMcem.xdmファイル） 2.この修正を含む最新のSPDバージョン（例：1.0.4以降） 3. DSA署名検証エラーを発生させることなく、eMcem.xdmに必要な1行の修正を適用できるライセンスの再アクティベーションまたは回避策 4. この問題を解決するより新しいSPDバージョンが存在するかどうかの確認と、ダウンロード/アップグレード手順 この問題がS32K344セーフティソフトウェアの統合、特にEB TresosのeMcem(拡張マイクロコントローラエラーマネージャ)モジュール構成を妨げています。 補足事項 SPD 1.0.3リリースノートには、RTD 3.0.0との互換性について記載されています。/ 3.0.0P07。当社ではRTD 4.4（SW32K3_RTD_4.4_R21-11_3.0.0_P01）を使用しています。また、SPD 1.0.3とRTD 4.4の互換性状況を確認してもらえますか?また、新しいバージョンかどうかも教えていただけますか RTD 4.xの統合にはSPDバージョンが必要ですか? --- ご協力ありがとうございました。追加の情報やログが必要な場合はお知らせください。 よろしくお願いいたします。 Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) こんにちは、 @WuDiDi さん、 この問題はSPD 1.0.4でも発生しています。 SPD 1.0.5とSPD 1.0.6で修正されているのが見えます: SPDバージョン1.0.5は、S32K3_S32M27xリアルタイム・ドライバASR R21-11バージョン5.0.0および4.0.0と互換性があります。 バージョン4.0.0は、S32K3Eシリーズ（S32K39xおよびS32K36x）を除くすべての派生機種でサポートされています。 SPDバージョン1.0.6はS32K3リアルタイムドライバーバージョン7.0.0と互換性があります+ 6.0.0。 新しいRTD/SPDバージョンにアップデートできますか? バージョン1.0.3以降、多くのRTD、SPDのバグが修正されました。 なお、NXPは古いソフトウェアバージョンに対してホットフィックスを提供していません。 SPD 1.0.3の互換性については、リリースノートで明示的に指定されたRTDバージョンとの機能のみを保証します。他のRTDバージョンとの互換性は保証されません。 よろしくお願いいたします。 ダニエル Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) こんにちは、 @WuDiDi さん。 フォローアップの質問は元のトピックとは関係ありません。 新しいスレッドを作ってもらえますか? よろしくお願いします。 BR、ダニエル Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) こんにちは、ダニエルさん。 ご説明いただきありがとうございます。私は既にSPD 1.0.5（D2503）とRTD 4.0.0を使用しています。S32K342はP01なので、バージョン互換性は問題ないはずです。 実装範囲に関して具体的な質問があります。SPD 1.0.5 デモプロジェクト (S32_SPD_Demo) では、S32K344/S32K358/S32K388/S32K396 用の TresosProject 構成のみが提供されており、S32K342 用は提供されていません。S32K342に対応させています。 以下の点をS32K342確認していただけますか? 1. ロックステップフォールト注入:S32K342 DCM/EIMメカニズムによるロックステップフォールト注入をサポートしていますか?S32K342はシングルコアのロックステップデバイスで、DCMフォルトにはEMCEM_DCM_NCF_3_LC_ERRとEMCEM_DCM_NCF_0_PLTFRM_CM7_0_LUPが見えます リスト。注入箇所はこれで合っていますか？ 2. LBIST/MBIST: Bist_TS_T40D34M10I5R0 プラグインには S32K342 EPD バリアントがあります。Bist_SpecificTables_S32K3XX.c に含まれる LBIST MISR ゴールデンシグネチャと MBIST パーティションテーブルは、S32K342 シリコンに対して既に正しく動作していますか？必要なのか? S32K342特化した調整は? 3. セーフティ検証(LBIST/MBIST/lockstep FI)S32K342専用のアプリケーションノートやリファレンス・マニュアルはありますか?

S32DS環境とSDKパッケージを再インストールしたことで、以前のプロジェクトがコンパイルに失敗する原因となりました S32DS環境とSDKパッケージを再インストールしたことで、以前のプロジェクトがコンパイルに失敗する原因が発生しました。 以前はS32DS V2.2とSDK RTM 2.0.0を使っていました。今は再インストール後、S32DSを使っています。ARM.2018.R1もインストールし、SDK RTM 2.0.0もインストールしています。しかし今はプロジェクトをコンパイルできません。プロジェクト自体を認識できないようです。写真で詳細が見て取れます。 Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi こんにちは、@yangcao1234さん なお、S32K1 SDK RTM 2.0.0はARM 2018.R1 Update 6向けにS32DS専用にリリースされたものであることにご注意ください。ARM 2.2用のS32DSでの使用を想定しておらず、そのバージョンとの互換性は保証されていません。 BR、VaneB

GUI Guider 2.0で選択されたイメージ保存タイプがFlashの場合、表示できません。 Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 こんにちは、 @sk-l さん。 CAN you please provide a more detailed description of the issue?It would be very helpful if you CAN also attach screenshots or relevant pictures for reference.   ありがとう。   BR ハリー Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 画像/アニメーション画像、 カラーフォーマットはI4、ストレージタイプはフラッシュメモリ、シミュレーション中は表示されません。 カラーフォーマットはI4、ストレージタイプはc配列、画像は正常に表示されます。

I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT エラー こんにちは、NXP チームの皆様、 .wicファイルを使用してi.MX93ボードにファームウェアを書き込もうとしています。画像ファイルは当チームより提供されました。弊社には、同じハードウェアリビジョン（ SCH-96411 REV_B2 ）のi.MX93ボードが2枚あります。 1枚の基板では、.wicファイルの書き込みに成功しました。画像。しかし、同じイメージを2枚目の基板に書き込もうとすると、エラーが発生します。 私たちは両方をテストしました。 emmc_all（eMMC書き込み用） sd_all(SDカード使用) どちらの場合も、同じ問題が第2ボードで発生します。 トラブルシューティングや解決にサポートをご協力いただけるとありがたいです。追加のログ、エラーメッセージ、またはボード情報が必要な場合はお知らせください。 Providing both uuu command and debugProviding both uuu command and debugProviding both uuu command and debuguuuコマンドとデバッグの両方を提供します uuu supported listuuu supported listuuu supported listuuu サポート対象リスト i.mx93 usb identifiedi.mx93 usb identifiedi.mx93 usb identifiedi.mx93 USBが識別されました Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 回路図の識別は良いですが、93 i.MX トップマークを確認することをお勧めします。両者が最高評価を共有していることを確認してください。 Linuxから最新の既成イメージリリースをダウンロードしてください。 最後に、両方のデバイスをシリアルダウンロードでフラッシュしようとしているとのことですが、ヒューズが切れている箇所はありますか？ よろしくお願いします。 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error こんにちは 添付画像をご確認ください。ICの部品番号にいくつか変更点があることに気づきました。 SDカードを外部でフラッシュしてからi.MX93ボードに挿入するという方法も試しましたが、やはり同じ問題が発生します。 さらに、eMMCには既にイメージファイルが存在しており、ボードはそのイメージファイルから正常に起動できることをお知らせいたします。しかし、新しいイメージをフラッシュしようとすると、エラーが発生します。 デバッグログを添付しましたので、下記をご覧ください。1つの観察結果は、ボードに付属していたプリロードイメージがU-Boot SPL 2025.04を示していることです。一方、私たちが使用しようとしているイメージはU-Boot SPL 2024.04を示しています。 最新の Linux 6.18.20_2.0.0(i.MX93 EVK、FRDM) リリースをダウンロードしました。しかし、 14x14のEVK WIC画像 しか見つけられず、 11x11のFRDM WIC画像 パッケージは見つけられませんでした。14x14の画像が当ボードに正しいものか、それとも別の11x11 FRDM画像があるのか確認いただけますか? SDカードブート: U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK eMMCブート: U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS が DRAM 2CS_2GB と一致する DRAM を検出しました M33準備OK 通常のブート BOOTROMから起動しようとしています ブートステージ:プライマリブート 画像オフセット 0x8000、ページサイズ 0x200、IVT オフセット 0x0 ROM_APIを使用して0x57800からイメージをロードします 通知：TRDC初期化完了 お知らせ：BL31：v2.12.0（リリース）：lf-6.18.2-1.0.0 お知らせ：BL31：製造日時：2026年2月10日 07:53:18 /****************************************************/ ヒューズが飛んだことについてですが、ヒューズがプログラムされているのか、基板上で飛んだのかをどうやって確認できるか教えていただけますか? ありがとう。 Issue board - imx93Issue board - imx93問題掲示板 - imx93 Working board - imx93Working board - imx93作業用ボード - imx93 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error 私も同様の問題を抱えており、私の理解では、FRDMシリーズを製造している中国のメーカーがDDR RAM ICを変更したようです。これにはDDRの再学習とyou-bootへのアップデートが必要で、これはボードソフトウェア用に行われ、nxpのu-bootリポジトリにコミットされましたが、ウェブサイト上のBSP、Yoctoレイヤー、バイナリイメージは更新されていませんでした。 基本的に新しいボードは内蔵のU-Bootのみで動作し、開発者がBSPで作るもの(および2024年以降のU-boot)は、ddr設定の無効により起動すらできません。 この問題を確認するには、ボードのU-Bootから起動し、キーボードで停止し、SDカードからカスタムLinuxカーネルとDTを手動でロードする方法があります。

Clock_Ip_Init() 呼び出し時の外部データアボート こんにちは、 RTDとS32 DSのmexツールを使ってペリフェラルクロックを初期化しようとしています。(注:私はM7プロジェクトでコードを生成していますが、実際にはA53プロジェクトのためにビルドして実行しています) しかし、Clock_Ip_Init() 関数内で外部データによる異常終了が発生しました。具体的には、コールスタックは次のようになります。 Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref()。 これはCMUペリフェラルメモリへの書き込みを初めて試みた試みのようです。この障害は、メモリ0x4005'C028上のLDR命令で発生しており、S32G3メモリマップによれば、この命令はCMUメモリ領域内に正しく配置されています。 現時点ではMMUは有効になっていませんが、私の理解では、外部のデータアボートはCPU/MMUの外で発生し、 おそらくセキュアアクセス か 「ロックされた」 周辺機器に関連しているようです。 Clock_Ip_Init() を呼び出す前に、何らかの方法で CMU を A53 コアから「アクセス可能」にする必要がある、という理解で合っていますか？もしそうなら、その手順についてアドバイスをいただけますか? よろしくお願いいたします。 ジョニー デバイス = S32G399A コンパイラ = S32DS_GCC _11_4 コア = Cortex A53 Re: External Data Abort when calling Clock_Ip_Init() こんにちは、 jonnyWHIS お問い合わせいただきありがとうございます。 S32DS IDEのS32G A53コア上でベアメタルコードを作成するつもりですか? BR ジョーイ

无法从 T2081 处理器访问 MT29F64G08AECAB 8GB 与非闪存 你好， 我有一个T2081 NXP 处理器，通过IFC连接到外部与非闪存 MT29F64G08AECAB 。 我的目标是在 Code Warrior 上对该与非 Flash 进行诊断测试，或者直接读取该设备的设备和制造商 ID（我已经为此编写了代码）。 为了实现这个目标，我已经完成了以下工作： 1. 在生成的T2081QDS_init_core.tcl 中配置 与非 IFC 的 LAW，起始地址为 0xFF800000，大小为 1MB 。 ## LAW3 到 IFC - 与非 # LAWBARH 内存 [CCSR_ADDR 0x000C30] = 0x00000000 # 律师协会 内存 [CCSR_ADDR 0x000C34] = 0xFF800000 # LAWAR 内存 [CCSR_ADDR 0x000C38] = 0x81F00013 2. 还配置了与 NAND 对应的CSPR 和 FTIM 寄存器，如下所示： 设置 NAND_CS 5 # 与非闪存，地址0xFF800000，容量1MB，8位与非，ECC禁用 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 # AMASK mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 请注意，处理器到与非 有 2 个片选信号（CS5 和 CS6），目前我正在尝试访问前 4GB，因此只配置了 CS5 。 3. 已配置TLB： 1M TLB 条目 5：0xFF800000 - 0xFF8FFFFF，适用于 与非 缓存禁止、受保护的缓存 寄存器${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. 由于在安装目录中找不到对 MT29F64G08AECAB 的设备支持，我按照手册为该设备（4GB）创建了一个 .xml 文件，我已将其附在此处。 完成上述步骤后，当我在 CodeWarrior 上运行 与非 设备的诊断测试时，出现以下错误： 作为替代方案，我尝试编写一个简单的 C 代码来从该设备读取设备 ID。所以我用 CodeWarrior 编写了以下代码，并附在这里。因此，当我读取 IFC_NAND_MDR 寄存器时，我得到了 0x124E0000，这与设备 ID 不匹配。 我想知道是不是我做错了什么或者遗漏了什么，因为我无法运行诊断测试或读取设备 ID 。 我已附上相应的 T2081QDS_init_core.tcl 文件以及相应的原理图供您参考。 问候， 尼萨加 R   QorIQ T2 设备

rt1189 ブートフロー 1.図に示すように、「画像の認証」プロセスは、SHA-512ハッシュ化の段階でハッシュ値を検証するのでしょうか？ 2. ハッシュ値を設定した場合、BootROMはイメージの整合性を検証しますか？BootROMの検証に失敗した場合、リカバリーモードに入るのでしょうか？ Re: rt1189 Boot Flow 上の図に示すように、イメージに署名するだけで暗号化しない場合、ブートROMの検証フローを通過できるでしょうか？さらに、oem_closeが有効になっている場合でも、ブートROM検証フローに入ることは可能でしょうか？     Re: rt1189 Boot Flow 1. 署名認証機能が有効である場合にのみハッシュ検証が有効ですか?ハッシュ検証はどのように独立して有効化できるのでしょうか?デバイスはどのようにしてOEM_CLOSEDライフサイクル状態に移行できますか? 2. リカバリーブートヒューズを有効にする。 3. 私の目標は暗号化されていない画像を使うことです。ブートROMはイメージハッシュを計算し、検証する必要があります。ハッシュ検証が失敗した場合、ブートROMはリカバリブートフローに入り、LPSPI NORフラッシュからリカバリイメージを起動する必要があります。 Re: rt1189 Boot Flow 下記に、お客様からの2つのご質問に対する回答を記載いたします。 1. 署名のみ(暗号化されていない)イメージがBootROM検証フローを通過できますか?はい。RT1180 AHABでは、署名(認証)がセキュアブートの必須部分であり、画像の真正性と整合性を確保しています。一方、暗号化(OTFAD/IEE)は独立した任意のアンチクローン機能であり、検証の前提条件ではありません。したがって、署名のみのイメージは通常どおり完全な AHAB 署名検証フローを通過します。これは、NXP の公式 SPSDK rt118x_secure_boot サンプルにおける標準的なアプローチでもあります。 2. oem_close (OEM_CLOSED) が有効になっている場合でも、検証フローは実行されますか？はい、そして本人確認が必須となります。 おすすめ: oem_closeを実行する前に、署名済みイメージをOEM_OPEN状態でプログラムし、ELEイベントなしで正常に起動することを確認すると、デバイスを閉じてください(SRKHはフュージョンされると不可逆的です)。部品のブリックを防ぐためです。 (参照:i.MX RT1180セキュリティリファレンスマニュアル。会社のアカウントを通じてNDAに署名した後、オンラインの営業担当者にリクエストを提出してください。) Re: rt1189 Boot Flow こんにちは@yanyanwangさん A1：はい。RT1180はAHABを2つの認証層で使用しています: 署名レイヤー：ECDSA（SHA-256 / SHA-384）は、コンテナヘッダーとイメージ配列エントリ（各イメージのハッシュを格納する）を検証します。 ハッシュ層：ROMはロードされたイメージ本体のダイジェストを再計算し、イメージ配列エントリに格納されているハッシュと比較します。 図中のSHAハッシュ段階はまさにこの必須の整合性チェックであり、ハッシュ値を検証するものです。 A2: ROMは常にハッシュを計算・比較しますが、失敗が強制されるかどうかはデバイスのライフサイクルによって異なります。アウトオブファブのデフォルトはOpen構成で、認証は実行されますが、すべての認証エラーは無視され、画像は実行されます。デバイスをOEM_CLOSEDに移動して初めて 、ハッシュの不一致が起動をブロックします。 リカバリーモードに入るかどうかは、リカバリーブートヒューズの状態によって決まります。有効化されると、プライマリブート認証の失敗がリカバリーデバイスから再ロードおよび再認証が引き起こされます。有効化されていない場合、フローはシリアルダウンローダー/フェイタルモード/リセットループに移行します。 よろしくお願いします、 ギャビン Re: rt1189 Boot Flow multicore_triggerとcm7_helloworldという2つのデモを使用した際、CM7 ITCMのECCは有効にしませんでした。私はSPTツールを使用して、メモリから実行することを目的としたCM33イメージとCM7イメージを1つのイメージに統合し、その後、統合したイメージをUART経由でNORフラッシュに書き込みました。しかし、起動プロセスが失敗しました。マニュアルによると、コンテナには最大8つのOEM画像エントリーを含めることができます。今回のテストでは、CM33画像とCM7画像の2枚のみを使用しました。CM7 ITCM ECCは有効になっていませんでした。 CM33イメージもCM7イメージも起動しなかった。しかし、コンテナヘッダーを確認したところ、CM33イメージしか存在しないことがわかりました。CM33イメージ自体は単独で使っても問題なく正常に起動できます。 CM7イメージが想定どおりに含まれなかった、あるいは処理されなかった理由、そしてCM7 ITCM ECC構成の欠如がブートROMによるCM7イメージの処理方法に影響を与えるかどうかを理解したいと考えています。 質問2： 8つのCM7イメージと1つのCM33イメージを1つのコンテナに統合した場合、ブートROMは起動プロセス中にどのような動作をしますか？ CM7コアは1つしかないのに、ブートROMはどのCM7イメージを起動するかをどのように判断するのでしょうか？もし8枚の画像エントリすべてがCM7の画像なら、Boot ROMは8枚すべての画像を読み込むのか、1枚だけを選択するのか、それとも選択はCM33アプリケーションに任せるのか? Boot ROMは、同じコンテナ内の複数のCM7イメージエントリをどのように識別し、処理するのですか？どのCM7イメージを実行するかを決定するために使用される優先順位、イメージインデックス、コアID、ロードアドレス、エントリポイント、またはその他のメカニズムはありますか？ また、CM7 ITCM ECCが有効になっている場合と無効になっている場合における、ブートROMの正確な動作についても理解しておきたい。 CM7 ITCM ECCが有効になっている場合、ブートROMはCM7 ITCM ECCメモリを初期化し、NORフラッシュからCM7イメージをCM7 ITCMにコピーし、その後CM7をリセット状態から解放するのでしょうか？それとも、Boot ROMはCM7イメージだけを読み込み、CM33アプリケーションはCM7のリセット解除と起動を担当しているのでしょうか? CM7 ITCM ECCが有効になっていない場合、ブートROMは、ロードアドレスがCM7 ITCM内にあるCM7イメージを検出したときにどのような動作をしますか？Boot ROMはCM7イメージをスキップしたり、ロードに失敗したり、CM7をリセット状態にしたり、コンテナのブートプロセス全体を失敗させたりしますか？ 特に、以下のコンテナがサポートされているかどうかを確認したいです。 画像0：CM33 画像1：CM7 画像2：CM7 画像3：CM7 画像4：CM7 画像5：CM7 画像6：CM7 画像7：CM7 画像8：CM7 もしサポートされている場合、ブートROM起動時にこれら8つのCM7イメージは具体的にどのように処理されるのでしょうか？また、実際に実行されるCM7イメージを選択する役割を担うコンポーネントはどれでしょうか？ 最後に、最大8つのOEMイメージエントリがコンテナに8つの異なるイメージを保存できるのか、それともBoot ROMが特定のコアに対して特定のイメージを選択して起動する仕組みを提供しているのかを明確にしたいと思います。

SPD 1.0.3 — eMcem.xdm XDM 架构错误，位于第 717 行（EB Tresos 导入失败） 我报告的是S32K3功能安全外设驱动程序（SPD）1.0.3版本中的一个错误。具体来说，是 eMcem 模块的 XDM 配置文件存在问题，导致无法将其导入 Elektrobit (EB) Tresos Studio。 环境 ┌─────────────────────┬──────────────────────────────────────────────┐ │ 项目 │ 版本 / 路径 │ ├───────────────────┼──────────────────────────────────────────────┤ │ MCU │ S32K344 (S32K3XX) │ ├───────────────────┼──────────────────────────────────────────────┤ │ SPD │ S32K3_SPD 1.0.3 (S32K3_SAF_1.0.3_D2306) │ ├───────────────────┼──────────────────────────────────────────────┤ │ RTD │ SW32K3_RTD 4.4 R21-11 3.0.0P01 │ ├───────────────────┼──────────────────────────────────────────────┤ │ EB Tresos │ 29.0.0（安装在 C:\EB\tresos） │ ├───────────────────┼──────────────────────────────────────────────┤ │ S32 设计工作室 │ 3.6.0│ └─────────────────────┴────────────────────────────────────────────┘ 问题描述 尝试将 eMcem 模块 (eMcem_TS_T40D34M10I3R0) 导入到 EB Tresos 项目中时，XDM 解析器抛出以下错误： ▎ “标签‘a’的属性‘a’无效”位于config/eMcem.xdm文件的第717行 这样就完全阻止了 eMcem 模块被导入到任何 EB Tresos 项目中。 根本原因分析 文件 C:\NXP\S32K3_SPD_1.0.3\eclipse\plugins\eMcem_TS_T40D34M10I3R0\config\eMcem.xdm 的第 715-718 行 RecoveryTimeoutEnabled 参数块中包含无效的 XDM 架构结构： 代码有误（第 715-718 行）： VariantPreCompile 问题在于嵌套的 位于 元素内。根据 XDM 模式（ http://www.tresos.de/_projects/DataModel2/08/attribute.xsd ）， 元素不能 包含另一个 元素作为子元素。 同一文件中所有其他出现位置（例如，第 684-687 行的 ReactionType 参数）使用的正确结构是： 正确代码： VariantPreCompile 这是整个 eMcem.xdm 文件中唯一出现这种格式错误的嵌套的地方（20 多个其他 IMPLEMENTATIONCONFIGCLASS 块都已正确形成）。这显然是SPD包装过程中的复制粘贴错误。 验证 -来自同一 SPD 1.0.3 包的 Bist 模块 (bist_t40d34m10i3R0) 和 SafetyBase 模块 (SafetyBase_t40d34m10i3R0) 没有这个错误 —— 他们的 .xdm文件结构正确，并导入到 EB Tresos 中，没有任何 错误。 - 我确认 Bist.xdm 文件中 内没有嵌套 。 为什么会陷入僵局 eMcem 插件中的 META-INF/CRYPTOMANIFEST.MF 和 META-INF/CRYPTOMANIFESTSIG.MF 文件包含关键插件文件的 DSA 加密签名（密钥 ID：Freescale，提供商：dreisoft.tresos.launcher2.CryptoKeyProvider），其中包括 config/eMcem.xdm。对 .xdm 文件的任何修改文件（即使是单行修复）也会破坏 DSA 签名验证，导致 EB Tresos 因许可证/完整性错误而拒绝该模块。 这将造成无法挽回的死锁： - 由于存在错误，无法导入 — XDM 架构验证失败 - 无法修复此错误——DSA 签名验证失败→许可证错误 - 无法移除签名 — EB Tresos 启动失败（插件完整性检查） 申请它 请提供以下信息之一： 1.一个与我们环境兼容的 SPD 热修复版本（或者至少是一个经过修正的 eMcem.xdm 文件，其中包含更新的 CRYPTOMANIFEST 签名）。 2.包含此修复程序的更新版 SPD（例如 1.0.4 或更高版本）。 3. 许可证重新激活或变通方案，允许我们对 eMcem.xdm 应用必要的单行修复，而不会触发 DSA 签名验证失败。 4. 确认是否存在可解决此问题的更新版 SPD，并提供下载/升级说明。 这个问题阻碍了我们的 S32K344 功能安全软件集成，特别是 EB Tresos 中的 eMcem（扩展微控制器错误管理器）模块配置。 补充说明 SPD 1.0.3发布说明中提到与 RTD 3.0.0 兼容。/ 3.0.0P07。我们正在使用 RTD 4.4 (SW32K3_RTD_4.4_R21-11_3.0.0_P01)。能否请您确认一下 SPD 1.0.3 和 RTD 4.4 的兼容性，并告知是否有更新的版本可以兼容？ RTD 4.x 集成是否需要 SPD 版本？ --- 谢谢你的帮助。如果您需要任何其他信息或日志，请告诉我。 顺祝商祺！ Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 你好@WuDiDi ， SPD 1.0.4 中也存在此问题。 我看到这个问题在 SPD 1.0.5 和 SPD 1.0.6 中已经修复了： SPD 版本 1.0.5 与 S32K3_S32M27x 实时驱动程序 ASR R21-11 版本 5.0.0 和 4.0.0 兼容。 除 S32K3E 系列（S32K39x 和 S32K36x）外，所有衍生型号均支持 4.0.0 版本。 SPD 版本 1.0.6 与 S32K3 实时驱动程序版本 7.0.0 兼容。+ 6.0.0。 能否更新到更新的RTD/SPD版本？ 自 1.0.3 版本以来，许多 RTD、SPD 错误已被修复。 请注意，NXP 不提供针对过时软件版本的热修复程序。 关于 SPD 1.0.3 的兼容性，我们只能保证与发行说明中明确指定的 RTD 版本兼容。无法保证与其他RTD版本兼容。 此致， 丹尼尔 Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 嗨，丹尼尔， 谢谢你的解释。我目前使用的是 SPD 1.0.5 (D2503) 和 RTD 4.0.0。P01 适用于 S32K342，因此版本兼容性应该没问题。 我有一个关于实现范围的具体问题：SPD 1.0.5 Demo 项目 (S32_SPD_Demo) 只提供了 S32K344/S32K358/S32K388/S32K396 的 TresosProject 配置，而没有提供 S32K342 的配置。我正在将其适配到 S32K342。 请您确认以下关于S32K342的信息： 1. 锁步故障注入：S32K342 是否支持通过 DCM/EIM 机制进行锁步故障注入？S32K342 是单核锁步设备——我在 DCM 故障中看到了 EMCEM_DCM_NCF_3_LC_ERR 和 EMCEM_DCM_NCF_0_PLTFRM_CM7_0_LUP。 列表。这些注射点正确吗？ 2. LBIST/MBIST：Bist_TS_T40D34M10I5R0 插件具有 S32K342 EPD 变体。Bist_SpecificTables_S32K3XX.c 中的 LBIST MISR 黄金签名和 MBIST 分区表对于 S32K342 芯片是否已经正确？我们需要什么？ 针对 S32K342 的具体调整？ 3. 是否有专门针对 S32K342 功能安全验证（LBIST/MBIST/锁步 FI）的 应用笔记或 参考手册可以分享？ Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 你好@WuDiDi ， 后续问题与原话题无关。 请您为他们创建一个新帖子好吗？ 谢谢！ BR，丹尼尔

Which Timer from the FS32K144UAT0VLLT has Input Capture functionality? manager: Question: (1) The FS32K144UAT0VLLT datasheet shows that it has 8 independent TIMEs, but I only see FTM0, FTM1, and FTM2. What else is also a TIME? (2) Which TIME function of FS32K144UAT0VLLT has the Input capture function? Thanks! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Robin_Shen Hello, additional question: 1. In Table 47-1, FTM instances and features of S32K-RM Rev14.2, what is the parameter “Fault inputs”? 2. How many pages in the S32K-RM Rev14.2 manual show that each FTM has input capabilities?What about the capture function? Thanks! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Hi S32K-RM Rev14.2的Table 47-1. FTM instances and features 表格里S32K144只看到支持FTM0-FTM3. 你提到的应该是指每个FTM支持8 Channels通道。 都支持Input capture功能。 如果你要看FTM instances的功能区别也是看这个表格列出的功能才是某些FTM不支持的。 Best Regards, Robin Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ A1. This refers to the number of external fault inputs supported. Taking the S32K144 as an example, Table 47-1 shows that it supports 4 inputs. You can see these 4 inputs, FTM0_FLT0\1\2\3, in the table on the left. A2. The features supported by each FTM are usually not specifically listed. Refer to Table 47-5.The Channel Modes Selection configuration register can be used to implement the input capture mode mentioned in 47.5.5 Input Capture Mode.

PCA9615 dI2C通信の両端の回路、つまりツイストワイヤ束を介して接続された2枚のPCB間の回路（DSDAPとDSDAM、DSCLPとDSCLM、2本のGND、および2本の5Vライン）について助けを求めてご連絡しました。この前にGeminiをテストすることに決め、残念ながらdI2C通信に関連する2つのPCBの部品を生成するためにAIに頼ってしまいました。dI2Cに関連する回路図の一部を添付します。当然のことながら、各ボード間には通信手段がありませんでしたが、私の怠惰と、正直に言うと愚かさ（教訓になりました）のせいで、多くの時間を無駄にしてしまいました。最終的にデモボードのデータシートとユーザーマニュアルを参照したところ、明らかな違いは正の線(DSCLPとDSDAP)とVDD(B)の間に600オームの抵抗があり、負極線(DSCLMとDSDAM)とVSSの抵抗が同じで、正負の線間は120オームで、正負の線間は100オームになると知っています(1/600 + 1/120 = 1/600 + 5/600 =100ですが、電気的には見えません。多分機械工学者だからでしょうか?この誤差(おそらく複数のエラーの一つ)は、それぞれのウィリーの間に600オームプルアップ抵抗、600オームプルダウン抵抗、120オーム抵抗が存在しないことによるものです(28 AWGツイストワイヤペアの特性インピーダンスは、内部データリンクやUSB/イーサネット構成で約100オームのケーブル、標準的な間隔構成では78 Ωから95 Ωの配線です。PVCまたはFEP絶縁線)を使い、代わりにPCA9615のdI2C側の接続線の両端に100オームのリサイザーを単純に設置するという、単純化され、おそらく誤ったバージョンだったのでしょうか? これは、AIが私に示してくれた結果と、データシートの図1、7、8、9に示されている結果との間の重要な相違点の1つです。もう一つの違いは、AIが2枚のプリント基板に対して異なるコンデンサ配置を提案したのに対し、デモボードには1種類の配置しかない点です（これはdI2C接続ラインの両側で使用されるものと思われます）。さらに、VDDAピンとVDDBピンそれぞれに2つのコンデンサがあるようです。どちらもセラミックコンデンサです（ただし、最初に思ったのは、2つの黄色のコンデンサはタンタルタイプだろうということでした）。デモのユーザーマニュアルに記載されているコンデンサ配置を使い、添付のAIが提供・示したものは無視してもいいのでしょうか? もう一つの問題は、マスター側(私が3.3Vマイクロコントローラを使っている)では、当初AIがイネーブルピンを5Vラインにコネクテッドするよう指示していたことですが、基板を作った後、両基板間で機能がなかったため、AIはマスター側のイネーブピンをマスターボードの3.3Vライン(VDD(A)にコネクテッドすべきだと判断しました。3.3Vのラインにコネクテッドされています。その後、テストとして、マスター基板上のイネーブルピンへの電源供給を完全に遮断するよう要求した。どの電源、もし全てをENピンに流すべきなら、アドバイスしてもらえますか?テスト中または最終動作中は、電気部品のホットスワップは一切行いません。 上記変更の実施を検討していますが、高価な基板を導入する前に、ぜひとも皆様のご意見を伺いたいと思っています。 Re: PCA9615 コンデンサに関してもう一つ補足すると、マスター基板上のVDDAピンとVDDBピンの両方には、デカップリングコンデンサのみが推奨されています。スレーブ基板にもデカップリングコンデンサが提案されたが、スレーブ基板のVDDBピンにもさらに2つのコンデンサが提案された。 Re: PCA9615 こんにちは！ 詳しい説明をありがとうございました。 なお、NXPはPCA9615ファミリの評価ボードを提供しており、実装の**リファレンス・デザイン**として利用できます。デザインには推奨される差動I²C終端ネットワーク、バイアス抵抗、デカップリングコンデンサ、ENピン接続が含まれており、NXPによって検証されているため、回路図をPCA9615評価基板および対応ユーザーマニュアルと比較することを強くお勧めします。 評価ボード回路図を基準に、カスタムPCA9615ベースのシステムを設計する際には、設定やレイアウトの問題のリスクを最小限に抑え、データシートやアプリケーションドキュメントの推奨事項に従うため、最良のアプローチとなることが多いです。 次のPCB改訂に取り組む前に、評価ボードの回路図を確認し、設計を適切に更新することをお勧めします。 https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL お役に立てば幸いです！

调用 Clock_Ip_Init() 时外部数据中止 您好， 我正在尝试使用RTD和S32 DS mex工具初始化一些外设时钟。（注意：我是在 M7 项目中生成代码，但实际构建和运行是在 A53 项目中进行的。） 然而，在 Clock_Ip_Init() 函数内部发生了外部数据中止。具体来说，调用堆栈如下所示： Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref()。 这似乎是首次尝试向 CMU 外围存储器写入数据。故障发生在内存0x4005'C028上的LDR指令中，根据 S32G3 内存映射，该内存正确地位于 CMU 内存区域内。 目前 MMU 尚未启用，但据我了解，外部数据中止发生在 CPU/MMU 之外，可能与安全访问或“锁定”的外围设备有关。 我的理解是，在调用 Clock_Ip_Init() 之前，需要以某种方式使 CMU 可以从 A53 内核“访问”，这种说法对吗？如果可以的话，您能否告知我具体的操作步骤？ 顺祝商祺！ 乔尼 设备 = S32G399A 编译器 = S32DS_GCC_11_4 核心 = 皮层 A53 Re: External Data Abort when calling Clock_Ip_Init() 嗨， jonnyWHIS 感谢您与我们联系。 您打算在 S32DS IDE 中创建可在 S32G A53 内核上运行的裸机代码吗？ BR 乔伊

iMX8 Nano 内核从 5.15 更新至 6.18 你好 在将 A53 内核从 5.15 移植到 6.18 时，遇到了 rpmsg 的问题。 # dmesg -T | grep -Ei 'rpmsg|rproc' [2024年10月8日星期二 15:42:28] imx rpmsg 驱动程序已注册。 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：错误 -ENOENT：启用时钟失败 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：使用驱动程序 imx-rproc 进行探测失败，错误代码为 -2 [2024年10月8日星期二 15:42:29] remoteproc remoteproc0：正在释放 imx-rproc 我遇到了这个错误。我在网上搜索这个错误时，有人建议我在 DTS 文件中添加一个虚拟时钟，如下所示。 imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7"; rsc-da = <0xb8000000>; clocks = <&clk IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; 内存区域 = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; 状态 = "正常"; } 请问是否只需要做这一项更改？更改的原因是什么？ 问候 亚杜纳特·R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 不——我不会将 clocks = <&clk IMX8MN_CLK_DUMMY>; 视为唯一需要的更改。或许可以解决眼前的 -ENOENT：启用时钟探测失败的问题，但对于 i.MX8M Nano 来说，重要的要求是，当 Linux 加载/启动 M7 固件时，Cortex-M7 根时钟必须保持启用状态。 原因： imx-rproc 节点应该有一个时钟条目；AN5317 显示了 i.MX8M remoteproc DTS 节点，其 compatible = "fsl,imx8mn-cm7" 和 clocks = <...> 属性，以及邮箱和内存区域条目。 您的错误意味着内核 6.18 imx-rproc 驱动程序尝试从该节点获取/启用时钟，但时钟查找失败并出现 -ENOENT 错误，因此在 remoteproc0 保持注册状态之前探测中止。 NXP 的 AMP 指南指出： “对于 i.MX 8M 平台，Linux 必须始终启用 M7/M4 的根时钟，才能加载固件代码并启动 Cortex M7/M4。”它还指出，NXP Linux 电路板支持包 在 M 内核从 U-Boot 启动时保持此根时钟启用；否则，如果 M 内核首先从 Linux 启动，则必须更新 drivers/clk/imx/clk-composite-8m.c 以跳过 M 内核时钟的门注册。 所以这一变化有两种可能的含义： 使用虚拟时钟作为兼容性替代方案 如果内核 6.18 imx-rproc 需要一个 clocks 属性，但实际的 M7 时钟并非有意通过通用时钟框架控制，则添加 IMX8MN_CLK_DUMMY 可以满足驱动程序的时钟句柄要求，并避免 -ENOENT。 真正的时钟控制修复 如果 Linux 实际上负责加载/启动 M7，那么仅使用虚拟时钟可能会掩盖探测错误，但不能保证 M7 时钟已启用。在这种情况下，您必须确保 M7/M4 根时钟保持开启状态，这可以通过 NXP 电路板支持包时钟驱动程序处理或 clk-composite-8m.c 文件来实现。AN5317 中描述的变更。 此外，还要检查 remoteproc/rpmsg DTS 的其余部分，而不仅仅是时钟线： imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7";         rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* 或您的 电路板支持包 使用的正确 M7 时钟 */ mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>; memory-region = , , , ;         status = "okay"; }; 内存区域列表很重要，因为 AN5317 指出此属性必须包含固件 ELF 使用的内存部分，以便 remoteproc 可以从 sysfs 重新加载它。 推荐检查路径： 如果从U-Boot启动 M7，请使用 NXP 流程，例如 prepare_mcore / bootaux，然后启动 Linux；AN5317 指出，这是 BSP 保持 M 内核根时钟启用的路径。 如果您从Linux remoteproc启动 M7，请确认您的 6.18 时钟驱动程序包含 NXP 处理，以保持 M 内核根时钟始终启用；否则，虚拟时钟可能只能修复探测，而不能修复运行时启动/加载。 将您的 DTS 与 NXP imx8mn-*-rpmsg.dts 进行比较对于同一个 BSP 版本，特别是时钟、mboxes、rsc-da 和保留内存布局。 虚拟时钟解释了立即出现的 -ENOENT 探测失败，但真正的设计要求是保持 i.MX8MN M7 根时钟启用；仅靠 DTS 是否足够取决于你的 6.18 BSP 时钟驱动程序是否已经保留了该时钟。

RT1171CVM8BでのモバイルSDRAM(1V8)サポート 私たちは新製品に使われるRT1171CVM8Bを調査しています。 このRTファミリーのメンバー i.MX モバイル(低消費電力、1.8V)SDRAMに対応していますか? データシート、リファレンスマニュアル、利用可能なアプリケーションノートや回路図からは、それがすぐには明確ではありません。これは1V8および3V3の両方で指定されているポートドライバ(NVCC_EMC1,2)によって推論されます。また、RT1060およびRT1050 i.MX の類似の質問や回答から肯定の推論も得られます。 EMCやSDRAMインターフェースの特殊な部分が1V8の部品で故障するようなトラブルは避けたいです。 そうでなければ、なぜデータシートに明確に記載されていないのでしょうか!? 敬具 ジョージ・ツァナトス。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B @georgetzanatos様、 RT1171はモバイルSDRAM(低消費電力1.8V SDRAM)をサポートしています。 現在のドキュメントにはこれを明確に記載していないことには同意します。データシートおよびリファレンスマニュアルでは、メモリプロトコルのサポートとI/O電圧モードが別々に説明されており、単一の「モバイルSDRAMサポート」文にまとめられているわけではありません。 ご心配は理解できます。RT1171のモバイル SDRAMを使っても構いません。重要な要件は、関連するNVCC_EMC1/2電源ドメインを1.8V動作用に設定し、SDRAMのI/O電圧レベルに合わせることです。   よろしくお願いいたします。 シェリー

T2081プロセッサからMT29F64G08AECAB 8GB NANDフラッシュにアクセスできない こんにちは、 私はT2081 NXPプロセッサを、IFC経由で外部NANDフラッシュMT29F64G08AECABに接続しています。 私の目標は、CodeWarrior上でこのNANDフラッシュの診断テストを実行するか、あるいはCodeWarrior上でこのデバイスのデバイスIDと製造元IDを読み取ることです（そのためのコードは既に作成済みです）。 この目標を達成するために、私は既に以下のことを実行しました。 1. 生成されたT2081QDS_init_core.tcl で、0xFF800000 から始まるサイズ 1MB のNAND IFC 用の LAW を設定しました。 ## LAW3からIFCへのNAND # ローバー mem [CCSR_ADDR 0x000C30] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000C34] = 0xFF800000 # 戦争 mem [CCSR_ADDR 0x000C38] = 0x81F00013 2. また、以下のようにNANDに対応するCSPRレジスタとFTIMレジスタを設定しました。 NAND_CS 5 を設定 # NANDフラッシュ、アドレス0xFF800000、サイズ1MB、8ビットNAND、ECC無効 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 #マスク mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 プロセッサからNANDへ向かうチップセレクトが2つあり(CS5とCS6)、今のところ最初の4GBにアクセスしようとしているので、CS5のみの設定をしています。 3. 設定済みのTLB: 細かい 1M TLB エントリ 5 : 0xFF800000 - 0xFF8FFFFF (NAND キャッシュ禁止、ガード付き) reg ${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. インストール済みディレクトリにはこのMT29F64G08AECABのサポートが見つからなかったため、マニュアルに従ってこのデバイス用の.xml(4GB分)を作成し、ここに添付しました。 これらすべてを実行した後、CodeWarriorでNANDデバイスの診断テストを実行すると、以下のエラーが表示されます。 代替案として、このデバイスからデバイスIDを読み取るための簡単なC言語コードを書いてみました。そこで、以下のコードをCode Warriorで書き、ここに添付しました。その結果、IFC_NAND_MDRレジスタを読み戻すと、デバイスIDと一致しない0x124E0000が返されます。 診断テストを実行できない、またはデバイスIDを読み取れないのは、私が何か間違ったことをしているか、何かを見落としているからでしょうか。 参考資料として、関連するT2081QDS_init_core.tclファイルと回路図を添付しました。 よろしくお願いいたします。 ニサルガR   QorIQ T2デバイス

Selection of FS2613 chip The FS2613 series chips are quite powerful, and the values and timings of each power rail are editable. However, we don't have much time for software development and prefer not to implement OTP ourselves. Are there any models that are factory-configured to be compatible with the S32K358? For example, like the one shown in the image below? Re: 关于FS2613芯片的选型 See attachment Re: 关于FS2613芯片的选型 Okay, for the MFS2633AMDB2AD model, what are the output voltages of each of the following channels after power-on by default? Where do VCORE, LDO1, LDO2, VREF, VBST, TRK1, and TRK2 originate? Re: 关于FS2613芯片的选型 MFS2633AMDB2AD Search | NXP Semiconductors You can choose this one! Re: 关于FS2613芯片的选型 The MFS2633AMDB2AD is discontinued. With the same specifications, I should replace it with the MFS2633HMDB2AD, right? Re: 关于FS2613芯片的选型 Yes! Re: 关于FS2613芯片的选型 Please submit a new ticket for new questions. Thank you! Re: 关于FS2613芯片的选型 How are PIN.17 FCCU1 and PIN.18 FCCU2 used on this chip? What truth table do the input values of these two pins form, triggering different protection mechanisms of the chip?

rt1189 启动流程 1.如图所示，“图像认证”过程是否会在 安全散列算法(SHA)-512 哈希阶段验证哈希值？ 2. 如果我设置了哈希值，BootROM 会验证镜像完整性吗？如果 BootROM 验证失败，它会进入恢复模式吗？ Re: rt1189 Boot Flow 如上图所示，如果我只对镜像进行签名而不进行加密，它是否能够通过 bootrom 验证流程？此外，启用 oem_close 后，它是否还能进入 bootrom 验证流程？     Re: rt1189 Boot Flow 以下是您两个问题的答案： 1. 仅签名（未加密）的镜像能否通过 BootROM 验证流程？是的。在 RT1180 AHAB 中，签名（认证）是安全启动的必要部分，可确保映像的真实性和完整性，而加密（OTFAD/IEE）是一个独立的、可选的防克隆功能，并非验证的先决条件。因此，仅签名的图像将正常地经过完整的 AHAB 签名验证流程，这也是 NXP 官方 SPSDK rt118x_secure_boot 示例中的标准方法。 2. 启用 oem_close (OEM_CLOSED) 后，是否仍会进入验证流程？是的，验证将成为强制性要求。 建议：在执行 oem_close 之前，请先将签名映像编程到 OEM_OPEN 状态，并确认其启动成功且无 ELE 事件，然后再关闭设备（SRKH 一旦熔丝就不可逆），以避免损坏设备。 （请参阅：i.MX RT1180 网络安全参考手册。）通过公司账户签署保密协议后，请向在线技术销售代表提交申请。） Re: rt1189 Boot Flow 1. 是否只有在启用签名认证功能时才启用哈希验证？如何独立启用哈希验证？如何将设备过渡到 OEM_CLOSED 生命周期状态？ 2. 我将启用恢复启动熔丝。 3. 我的目标是使用未加密的图像。启动ROM应计算并验证镜像哈希值。如果哈希验证失败，启动 ROM 应进入恢复启动流程，并从 LPSPI NOR Flash 启动恢复映像。 Re: rt1189 Boot Flow 嗨@yanyanwang ， A1：是的。RT1180 使用 AHAB 协议，并采用两层认证： 签名层：ECDSA（安全散列算法(SHA)-256 / 安全散列算法(SHA)-384）验证容器头和图像数组条目（存储每个图像的哈希值）。 哈希层：ROM 重新计算已加载图像主体的摘要，并将其与存储在图像数组条目中的哈希值进行比较。 图中所示的 安全散列算法(SHA) 哈希阶段正是这种强制性的完整性检查，它确实会验证哈希值。 A2： ROM始终会计算并比较哈希值，但是否强制执行错误取决于设备的生命周期：出厂默认配置为 Open，此时会运行身份验证，但所有身份验证错误都会被忽略，镜像仍然可以执行。只有在设备切换到 OEM_CLOSED 状态后，哈希值不匹配才会真正阻止启动。 是否进入恢复模式取决于恢复启动熔丝。如果启用，主启动身份验证失败将触发从恢复设备重新加载和重新身份验证；如果未启用，则流程将进入串行下载器/致命模式/RESET循环。 此致， 加文 Re: rt1189 Boot Flow 使用 multicore_trigger 和 cm7_helloworld 这两个演示程序时，我没有为 CM7 ITCM 启用 ECC。我使用 SPT 工具将 CM33 镜像和 CM7 镜像（旨在从内存运行）合并成一个镜像，然后通过 UART 将合并后的镜像编程到或非 Flash 中。然而，启动过程失败了。根据手册，一个容器最多可以包含 8 个 OEM 图像条目。在我的测试中，我只包含了两张图片：一张 CM33 图片和一张 CM7 图片。CM7 ITCM ECC 未启用。 CM33 和 CM7 镜像均未启动。但是，当我检查容器头时，发现其中只有 CM33 镜像。CM33 镜像本身单独使用时可以正常启动，不会出现任何问题。 我想了解为什么 CM7 镜像没有被包含或按预期处理，以及缺少 CM7 ITCM ECC 配置是否会影响 Boot ROM 处理 CM7 镜像的方式。 问题2： 如果我将 8 个 CM7 镜像和 1 个 CM33 镜像合并到一个容器中，启动过程中 Boot ROM 会执行什么操作？ 由于只有一个 CM7 内核，启动 ROM 如何确定应该启动哪个 CM7 镜像？如果所有 8 个图像条目都是 CM7 图像，启动 ROM 会加载所有 8 个图像、只选择一个图像，还是将选择权交给 CM33 应用程序？ Boot ROM 如何识别和处理同一容器中的多个 CM7 映像条目？是否存在优先级、映像索引、核心 ID、加载地址、入口点或其他机制来确定执行哪个 CM7 映像？ 我还想了解启用 CM7 ITCM ECC 和未启用 CM7 ITCM ECC 时启动 ROM 的确切行为。 启用 CM7 ITCM ECC 时，启动 ROM 是否会初始化 CM7 ITCM ECC 存储器，将 CM7 映像从 NOR Flash 复制到 CM7 ITCM，然后释放 CM7 的 RESET 状态？或者说，Boot ROM 只负责加载 CM7 镜像，而 CM33 应用程序负责解除 CM7 的 RESET 状态并启动它？ 当 CM7 ITCM ECC 未启用时，启动 ROM 在遇到加载地址位于 CM7 ITCM 中的 CM7 映像时会做什么？启动 ROM 是否会跳过 CM7 镜像、无法加载、使 CM7 保持重置状态，或者导致整个容器启动过程失败？ 我尤其想确认一下是否支持以下容器： 图片 0：CM33 图1：CM7 图2：CM7 图3：CM7 图4：CM7 图5：CM7 图6：CM7 图7：CM7 图8：CM7 如果支持，那么在启动 ROM 时，这 8 个 CM7 镜像究竟会发生什么？哪个元器件负责选择实际执行的 CM7 镜像？ 最后，我想澄清一下，最多 8 个 OEM 镜像条目是指容器可以简单地存储 8 个不同的镜像，还是 Boot ROM 也提供了一种机制，可以为给定的核心选择和启动特定的镜像。