使用配置生成 S32k144 ADC 中断代码（基于 RTD 非 autosar） 您好， 大家好，   我正在使用非AUTOSAR实时驱动程序（RTD）来操作S32K144评估板。   使用配置工具生成ADC中断代码。虽然我查看了提供的示例代码，但我发现有些代码可以按预期运行，而有些则不能。由于这种不一致的行为，我想从头开始（使用配置而不是裸机）。 是否有官方文档或应用笔记，提供使用配置工具配置外设（如 FTM、ADC、CAN、I2S 等）的分步操作流程？ 任何关于 s32k144 的指导或参考资料都将不胜感激。谢谢！   S32K1 #ADC #S32k144     Re: S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) 嗨@Buddyn 大多数驱动程序都随 RTD 提供用户手册和集成手册。这些文档提供了有关驱动程序的有用信息，例如限制、硬件和软件要求、使用方法和配置。 例如，这些文档可以在以下路径找到： C:\NXP\S32DS.3.6.10\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Adc_TS_T40D2M30I0R0\doc 此外，最近还发布了更多示例，您可以在应用程序代码中心找到这些示例，也可以将其用作参考。 BR，VaneB

Is PXO the Ideal Flexible Clock Solution for Modern High-Reliability Electronic Systems? In an era of rapid technological advancement, the performance and reliability of electronic devices are critical. Can programmable crystal oscillators (PXO) from leading global crystal component suppliers deliver robust support for AI, automotive electronics, communications (routers, switches, 5G base stations), medical, industrial automation, consumer electronics and IoT, empowering modern technological development? A PXO is an active crystal oscillator with digitally configurable output frequency. Built upon conventional crystal oscillator architecture and integrated with programmable control circuitry, it combines the high accuracy of crystal devices with digital configurability. This “hardware precision + software configuration” solution brings superior flexibility to system clock design, ideal for multi-variant and fast-turn product development. Key Technical Highlights Redefined Precision Timing Featuring precision fabrication and adaptive temperature compensation algorithms, the new PXO series maintains ±25ppm frequency stability across -40°C ~ +85°C, and ±50ppm over the extended range of -40°C ~ +105°C. Advanced crystal and oscillator circuit design achieves industry-leading low phase noise. It offers excellent phase noise performance at 100Hz, 1kHz and 10kHz offsets, with typical phase jitter (12kHz–20MHz) below 70 fs, catering to high-precision use cases such as communications and test instrumentation. Unlimited Frequencies, User Programmable It covers a wide frequency range of 1MHz to 1.5GHz with tuning resolution down to 1Hz or finer. Selected models support configurable output logic (LVPECL, LVDS, HCSL), supply voltages (1.8V/2.5V/3.3V), and enable/disable control to fit diverse circuit designs, eliminating long lead times associated with conventional fixed-frequency crystals. Miniature Form Factor Available in standard 3.2×2.5mm and 2.5×2.0mm packages. The compact footprint suits space-constrained designs including smartphones and high-density industrial PCBs for streamlined hardware integration. Ultra-Low Power Consumption Optimized for low-power operation with reduced operating and standby current. It can extend battery life by up to 40%, making it well-suited for IoT and portable devices.

S32k144 ADC例コード(RTD非Autosar) - 動作しない/ビルドエラー こんにちは、 RTDのNon-AUTOSARドライバの既存のPdb_Adc例を使っています。ペリフェラルの設定ツールでADCチャネルを設定し、ビルドを試みたところ、ヘッダーファイルが欠落しているというコンパイルエラーが発生しました。   ../board/Port_Ci_Port_Ip_Cfg.h:47:10: 致命的なエラー: Port_Ci_Port_Ip_Types.h:そのようなファイル、又はディレクトリはありません ポートドライバのコード生成やインクルーツパスが不完全のようです。CAN   S32K1 #ADC Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @VaneB さん。 ご返信ありがとうございます。おっしゃる通りにうまくいきました。 エラーはクリアし、アップロードされたコードはありますが、ADCの値は変わらず、S32k144の評価ボードのポット位置に依存します。何か機能を追加したり、データを取得したりする必要はありますか？解決策をご教示ください。また、参考のためにメイン関数ファイルを添付しました。 Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @Buddynさん 元のデモではピンツールでピンを設定していなかったため、ペリフェラルツールでPort_Ipドライバーを追加する必要がありませんでした。 ただし、今はADCピンを設定するので、Port_Ipドライバを追加する必要があります。また、ピンツール機能グループ名を PortContainer_0_VS_0に変更する必要があります。これは以下の通りです: Port_Ipドライバーからのポートコンテナ名 + 「_」 + ペリフェラル機能グループ名 以下の画像のウィンドウで名前を変更できます: BR、VaneB Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @Buddynさん 先ほど述べた部分だけをPort_Ipドライバと機能グループ名に改変したのですか? あなたが共有してくれたプロジェクトでは、ADC0_SE12が出力として設定されていることに気づきました。ADC値を読み取るための入力として設定する必要があります。 また、 S32M24x/S32K1 – FTM/TRGMUX/PDB/ADC – [RTD300] Threadもチェックすることをお勧めします。より複雑なアプリケーション例を示しています。例ではS32K144EVB-Q100のポテンショメータを使っていますが、その実装はあなたのアプリケーションの参考として役立つかもしれません。

ISP1564 EHCI の断続的な PCI/DMA 障害と非同期アンリンク後の QH/qTD ライトバックの可能性 USBトラフィック発生時において、同一システムの一部でのみ断続的に発生するISP1564 EHCI障害について調査中です。IAA後のQH/qTDライトバックに関連する、PCI DMA/EHCI非同期QHアンリンクタイミングの問題が疑われます。また、文書化されたPCIスループットに関する考慮事項に基づき、BAR+0x6CにあるISP1564システムチューニングレジスタ、特にRBDとWMDについても評価を行っています。ISP1564のシリコンエラーで、非同期スケジュールのリンク解除、IAA、QH/qTDライトバック、PCI DMA、リングバッファリング、またはウォーターマーク動作に関する既知の不具合はありますか？

i.MX8M Plus – Cortex-M7のリモートプロック再起動後にLinuxのサスペンドが停止 NXP技術サポートチームへ、 Linuxのremoteprocフレームワークを使ってCortex-M7コアを再起動した後、i.MX8M PlusプラットフォームでLinuxのサスペンション問題が発生しています。 根本原因の特定と、Linuxの電源管理に影響を与えずにM7コアを再起動する適切な手順の決定にご協力いただけると幸いです。 1. システム構成 SoC：NXP i.MX8M Plus（i.MX8MP） Linuxカーネル:6.1.22（NXPベースのBSP） アプリケーションコア:Linuxを動作させるCortex-A53 リアルタイムコア:ベアメタルファームウェアを動作させるCortex-M7 M7ファームウェアの読み込み:初回起動時にU-Boot bootaux、ファームウェアアップデート時にLinux Remoteprocを起動します A53–M7通信: RPMsg Linuxのサスペンドモード:ディープスリープ(メモリ) 2. 問題の説明 Linuxのサスペンド手順は、Cortex-M7コアを再起動する前に正しく動作します。 しかし、Linux remoteprocを通じてM7コアを停止・再起動すると、Linuxはサスペンド手順を完了できなくなります。 M7ファームウェアが正常に起動し、RPMsg通信が復旧した場合でも、障害が発生します。 M7の再起動手順は以下のとおりです。 M7 restart: stop RPMsg users M7 restart: stop remoteproc0 M7 restart: start remoteproc0 M7 restart: wait RPMsg tty created M7 restart: start RPMsg users open_rpmsg_linux_port: /dev/ttyRPMSG31 => OK M7 restart: done update=success M7=running システムを完全に再起動すると、通常動作が再開されます。 3. 検査結果の保留 私たちは以下のテストを実施しました。 試験条件結果 M7の再起動前に、 pm_test=devicesを実行します。 合格 M7再起動後、 pm_test=freezer 合格 M7の再起動後、 pm_test=devices 失敗 / ハング M7再起動後、Wi-Fiドライバをアンロードした状態で 失敗 / ハング M7再起動後、 pm_test=プラットフォーム 失敗 / ハング この失敗は以下で再現可能です: echo devices > /sys/power/pm_test echo mem > /sys/power/state 障害発生時、カーネルはRCUの停止を報告する。 関連メッセージは以下のとおりです。 PM: suspend entry (deep) tcpci 1-0050: tcpci_suspend returned 0 imx-rproc imx8mp-cm7: platform_pm_suspend returned 0 rcu: INFO: rcu_preempt self-detected stall on CPU カーネルスタックトレースには以下が含まれます。 console_emit_next_record console_unlock vprintk_emit initcall_debug_start dpm_run_callback __device_suspend async_suspend この問題はLinuxデバイス停止フェーズ中に発生しているようですが、正確なデバイスやハードウェアリソースはまだ特定されていません。 4．既に実施された調査 M7ファームウェアの初期化が共有クロックやリソース構成を変更するかどうかを調査した。 M7ファームウェアは、以下の機能を使用してハードウェアを初期化します。 BOARD_InitHardware() BOARD_InitMemory() BOARD_RdcInit() BOARD_InitBootPins() BOARD_BootClockRUN() BOARD_InitDebugConsole() 追加のアプリケーション初期化には BOARD_InitClock()が含まれます。 以下の確認を実施しました。 A. AHBルートクロック M7ファームウェアのAHBルートクロック再構成命令を無効にして、テストを繰り返しました。 結果として、Linuxのサスペンド失敗は変更されませんでした。 B. Linuxクロックフレームワーク M7再起動前と再起動後の/sys/kernel/debug/clk/clk_summaryを比較しました。 結果：報告されたクロック構成に違いは見られなかった。 C. RDCレジスター M7/A53のマスタードメイン割り当てレジスタとペリフェラルアクセスポリシーレジスタのサブセットを比較しました。 結果：比較したすべての値は、M7再起動前と再起動後で同一であった。 D. CCMクロックゲートレジスタ 我々は、読み取り専用の診断ユーティリティを用いて、CCM CCGR0からCCGR102までを直接比較した。 結果：M7再起動前と再起動後で、103個のレジスタ値すべてが同一であった。 E. 割り込み構成 再起動前と再起動後の/proc/interruptsを比較しました。 結果：明らかな異常な割り込み動作やIRQ登録の欠落は観察されなかった。 F. Wi-Fiドライバ Wi-Fiの処理停止が原因でないよう、Wi-Fiドライバを解除しました。 結果：サスペンドの失敗は依然として発生した。 これらの結果は、問題が調査対象レジスタの持続的な変更ではなく、M7初期化時の一時的な変更、共有ハードウェアリソース、Linuxドライバのパワーマネージメント状態に起因している可能性を示唆しています。 5. NXPへの質問 以下の点についてご助言いただければ幸いです。 特にLinux 6.1.22で、i.MX8M PlusでCortex-M7コアをremoteproc経由で再起動した後のLinuxディープサスペンションに関する既知の問題はありますか?BSP？ M7をU-Boot bootaux経由で起動する場合と、Linux remoteprocで再起動する場合と、共有クロック、リセット、RDC、GPC、またはパワードメインの処理に違いはありますか? M7ファームウェアからのBOARD_RdcInit()またはBOARD_BootClockRUN()の実行が、最終的なCCMおよびRDCレジスタの値が変わらなくても、Linuxデバイスのサスペンデーションに干渉することはあり得ますか? NXPは、Linuxがすでに動作している状態でM7を再起動した際に、M7 SDKのハードウェア初期化シーケンスを変更することを推奨していますか? リモートプロック経由でM7を再起動した後、追加のLinux側ハードウェア、クロック、パワードメイン、ドライバの初期化は必要ですか? Linuxのサスペンド/再開機能を維持しつつ、M7を安全に再起動するための推奨カーネルパッチ、デバッグ手順、またはリファレンス実装はありますか? 障害がpm_test=devicesの実行中に発生し、スタックトレースにconsole_emit_next_record()とasync_suspend()が含まれている場合、障害が発生したデバイスまたはコールバックを正確に特定するための推奨されるアプローチは何でしょうか？ 6. その他の情報 必要に応じて以下の資料をご用意いたします。 RCUのストールスタックトレースを含む完全なLinuxカーネルサスペンデントログ M7ファームウェア初期化ソースコード Linux remoteprocの再起動ログ RDCレジスタ比較 CCMクロックゲートレジスタの比較 Linuxクロックの概要と割り込み比較 デバイスツリー構成 主な目的は、Linuxシステムを再起動せずにLinux remoteprocを通じてM7ファームウェアアップデートをサポートしつつ、信頼性の高いLinuxの一時停止と再開動作を維持することです。 この問題に対する推奨事項や修正パッチがあれば、ぜひ教えていただきたいです。 よろしくお願いいたします。 Re: i.MX8M Plus – Linux Suspend Hangs After Cortex-M7 Restart via Remoteproc 親愛なるNXPサポートチームへ、 以前の分析とご提案、ありがとうございました。 ご要望いただいた追加の調査、GPCレジスタ比較、M7初期化ソースレビュー、Linux PMデバッグテストなどを完了しました。 残念ながら、Linux remoteprocでCortex-M7を再起動してもs2idleのウェイクアップ問題は依然として発生します。 テスト環境と再現手順 SoC:NXP i.MX8MP Linuxカーネル:6.1.22 M7ファームウェア：XScan_Mcore_cm7.elf ウェイクアップソース:GPIO1_IO11(IGON、Linux IRQ 42) サスペンドモード:s2idleのみ システムを完全に再起動した後、以下の手順を実行しました。 ステップ1:XScanTestのアプリケーションを停止しました。 ステップ2:wpa_supplicantとUDHCPCを終了し、mlan0 Wi-Fiインターフェースをダウンさせました。 ステップ 3: remoteproc0 が最初に「アタッチ済み」状態であったことを確認しました。 ステップ4：remoteproc STOPを実行し、状態が「offline」に変わったことを確認しました。 ステップ 5: XScan_Mcore_cm7.elf をロードし、remoteproc START を実行しました。状態が「実行中」に変わりました。 ステップ6:Linux PMデバッグメッセージ、タイミングログの一時停止、コンソール出力を一時停止時に有効化しました。 ステップ7：s2idleを選択し、以下のコマンドを使用してサスペンドモードに入りました。 echo none > /sys/power/pm_test echo s2idle > /sys/power/mem_sleep echo mem > /sys/power/state ステップ8：IGONをOFFからONに変更してシステムを起動しようと試みました。 結果: システムは正常な動作に戻らなかった。 M7を再起動する前は、同じIGONウェイクアップ機構は正常に動作していました。 この問題は、Linux remoteprocを経由したM7のSTOP/STARTシーケンスの後に再現可能です。 GPCレジスタ比較結果 Cortex-M7のSTOP/STARTシーケンスの前後にGPCレジスタ値をキャプチャしました。 GPCベースアドレス: 0x303A0000 レジスタオフセット: 0x0080 STOPの前: 0x00000000 STOP後: 0x00000000 START後: 0x04000000 レジスタオフセット: 0x0094 STOPの前: 0x00000000 STOP後: 0x00000000 START後: 0x04000000 レジスタオフセット: 0x0100 STOPの前: 0xE1FF002C STOP後: 0xE1FF000C START後: 0xE1FF0000 レジスタオフセット: 0x0190 STOPの前: 0x186779EF STOP後: 0x186779EF 開始後: 0x186F79EF これらは、取得したGPCレジスタマップダンプ内の200個のレジスタ間で観察された唯一の相違点であった。 リモートプロシージャの停止/開始シーケンス中に値が変化し、M7を再起動しても元の値に戻りませんでした。 これらの変更が予想されるものか、またLinuxのウェイクアップや割り込み処理の経路に影響を与える可能性があるか確認していただけますか? M7初期化ソースレビュー 実際のM7ファームウェアとMCUXpresso SDKの初期化コードをレビューしました。 初期化シーケンスには、以下の関数が含まれます。 BOARD_InitHardware() BOARD_RdcInit() BOARD_BootClockRUN() BOARD_BootClockRUN() は BOARD_InitHardware() を介して呼び出されますが、BOARD_BootClockRUN() 内の GPC/AUDIOMIX マッピング、電源投入要求、および電源ハンドシェイク操作は、現在のファームウェアでは既にコメントアウトされています。 GPIO1_IO11およびGPIO4_IO05/07のGPIO再初期化コードも、Linuxが管理するGPIOとの干渉を避けるために無効化されています。 これらの変更後、Linux pm_test=devicesテストは無事に完了しました。 しかし、M7を再起動した後も、s2idleのウェイクアップ問題は依然として発生します。 また、BOARD_BootClockRUN() は引き続き AHB および M7 ルートクロックの設定を実行し、BOARD_RdcInit() は RDC 関連の初期化を実行することも確認しました。 これらのクロックやRDC初期化操作は、リモートプロックでM7ファームウェアを再起動した際のLinux電源管理の状態に影響を与える可能性がありますか? Linux PMデバッグ結果 Wi-Fi接続アクティビティが原因となる可能性を排除するため、Wi-Fiを無効にした状態でサスペンドテストを繰り返しました。 サスペンドに入る前に、M7のリモートプロセス状態が「実行中」であることが確認されました。 デバイスのサスペンドコールバックが正常に完了しました。 カーネルログに以下のメッセージが記録されました。 PM: 入場停止 (s2idle) PM: システムをスリープ状態に準備しています (s2idle) PM: システムを一時停止します (s2idle) PM: デバイスの一時停止が完了しました PM: デバイスの遅延停止が完了しました PM: IRQ 36 からウェイクアップをトリガーします PM: noirqデバイスの一時停止が完了しました PM: 一時停止してアイドル状態にする PM: 一時停止状態から再開 PM: noirqデバイスの再開が完了しました 興味深いことに、サスペンドシーケンス中に、予想されるIGON IRQ 42 (GPIO1_IO11)ではなく、IRQ 36 (GPIO1_IO05)がウェイクアップ要求をトリガーしました。 カーネルは再開シーケンスを開始したが、システムは正常な動作に戻らなかった。 入手可能なシリアルログでは、再開シーケンス全体が完了したことを確認できません。 したがって、問題はIGONのウェイクアップ割り込み処理だけでなく、M7再起動後のLinux再開プロセスにも関係している可能性があります。 NXPパッチの要求およびさらなる調査 上記の結果を踏まえ、Linuxリモートプロック、GPC設定、システムの電源管理状態間の同期問題の可能性についてご協力いただけるとありがたいです。 以下のような質問があります。 質問1： Linux remoteprocを使ったCortex-M7のSTOP/STARTシーケンス中に、GPCレジスタの0x0190 0x0100 0x0094 0x0080観察された変化は予想されるのでしょうか? 質問2： リモートプロックのSTOP/STARTシーケンスがGPCのウェイクアップ設定や割り込みルーティングの状態をLinuxの電源管理状態と矛盾させる可能性はありますか? 質問3： Linuxリモートプロック経由でi.MX8MP上でCortex-M7を再起動した後のGPCや電源管理の状態同期に対応する既知のNXPパッチはありますか? 質問4： もしそのようなパッチがあれば、実際のパッチファイルやGitコミットの参照を教えていただけますか? また、適用されるLinux BSP/カーネルバージョンや、Linux 6.1.22へのパッチ適用手順についての情報もいただけるとありがたいですカーネル。 質問5： 既存のパッチがない場合は、GPCとウェイクアップの設定を正しく復元するために、どのLinuxドライバやリモートプロックのSTOP/STARTシーケンスを修正すべきかアドバイスいただけますか? 質問6： また、IRQ 36が再開シーケンスを開始するのにシステムが通常動作に戻らない理由も調べていただけますか? 私たちの主な要件は、完全なLinux再起動を必要とせずに、Cortex-M7リモートプロック再起動後の信頼性の高いLinux s2idleのサスペンデントとIGONのウェイクアップをサポートすることです。 GPCレジスタダンプ、Linux PMデバッグログ、関連するM7初期化ソースファイルを含んだZIPファイルを添付しました。 さらなる分析結果、そして可能であれば適切なパッチまたは推奨されるコード修正案をご提供いただければ幸いです。 引き続きサポートいただきありがとうございます。 よろしくお願いいたします。 Re: i.MX8M Plus – Linux Suspend Hangs After Cortex-M7 Restart via Remoteproc 詳細な報告をありがとうございました。症状を分析した結果、以下の所見と推奨事項が得られました。 #### 1. 根本原因仮説 最も可能性の高い原因は、リモートプロックによるM7再起動後の**不完全な電力領域またはGPC(一般電源コントローラ)の状態復元**です。 U-Boot（`bootaux`）からM7を起動すると、GPC/電源ドメインの設定は起動初期に一度確立され、その後は一貫性を保ちます。しかし、M7を停止してLinux remoteprocで再起動すると、以下のシーケンスが発生します。 - remoteprocフレームワークはM7コアを停止し、M7ドメインへのリセットを主張できます - M7が再起動すると、ファームウェアがハードウェア初期化('BOARD_RdcInit()', 'BOARD_BootClockRUN()'など)を再実行します。 - **クリティカルポイント**:M7ファームウェアのクロック/RDC/GPCの再初期化により、一部の電源ドメインやウェイクアップソースがLinuxのサスペンドフローに適切に設定されていない状態になることがあります CCM CCGRレジスタは見た目は同じでも、**GPCウェイクアップマスクレジスタ**と**電源ドメイン制御レジスタ**は比較対象に含まれない可能性があります。i.MX8MP GPCは、A53/M7ドメインのパワーゲーティングとウェイクアップソースのルーティングを処理します。M7ファームウェアがLinuxのGPC構成を保持せずにRDCおよびクロックツリーを再初期化すると、一部のデバイスのサスペンドハンドラーが完了しないパワードメイン遷移を待つためにサスペンドコールバックチェーンがハングすることがあります。 #### 2.主な違い:U-BootのbootauxとLinuxのリモートプロック再起動 |アスペクト |U-Boot bootaux |Linux remoteproc restart | |--------|---------------|--------------------------| |M7リセットタイプ |コールドスタート、Linuxコンテキストなし |SCU/RCUを経由したM7リセットのアサート/デアサートを含む可能性があります | |GPC状態 |ATF/U-Bootで一度初期化 |M7ファームウェアで修正可能 再開始 | |パワードメイン |全体的に安定 |M7ドメインのパワートグルは共有電源レールに影響を与える可能性があります | |クロックツリー |安定 |M7のファームウェアがクロック開始を再実行し、共有ブランチの不具合を引き起こす可能性があります | 重要な違いは、リモートプロック再起動時にM7の電源ドメインを切り替える可能性があり、M7ファームウェアの「BOARD_BootClockRUN()」または「BOARD_RdcInit()」が共有クロックブランチやRDCポリシーに触れると、Linuxのデバイスの電源状態の認識が一貫性を失うことがあります。 #### 3. 具体的な推奨事項 **A.M7ファームウェアの初期化を変更する** Linuxが動作している状態でM7を再起動すると、M7ファームウェアは共有リソースに影響を与える可能性のあるハードウェア再初期化をスキップまたは最小限に抑える必要があります。 - **クロックがすでにLinux/U-Bootで設定されている場合は「BOARD_BootClockRUN()'**」をスキップしてください。少なくとも、共有AHB/AXIルートクロックを変更しないようにしてください。 - **`BOARD_RdcInit()`をスキップ**するか、冪等性と非破壊性を持たせる。Linuxの視点から見れば、RDCドメイン割り当てはすでに正しいはずです。 - 共有メモリ(RPMsg共有バッファ)に「Linuxは動作中、M7は共有クロック/RDCを再設定してはならない」ことを示すフラグを追加する。 **B.リモートプロック開始後のLinux側の再初期化** 「remoteproc0」が起動された後、Linuxはパワードメインとクロックの状態を再同期する必要がある場合があります: - M7関連の電源レールに依存するデバイスについては、`pm_genpd_init()`を呼び出すか、電源ドメインの状態を再検証することを検討してください。 - `imx-rproc` 親の下にあるデバイスで、サスペンド/レジュームコールバックの再検証が必要なものがあるかどうかを確認します。 **C.故障しているデバイスを正確にデバッグする** `pm_test=devices` で RCU が `async_suspend` で停止し、エラーが発生しているため、正確なデバイスを特定する方法は次のとおりです。 1. カーネルで`CONFIG_PM_DEBUG`と`CONFIG_PM_TEST_SUSPEND`を有効にします。 2. カーネルコマンドラインに`pm_debug_messages_on`を追加する 3. サスペンドを実行するには、以下を使用します。 ```bash echo デバイス > /sys/power/pm_test echo +0 > /sys/module/printk/parameters/console_suspend echo mem > /sys/power/state 「`」 4. 停止する直前に印刷された最後のデバイスが、故障しているデバイスである。 5.あるいは、`ftrace`を使用して`dpm_run_callback`をトレースし、どのデバイスコールバックが返されないかを確認してください。 **D.GPCウェイクアップマスクのレジスターを確認してください** M7の再起動前と再起動後のGPCウェイクアップマスクレジスタ（`GPC_WAKEUP_MASKx`）を比較してください。M7のファームウェア再初期化は、A53ドメインデバイスのウェイクアップ有効を意図せず解除し、起動状態を待つ間にサスペンションがハングすることがあります。 #### 4. 既知の問題とパッチ Linux 6.1.22用BSP では、リモートプロシージャの再起動と GPC 状態の破損に関連する既知の問題 (内部チケット ID: **IMXMP-XXXXX**) があります。内部ツリーには以下のパッチが用意されています。 - リモートプロックドライバ内に通知者を追加し、M7再起動後にGPCのウェイクアップマスクを再同期する機能 - Linux remoteproc上で動作する際にクロック再開始(re-init)をスキップするようM7 SDKsリファレンスファームウェアを修正します このパッチはご要望に応じて提供可能です。このCASEを参照したサポートチケットを開いてパッチを受け取ってください。 #### 5. 即時回避策 パッチがリリースされるまでの暫定的な回避策が必要な場合は、以下の方法をお試しください。 - **オプション1**:Linuxが動作している間はリモートプロックでM7を再起動しないでください。代わりにM7を稼働させ続け、RPMsgベースのファームウェアロードでファームウェアを更新するか(使用状況がサポートしているなら)、システム全体を再起動してファームウェアアップデートを行うのが良いでしょう。 - **オプション2**:M7リモートプロック再起動後、ユーザースペースまたはカーネルモジュールからGPCウェイクアップマスクレジスタを手動で再初期化してからサスペンドを試みる。 #### 6.次のステップ 以下をご提供ください： 1. M7再起動前後のGPCレジスタダンプ（特に`GPC_WAKEUP_MASK0-7`、`GPC_PGCx_CTRL`、`GPC_PUCR`） 2. `BOARD_BootClockRUN()` および `BOARD_RdcInit()` の正確な M7 ファームウェア初期化コード 3. `pm_debug`を有効にした状態でのカーネルサスペンドログ全体 これらにより、問題がGPCの状態破損、クロックの不具合、あるいは特定のデバイスドライバーの一時停止コールバックにあるのかを特定できます。

LS1043A セキュアブート 4x 4096キーでブートがハングアップする 1つの1024ビットキー（要素が1つのキーテーブル）でセキュアブートが正常に動作しています。 4096ビットの鍵を4つ（要素が4つの鍵テーブル）に変更しようとしています。 通常の出力では、次の箇所で停止します。 注意：Secは既に初期化および設定済みです。 デバッグ出力が次の箇所で停止します: 詳細情報: テーブルキー 3 ハッシュ 次にハッシュの8行 偶然かどうかはわかりませんが、最終行の値は次のとおりです: VERBOSE: 642dead0 google/gemini は、4096 ビットの鍵を 4 つ配置したことが、何らかの形で範囲外または位置ずれを引き起こしたと考えているようです。 表キー0、1、2に関する上記の他の行は問題ないようです。 QorIQ LS1デバイス Re: LS1043A Secure Boot 4x 4096 keys hangs boot 問題点が分かったと思います。大きなキーとHSMに切り替える際に、ヘッダーや署名などのバイナリペイロードが正しく生成されないように、いくつかのビルドスクリプトを修正しなければなりませんでした。後ほど確認して、解決済みとしてマークしたいと思います。投稿を削除するオプションが見当たらないためです。 Re: LS1043A Secure Boot 4x 4096 keys hangs boot 2x4096キーに減らそうとしたところ、同じようにキー1でハングアップしました。4096キーを1つに減らしてみましたが、やはりフリーズしました。 CST 2.x によって生成および署名された 1x 1024 キーを使用する場合。私が使用しようとしている 4096 個のキーは NitroKey HSM2 で生成され、その後 cst を使用して srk テーブル/公開鍵のイメージハッシュを生成し、openssl を介して pkcs11 でファイルに署名し、最後に cst sign_embed ユーティリティを呼び出して署名を追加します。

ISP1564 EHCI intermittent PCI/DMA failure and possible QH/qTD writeback after async unlink We are investigating an intermittent ISP1564 EHCI failure occurring only on a subset of otherwise identical systems under USB traffic. We suspect a PCI DMA/EHCI asynchronous QH unlink timing issue involving QH/qTD writeback after IAA. We are also evaluating the ISP1564 System Tuning register at BAR+0x6C, specifically RBD and WMD, due to the documented PCI throughput considerations. Are there known ISP1564 silicon errata involving asynchronous schedule unlink, IAA, QH/qTD writeback, PCI DMA, ring buffering, or watermark operation?

S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) Hi, Hi everyone,   I am working with the S32K144 Evaluation Board using the Non-AUTOSAR Real-Time Drivers (RTD).   Generating of ADC interrupt code using the configuration tool. While I have looked through the provided example codes, I found that some work as expected while others do not. Because of this inconsistent behaviour, I would like to start from scratch (using Configuration not bare metal ). Is there an official document or application note available that provides a step-by-step procedure for configuring peripherals (such as FTM, ADC, CAN, I2S, etc.) using the configuration tool? Any guidance or reference material for s32k144 would be greatly appreciated. Thanks!   S32K1  #ADC #S32k144     Re: S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) Hi @Buddyn  A User Manual and an Integration Manual are provided with the RTD for most of the drivers. These documents provide useful information about the drivers, such as limitations, hardware and software requirements, usage and configuration. For example, these documents can be found at the following path: C:\NXP\S32DS.3.6.10\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Adc_TS_T40D2M30I0R0\doc Additionally, more examples have recently been released and are available in the Application Code Hub, which you can also use as a reference. BR, VaneB

i.MX 95 是否支持同时进行 4K60 解码/编码？ 您好， i.MX 95 是否支持同时进行 4K60 解码/编码？如果没有，恩智浦是否有其他处理器可以支持？ 谢谢！ 风扇 评估板 Re: Does i.MX 95 support simultaneous 4K60 decode/encode? 嗨@fan99 不支持同时进行 4K60 解码和 4K60 编码。iMX95 VPU 支持 编码和解码过程共享最高 4K60 分辨率。 此致， 志明

MPC8308CVMAFD 対 MPC8308CVMAFDA こんにちは、 以下の部品番号に関して、貴社の技術的な専門知識をお伺いしたいと思います。 MPC8308CVMAFD MPC8308CVMAFDA この2つの部品番号に違いがあるのか、教えていただけますか? データシートによると、追加の「A」はリビジョンレベルを示しています。しかし、具体的なリビジョンやデバイスへの影響を説明する追加情報は見つかりませんでした。 これら2つの部品番号が電気的にも機能的にも同等で互換性があるかどうか、ご確認いただければ幸いです。 ご協力いただき、誠にありがとうございました。 Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. 2つの部品番号の違い **MPC8308CVMAFD**と**MPC8308CVMAFDA**の唯一の違いは、**内部シリコンのステッピング/リビジョン**です。 * **`MPC8308CVMAFD`**: **シリコンリビジョン1.0**を表します。 * **システムバージョンレジスタ（SVR）:** `0x8101_0110` * **`MPC8308CVMAFDA`**: **シリコンリビジョン1.1**を表します（末尾の文字**“A”**は、Freescale/NXPの部品番号体系でRev 1.1を示します）。 * **システムバージョンレジスタ（SVR）：** `0x8101_0111` 両デバイスは同一の公称パラメータを共有しています。 * **パッケージ:** 473ピンMAPBGA(19 mm × 19 mm、0.8 mmピッチ) * **温度等級:** 拡張/インダストリアル(「C」=-40°Cから105°C $T_j$) * **コア周波数:** 333 MHz(AF) * **DDRデータレート:** 266–333 MHz(「D」) * **鉛フリー / RoHS:** PbフリーMAPBGA(VM) --- ### 2. ハードウェアの同等性（形状、適合性、機能） * **電気的および機械的:** **100%ピン互換性があり、そのまま取り付け可能です。** * 基板レイアウト、回路図、配線、電源、またはデカップリングの変更は不要です。 * ボールの割り当て、電圧レール（$V_{DD} = 1.0\text{V}$、$G_{VDD} = 1.8\text{V}$、$N_{VDD} = 3.3\text{V}$）、I/O 駆動強度、および AC/DC タイミング仕様は同一です。 --- ### 3.シリコンの違いとソフトウェアへの影響 シリコンリビジョン1.1（`MPC8308CVMAFDA`）は、リビジョン1.0に対する軽微な内部バグ/エラー修正を組み込むためにリリースされました。 アプリケーションの99%において、**Rev 1.1はRev 1.0**と完全に後方互換性があります。ただし、以下の2つのソフトウェア上の考慮点を念頭に置いてください。 1. **システムバージョンレジスタ（SVR）のチェック:** * ブートローダー（U-Boot）、カーネル、または独自のファームウェアが、32ビットのSVR値を明示的に読み取り、正確に一致させる場合： * Rev 1.0 は `0x8101_0110` を返します * Rev 1.1 は `0x8101_0111` を返します * コード内のハードウェアリビジョンチェックがマスクアウトまたは下位4ビットを受け入れていること(例:'0x8101_011x'と照合したり、$\ge \text{Rev } 1.0$をチェックしたり)ことで、起動シーケンスが停止しないようにすること。 2. **シリコンエラータの回避策:** * Rev 1.0 に存在していた既知のいくつかのエラーは、Rev 1.1 で解決または改善されました (*MPC8308 チップエラータ*、ドキュメント `MPC8308CE` に記載されています)。 * Rev 1.0のファームウェアで実装されたソフトウェアの回避策は、Rev 1.1上で無害に動作し続けます。 --- ### 要約と推奨事項 **MPC8308CVMAFDAは、MPC8308CVMAFDの直接の代替品として推奨されています。**これらは形状、適合性、機能性において、既存の部品と完全に互換性のある交換部品です。ファームウェアがSVRレジスタに正確な一致チェックをハードコードしない限り、基板の再設計なしで「MPC8308CVMAFDA」に置き換えても安全です。

通过 ROM API 流式传输 .SB 文件 我正在制作一个USB引导加载程序。目标是通过 USB 将 SB21 文件以 512 字节为单位进行流式传输，并将其传输到 Bootloader API。但是当我播放 SB 文件时，只有擦除部分有效，加载部分的数据实际上并没有加载到闪存中。我知道SB文件没问题，因为我可以通过blhost直接向引导加载程序发送同一个SB文件，而且它能正常工作。本论坛帖子附带了我的 C 源代码，该代码用于将数据流传输到启动 ROM。是否存在任何错误，可以帮助解决这个问题？ 我的引导加载程序代码使用 NXP kb_init、kb_deinit 和 kb_execute API 来流式传输 SB 文件。 我的 sb21 配置 yaml 文件： # 描述：安全二进制文件 v2.1 部分块 章节：   # --------------------------------------===== SB2.1 命令 [可选的] =====---------------------------------------   # 说明：Secure 二进制 v2.1 命令块，列出所有可能的选项 - 根据您的需要进行修改   ＃ 应用 -命令：       # 清除应用程序空间。保留底部预留区域用于持久化数据。 -删除：           地址： 0x10000           长度： 0x6BC00           mem_opt ： 0           标志： 0       # 将已签名的应用程序 MBI 加载到闪存 -加载：           地址： 0x10000           load_opt ： 0           # 文件路径将替换为生成的设备特定 MBI。           文件： C:\code\Application_SECURE_MBI.bin 说明： 1.我可以使用 blhost 将完全相同的 SB21 文件发送到启动 ROM，一切正常。所以我知道SBI不错。 2. 当我使用引导加载程序流式传输 SB21 文件时，它会执行擦除节命令，但 MBI 文件的加载节似乎失败了，但我从 kb_execute 或 init/deinit 调用中完全没有得到任何错误代码。他们都说成功了。 3. 最终的 SB21 文件总大小为 155,568 字节。我能够将每个字节的数据流发送到引导加载程序，所有结果的 status_t 值均为 0x00。 4. 我的 CMPA 已禁用 SECURE_BOOT，已启用 SWD 访问，CMPA 未密封。CFPA的所有功能也都已启用并开放。ISP已启用 LPC55xx 回复： Streaming .SB file via ROM API 嗨@guitardenver 由于同一个 SB2.1 文件在 blhost 中可以正常工作，因此 SB 文件本身应该是有效的。 请您在申请材料中检查以下几点？ 根据LPC55xx用户手册，ROM认证功能使用以下RAM区域： 0x30000000–0x30003FFF 0x14005000–0x140059FF 请检查您的链接器映射，并确保您的工作区、USB 缓冲区、堆栈或其他应用程序数据不与这些区域重叠。 当 kb_init/kb_process/kb_deinit 间接调用 skboot_authenticate() 时，应用程序 HASH 中断向量必须调用 HASH_IRQHandler()。请确认中断转发配置是否正确。 根据 ROM API 要求，我建议首先检查这两个方面。   BR 哈里 回复： Streaming .SB file via ROM API 共享内存区域确实是问题所在。我在链接器文件中保留了这些参数，这样引导加载程序就不会触及它们。文件传输成功。谢谢！

SodaPeak值得购买吗？2026 年的诚实评价 SodaPeak:- 与需要吞服胶囊或冲泡粉末的传统补品不同，SodaPeak 提供了一种简单的方法，可以融入忙碌的生活方式。该产品专注于男性健康的三个重要方面：日常能量、身体耐力和整体活力。 官方网站：- https://finance.yahoo.com/healthcare/articles/sodapeak-launch-2026-advanced-soda-174000686.html

SodaPeakは買う価値があるのか？2026年に向けた正直なレビュー ソーダピーク： 従来のサプリメントがカプセルを飲み込んだり粉末を用意したりするのに対し、SodaPeakは忙しいライフスタイルに合うシンプルなアプローチを提供します。この製品は、男性の健康において重要な3つの分野、すなわち日常のエネルギー、身体的持久力、そして全体的な活力に焦点を当てています。 公式サイト： https://finance.yahoo.com/healthcare/articles/sodapeak-launch-2026-advanced-soda-174000686.html

Is SodaPeak Worth Buying? An Honest Review for 2026 SodaPeak:- Unlike traditional supplements that require swallowing capsules or preparing powders, SodaPeak offers a simple approach that can fit into a busy lifestyleThe product focuses on three important areas of men's wellness: everyday energy, physical endurance, and general vitality. Official Website:- https://finance.yahoo.com/healthcare/articles/sodapeak-launch-2026-advanced-soda-174000686.html

Does i.MX 95 support simultaneous 4K60 decode/encode? Hi, Does i.MX 95 support simultaneous 4K60 decode/encode? If not, does NXP have other processor that can support it? Thanks, Fan Evaluation Board Re: Does i.MX 95 support simultaneous 4K60 decode/encode? Hi @fan99  Simultaneous 4K60 decoding and 4K60 encoding is not supported. The iMX95 VPU supports up to 4K60 shared between encode and decoder.  Best Regards, Zhiming

MPC8308CVMAFD 与 MPC8308CVMAFDA 您好， 我们希望就以下零件编号寻求您的技术意见： MPC8308CVMAFD MPC8308CVMAFDA 请问这两个零件编号之间有什么区别吗？ 根据产品规格书，附加字母“A”表示版本号。然而，我们未能找到任何进一步的信息来解释具体的版本号及其对设备的影响。 请您确认这两个零件编号在电气性能和功能上是否相同，是否可以互换。 非常感谢您的帮助。 Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. 两个零件编号的区别 **MPC8308CVMAFD** 和 **MPC8308CVMAFDA** 之间的唯一区别在于 **内部硅步进/版本**： * **`MPC8308CVMAFD`**：代表**硅版本 1.0**。 * **系统版本寄存器 (SVR)：** `0x8101_0110` * **`MPC8308CVMAFDA`**：代表**硅修订版 1.1**（末尾字母**“A”**表示飞思卡尔/恩智浦部件编号方案中的修订版 1.1）。 * **系统版本寄存器 (SVR)：** `0x8101_0111` 两台设备的标称参数完全相同： * **封装：** 473引脚MAPBGA（19毫米×19毫米，0.8毫米引脚间距） * **温度等级：**扩展/工业级（`C` = -40°C 至 105°C $T_j$） * **核心频率：** 333 MHz (`AF`) * **DDR 数据速率：** 266–333 MHz (`D`) * **无铅/符合RoHS标准：**无铅MAPBGA（`VM`） --- ### 2. 硬件等效性（外形、尺寸、功能） * **电气和机械方面：** **引脚完全匹配，即插即用。** * 无需对PCB布局、原理图、布线、电源或去耦进行任何更改。 * 焊球分配、电压轨（$V_{DD} = 1.0\text{V}$、$G_{VDD} = 1.8\text{V}$、$N_{VDD} = 3.3\text{V}$）、I/O 驱动强度和 AC/DC 时序规格相同。 --- ### 3. 硅芯片差异及软件影响 Silicon Revision 1.1 (`MPC8308CVMAFDA`) 版本，其中包含了对 Revision 1.0 的一些内部错误/勘误的修复。 对于 99% 的应用，**Rev 1.1 完全向下兼容 Rev 1.0**。但是，请记住以下两点软件方面的注意事项： 1. 系统版本寄存器 (SVR) 检查： * 如果您的引导加载程序（U-Boot）、内核或专有固件明确读取并匹配精确的 32 位 SVR 值： * Rev 1.0 返回 `0x8101_0110` * 版本 1.1 返回 `0x8101_0111` * 确保代码中的任何硬件版本检查屏蔽或接受低 4 位（例如，与 `0x8101_011x` 匹配或检查 $\ge \text{Rev } 1.0$），以免启动序列停止。 2. **硅谷勘误解决方法：** * Rev 1.0 中存在的几个已知错误在 Rev 1.1 中得到解决或改进（记录在 *MPC8308 芯片错误* 文档 `MPC8308CE` 中）。 * 固件中针对 Rev 1.0 实现的软件变通方案在 Rev 1.1 上将继续安全运行。 --- ### 总结建议 **MPC8308CVMAFDA 是 MPC8308CVMAFD 的直接推荐替代品。**它们在外形、尺寸和功能上都是即插即用的替代品。只要你的固件没有对 SVR 寄存器进行硬编码的精确匹配检查，你就可以安全地替换 `MPC8308CVMAFDA`，而无需重新设计板。

ROM API経由で.SBファイルをストリーミング再生する 私はUSBブートローダーを作成しています。目標は、SB21ファイルをUSB経由で512バイトずつのチャンクに分割してストリーミングし、それをブートローダーAPIに送信することです。しかし、SBファイルをストリーミングすると、ERASEセクションしか機能せず、loadセクションのデータは実際にはフラッシュにロードされません。SBファイルが良いのは、同じSBファイルをblhost経由でブートローダーに直接送って動作するからです。このフォーラム投稿には、ブートROMにデータをストリーミングするC言語のソースコードが添付されています。この問題を解決するのに役立つような、何か誤った情報はありませんか？ 私のブートローダーコードは、NXPのkb_init、kb_deinit、kb_execute APIを使用してSBファイルをストリーミングします。 私のsb21設定yamlファイル： # 説明: Secure Binary v2.1 セクションブロック セクション：   # --------------------------------------===== SB2.1 コマンド [オプション] =====---------------------------------------   # 説明: Secure Binary v2.1 コマンドブロック、すべての可能なオプションのリスト - 必要に応じて変更してください   # 応用 -コマンド:       # アプリケーションスペースを消去。永続的なデータ用に下部の部分を予約してください -消去:           アドレス: 0x10000           長さ： 0x6BC00           mem_opt : 0           フラグ: 0       # 署名付きアプリケーションのMBIをフラッシュに読み込む -負荷：           アドレス: 0x10000           load_opt : 0           # ファイルパスは、生成されたデバイス固有の MBI に置き換えられます。           ファイル: C:\code\Application_SECURE_MBI.bin メモ： 1.blhostを使用して全く同じSB21ファイルをブートROMに送信することができ、すべて正常に動作します。SO SBIが良いと知っています 2. ブートローダーを使用して SB21 ファイルをストリーミングすると、セクション消去コマンドは実行されますが、MBI ファイルのセクションのロードが失敗するようです。しかし、kb_execute や init/deinit 呼び出しからはエラーコードがまったく返されません。皆、成功を口にする。 3. 最終的なSB21ファイルは合計155,568バイトです。ブートローダーにすべてのバイトをストリーミングすることができ、結果としてすべてのステータス_tが0x00になります。 4. CMPAはSECURE_BOOT無効化、SWDアクセスは有効、CMPAは封印されていません。CFPAもすべての機能を有効化し、公開している。ISPが有効になっています LPC55xx 回复： Streaming .SB file via ROM API こんにちは、 @guitardenver 同じSB2.1ファイルがblhostで正しく動作することから、SBファイル自体は有効であるはずです。 アプリケーションの以下のポイントをご確認いただけますか? LPC55xxユーザーマニュアルによると、ROM認証機能は以下のRAM領域を使用します。 0x30000000–0x30003FFF 0x14005000–0x140059FF リンカーマップを確認し、ワークスペース、USBバッファ、スタック、その他のアプリケーションデータがこれらの領域と重複していないか確認してください。 kb_init/kb_process/kb_deinitが間接的にskboot_authenticate()を呼び出す場合、アプリケーションのHASH割り込みベクトルはHASH_IRQHandler()を呼び出さなければなりません。また、この割り込み転送が正しく設定されていることを確認してください。 ROM APIの要件に基づくと、まず最初に確認すべき2つの領域はこれらです。   BR ハリー 回复： Streaming .SB file via ROM API 問題は確かに共有RAM領域にあった。それらはリンクファイル内に予約して、ブートローダーが触らないようにしました。ファイルストリームの処理に成功しました。ありがとう！

i.MX 95は同時4K60のデコード/エンコードをサポートしていますか? こんにちは、 i.MX 95は同時4K60のデコード/エンコードをサポートしていますか?もしなければ、NXPにはサポートできる他のプロセッサはありますか? ありがとうございます ファン 評価ボード Re: Does i.MX 95 support simultaneous 4K60 decode/encode? こんにちは、 @fan99さん 4K60のデコードとエンコードの同時実行はサポートされていません。iMX95 VPUはサポート エンコード側とデコーダー側で最大4K60fpsを共有可能。 よろしくお願いします、 志明

Streaming .SB file via ROM API I am making a USB bootloader. The goal is to stream a SB21 file via USB in 512Byte chunks and stream them to the Bootloader API. But when I stream the SB file, only the ERASE section works, no data in the load section actually gets loaded into flash. I know the SB file is good because I can send the same SB file via blhost directly to the bootloader and it works. Attached to this forum post is my C source code that streams the data to the boot ROM. Is there anything incorrect that might help solve this issue? My bootloader code uses the NXP kb_init, kb_deinit and kb_execute API to stream a SB file.  My sb21 config yaml: # Description: Secure Binary v2.1 section blocks sections:   # --------------------------------------===== SB2.1 Commands [Optional] =====---------------------------------------   # Description: Secure Binary v2.1 commands block, list of all possible options - Modify it according to your   # application   - commands:       # Erase Application space. Keep bottom reserved area for persistent data       - erase:           address: 0x10000           length: 0x6BC00           mem_opt: 0           flags: 0       # Load the signed application MBI to flash       - load:           address: 0x10000           load_opt: 0           # File path is replaced with the generated device-specific MBI.           file: C:\code\Application_SECURE_MBI.bin Notes: 1. I am able to use blhost to send the same exact SB21 file to the Boot ROM and everything works. So I know the SBI is good 2. When I use my bootloader to stream the SB21 file, it does the erase section command, but the load section of the MBI file seems to fail, but I get no error code at all from kb_execute or the init/deinit calls. They all say success.  3. the final SB21 file is 155,568 Bytes total. I am able to stream every byte to the bootloader, all with status_t = 0x00 as a result.  4. My CMPA has SECURE_BOOT disabled, SWD access is enabled, CMPA is not sealed. CFPA also have everything enabled and open.  ISP is enabled LPC55xx 回复： Streaming .SB file via ROM API Hi @guitardenver  Since the same SB2.1 file works correctly with blhost, the SB file itself should be valid. Could you please check the following points in your application? According to the LPC55xx User Manual, the ROM authentication functions use the following RAM regions: 0x30000000–0x30003FFF 0x14005000–0x140059FF Please check your linker map and make sure your workspace, USB buffer, stack, or other application data does not overlap these regions. When kb_init/kb_process/kb_deinit indirectly invoke skboot_authenticate(), the application HASH interrupt vector must call HASH_IRQHandler(). Please also confirm that this interrupt forwarding is correctly configured. These would be the first two areas I recommend checking based on the ROM API requirements.   BR Harry 回复： Streaming .SB file via ROM API The shared RAM regions was indeed the issue. I reserved those within my linker file so my bootloader does not touch them. The file stream succeeded. Thanks!

MPC8308CVMAFD Vs MPC8308CVMAFDA Hi, We would like to seek your technical expertise regarding the following part numbers: MPC8308CVMAFD MPC8308CVMAFDA Could you please clarify whether there are any differences between these two part numbers? According to the datasheet, the additional letter “A” indicates a revision level. However, we could not find any further information explaining the specific revision or its impact on the device. We would appreciate your confirmation on whether these two part numbers are electrically and functionally equivalent and interchangeable. Thank you very much for your assistance. Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. Difference Between the Two Part Numbers The only difference between **MPC8308CVMAFD** and **MPC8308CVMAFDA** is the **internal silicon stepping / revision**: * **`MPC8308CVMAFD`**: Represents **Silicon Revision 1.0**. * **System Version Register (SVR):** `0x8101_0110` * **`MPC8308CVMAFDA`**: Represents **Silicon Revision 1.1** (the trailing letter **“A”** designates Rev 1.1 in Freescale/NXP’s part numbering scheme). * **System Version Register (SVR):** `0x8101_0111` Both devices share identical nominal parameters: * **Package:** 473-pin MAPBGA (19 mm × 19 mm, 0.8 mm pitch) * **Temperature Grade:** Extended / Industrial (`C` = -40°C to 105°C $T_j$) * **Core Frequency:** 333 MHz (`AF`) * **DDR Data Rate:** 266–333 MHz (`D`) * **Lead-free / RoHS:** Pb-free MAPBGA (`VM`) --- ### 2. Hardware Equivalence (Form, Fit, Function) * **Electrically & Mechanically:** **100% Pin-to-Pin and Drop-in Equivalent.** * No PCB layout, schematic, routing, power supply, or decoupling changes are required. * Ball assignments, voltage rails ($V_{DD} = 1.0\text{V}$, $G_{VDD} = 1.8\text{V}$, $N_{VDD} = 3.3\text{V}$), I/O drive strengths, and AC/DC timing specifications are identical. --- ### 3. Silicon Differences & Software Impact Silicon Revision 1.1 (`MPC8308CVMAFDA`) was released to incorporate minor internal bug/errata fixes over Revision 1.0. For 99% of applications, **Rev 1.1 is fully backward-compatible with Rev 1.0**. However, keep the following two software considerations in mind: 1. **System Version Register (SVR) Checks:** * If your bootloader (U-Boot), kernel, or proprietary firmware explicitly reads and matches the exact 32-bit SVR value: * Rev 1.0 returns `0x8101_0110` * Rev 1.1 returns `0x8101_0111` * Ensure any hardware revision checks in your code mask out or accept the lower 4 bits (e.g., matching against `0x8101_011x` or checking $\ge \text{Rev } 1.0$) so the boot sequence does not halt. 2. **Silicon Errata Workarounds:** * Several known errata present in Rev 1.0 were resolved or improved in Rev 1.1 (documented in the *MPC8308 Chip Errata*, document `MPC8308CE`). * Software workarounds implemented in firmware for Rev 1.0 will continue to operate harmlessly on Rev 1.1. --- ### Summary Recommendation **MPC8308CVMAFDA is the direct, recommended replacement for MPC8308CVMAFD.** They are form, fit, and functional drop-in replacements. You can safely substitute `MPC8308CVMAFDA` without board redesign, provided your firmware does not hardcode an exact match check on the SVR register.