FRDM-i.MX93はM33準備完了以降に起動できません。LinuxとWindowsでUUU SDPSの起動がタイムアウトします。 こんにちは、NXPサポート様 FRDM-i.MX93ボードの復旧についてご協力をお願いします。ボードは、SPLブートの初期段階で「M33 prepare ok」の直後に一貫して停止し、BL31または完全なU-Bootに進みません。UUUリカバリもSDPSの起動中にタイムアウトで失敗します。 役員の詳細： ボード: FRDM-i.MX93 シリアルログに表示されるSoC：0xa1009300 シリアルログに表示されたLC: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的なシリアル出力： 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 再構築された2025 SPLでも、同じ停止ポイントが発生します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 使用したハードウェア構成： P1 = 外部電源、45W USB-Cウォールアダプターでテスト済み P16 = デバッグ用シリアルコンソール P13 = microSDカードスロット P2 = UUU / シリアルダウンローダーモード用のUSB-C接続 PCのUSB電源ではなく、壁のコンセント用アダプターから電源を供給するテストも行いました。行動に変化は見られなかった。 テスト対象のホストシステム： Linux Mint / Ubuntu ホスト Windowsホスト UUUのバージョンをテストしました： ううう 1.5.141 ううう 1.5.243 主な問題は、ボードがSPLに到達し、PMICとDDRを初期化して「M33 prepare ok」と出力した後、何も起こらないことです。「Normal Boot」、「Trying to boot from BOOTROM」、「NOTICE: BL31」、または完全な U-Boot に到達しません。これは、SDカードとeMMCの両方から起動した場合に発生します。 USBシリアルダウンローダーモードでは、ボードはUUUによって検出されます。 sudo ./uuu-lsusb コネクテッド Known USB Devices パスチッププロビデオPID Bcdバージョン 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 しかし、SDPSの起動中にUUUが失敗します。使用されたコマンドは次のとおりです。 sudo ./uuu-V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Linuxでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 HID(W)エラー:LIBUSB_ERROR_TIMEOUT Windowsでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7) これはLinuxとWindowsの両方でテストされ、同じ結果が得られました。 テスト対象画像： NXP公式FRDM-i.MX93 Rev 4.0デモイメージパッケージをテストしました。 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ブートイメージのハッシュ値は次のとおりです。 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 私は、同じブートイメージハッシュを使用するimx93frdm用の独自のYoctoイメージもテストしました。 SDカードからの起動選択が機能することを確認しました。SDカードが挿入されていないSDブートモードでは、シリアル出力はありません。SDカードを挿入したSDブートモードでは、SPLは起動して「M33 prepare ok」で停止します。SDカードブートスイッチは正常に動作しているようです。 また、公式のNXP .wicファイルも確認しました。イメージには、想定される32 KiB / 0x8000オフセットにブートイメージが含まれています。使用したコマンド: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WICには32Kにブートイメージが含まれています" || echo "NXP WICには32Kにブートイメージは含まれていません" 結果: NXP WICには32Kのブートイメージが含まれています つまり、SDカードイメージにはブートコンテナが正しく含まれているようです。 2024.04 SPLイメージだけが問題の原因ではないことを確認するため、Flexbuild/U-Bootを使用してより新しいブートイメージを作成しました。構築されたイメージ内のSPLは以下を示します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) NXP FRDM-IMX93 私は以下の方法で、この新しい flash.bin ファイルを SD カードの 32 KiB オフセットに書き込みました。 sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync 同期 その後、ボードは新しいSPLバナーを印刷し、新しいSDブートイメージが実行されていることを確認した。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK しかし、それでも同じ箇所で停止し、BL31/完全なU-Bootまでは進みませんでした。 eMMCの状態： 当初、eMMCはLinuxログイン画面まで起動したが、ルートファイルシステムに/bin/shが存在しなかったため、rootログインができなかった。復旧試行中に、eMMCは.wicファイルを使用してSD Linuxから書き換えられた。画像。その後、eMMCブートも「M33 prepare ok」の後に停止します。しかし、同じ停止ポイントは、公式のNXPイメージを使用したSDブートと、再構築された2025 SPLを使用した場合にも発生するため、現在の問題はLinux/rootfsよりも前の段階にあるようです。 私が除外されたと考えること： シリアルポートが間違っています：シリアル接続は正常に動作し、SPL出力が表示されます。 PCの電源不良：45Wの外部ACアダプターを使用してテストしました。 SDカードブートスイッチの設定が間違っています：SDカードが入っていない状態でSDブートモードにすると、何も出力されません。 SDイメージにブートイメージがありません：公式NXP WICの0x8000 / 32 KiBにブートイメージが存在することが確認されています。 Linux/rootfsの問題：BL31/完全なU-Boot/Linuxの前に障害が発生します。 UUUのホストOSの問題：UUU SDPSの起動タイムアウトがLinuxとWindowsの両方で発生します。 古い2024 SPLだけが問題で、再構築された2025.04 SPLも「M33 prepare ok」の後に停止します。 これがFRDM-i.MX93の既知の早期起動問題かどうか、確認にご協力いただけますでしょうか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 弊社がリリースしたBSPバージョンをご利用ですか？ i.MXアプリケーション・プロセッサ向け組み込みLinux | NXP Semiconductors どのバージョンのBSPを使用していますか？また、どのバージョンを選択していますか？ 労働者の休暇から戻り次第、当社のボードでテストしてみます。来週の水曜日にオフィスに戻り、テストを実施してから、テスト結果をご報告します。 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私はLF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93を使用しています。画像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows オフィスに戻りましたので、ボードでテストを行い、結果をお知らせします。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 解決できましたか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 同じ問題が発生しています... 私のimx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgapビルドでは、BL31が起動を開始したのを見たことがありません。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows こんにちは、私も現在同じ問題を抱えています。解決策は見つかりましたか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題に直面しています。imx93がSDカードから起動できるようにするため、あるいはUUUが正常に動作するようにするために必要なアップデートはありますか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 他のFRDM-IMX93ボードと比較して、このボード上のメモリチップに違いがあることに気づきました。これが問題解決の手がかりになるかもしれません。 正常に動作する基板にはミクロン製の部品が使われており、故障した基板には見覚えのないメーカーの部品が使われている。     Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題を抱えています。 これは最優先事項としてマークされるべきです。なぜなら、唯一正常に動作するイメージは、工場出荷時にeMMCに搭載されているものだけだからです！もしそれを再フラッシュしたら、解決策が見つかるまでFRDM-IMX93は起動不能な状態になってしまうでしょう。これはDDRメモリのタイミングに関係しているのではないかと疑っています。 私も「M33 prepare ok」で止まってしまいます。これはDDRの設定/タイミングの問題を示しています。私のボードにも、上記の@SynchronicITさんの投稿と同じ「ノーネーム」DDR IC（メーカーロゴに「J」が付いているもの）が搭載されています。 なぜこれらのボードはeMMCで動作イメージを付けて出荷できるのに、NXPのどの画像も動作しないのでしょうか? 工場出荷時に搭載されているeMMC経由で起動した場合（これは正常に動作します）、u-bootのバージョンは以下のとおりです。 U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) 一方、NXPからの最新ダウンロード（LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip）では、「imx-boot-imx93frdm-sd.bin-flash_singleboot」ファイルはU-Bootのバージョンです。 U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) 以下は、正常に動作する工場出荷時イメージのeMMC、および動作しないSDカードに書き込まれたイメージとUUUにアップロードされたu-bootからの完全な出力です。 * 動作確認済み（工場出荷時設定の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 U-Boot 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) リセットステータス: POR CPU:NXP i.MX93(52) Rev1.2 A55、1700 MHz CPU:インダストリアル温度グレード(-40°Cから105°C)、24°Cで対応 モデル:NXP FRDM-IMX93 DRAM:2 GiB ボード:V1.0(ADC2:684、ADC3:271) TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x52] 無駄。CC1でのPower3.0 PDO 0:タイプ0、5000 mV、3000 mA [E] PDO 1:タイプ0、9000 mV、3000 mA [] PDO 2:タイプ0、12000 mV、3000 mA [] PDO 3:タイプ0、15000 mV、3000 mA [] PDO 4:タイプ0、20000 mV、3250 mA [] PDO 5:タイプ3、未定義 PDO 4を要請:20000 mV、750 mA ソース受理リクエスト PDソース準備完了! tcpc_pd_receive_message:ALERTレジスタのポーリング、TCPC_ALERT_RX_STATUSビット失敗、ret = -62 TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x50] コア:229デバイス、32 uクラス、devicetree:別々 MMC: FSL_SDHC: 0, FSL_SDHC: 1 MMCからの読み込み環境...MMC(0)から読み上げています... *** 警告 - CRCが悪い、デフォルト環境を使用しています ビデオリンクの設定に失敗しました 掲載: シリアル 出力: シリアル エラー: シリアル ビルド情報: - ELEファームウェアバージョン2.0.5-7a34cee パーティション#0に切り替える、OK MMC0(パート0)は電流装置です UID: 4a7ff07fa81b46d8b2b59146dfa5af84 フラッシュターゲットはMMC:0です ネット:eth0: ethernet@42890000、eth1: ethernet@428a0000 [プライム] 速攻:通常 通常起動 自動起動を停止するには、任意のキーを押してください: 0 u-boot=> *動作しません* 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 - 下がる - Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題を抱えています。uuu.exe を介してイメージをフラッシュしようとしましたが、同じ「HID(W): LIBUSB_ERROR_TIMEOUT (-7)」エラーが出力されました。私のマザーボードに搭載されているメモリチップも、Micron製ではなく「J」ブランドのものです。

T2080 ATMUのPCIe1用セットアップ 私は2枚のT2080をPCIe接続で連結しています。1台はRCとして、もう1台はEPとして設定しています。私はRCからEPへのトラフィック（読み取り/書き込み）のみをテストしています。PCIe2またはPCIe4間の接続テストを実行すると、テストは正しく機能し、EPに書き込まれたデータはEPからの読み取り時に正しくエコーバックされます。このテストは、EP社のT2080のDRAMへのマッピングを行うだけのものです。つまり、ATMUレジスタ、LAW、TLBは正しく設定されています。 しかし、PCIe1を使用するとテストは失敗します。3つのコントローラセットアップすべてで設定はまったく同じです。SWは単にコンパイルされ、コントローラに適切なメモリ変更を加えてバスをPCIe4からPCIe1に変更します。バス上にPCIeアナライザを設置しています。書き込みと読み込みが想定どおりに完了していることが確認できました。しかし、読み戻されたデータは、RCが前のステップで書き込んだデータとは一致しない。RCからエミュレータを使用して侵入し、PCIeバスを介してEP DRAM（BAR1）にマッピングされたメモリ空間を調べると、繰り返しパターンが見られます。T2080 EPプロセッサに侵入してDRAMを調べると、DRAM開始時に書き込まれた元の値からは変わっていません。PCIe1の何が違うのか。PCIe1がSR-IOVをサポートしていることは知っていますが、有効にしていません。 Re: T2080 ATMU setup for PCIe1 私もPCIe設定を進めているときに似たような問題に遭遇し、ドキュメントを丁寧に確認したことで大きな違いがありました。別のプロジェクトに関連する情報を整理する際に、ハードウェアのリファレンス情報の一部をPinal Assessor Portalと比較しました。セットアップがスムーズに進むことを願っています。最終的に問題が解決した方法を教えていただけると嬉しいです。この話題を持ち出してくれてありがとう。 Re: T2080 ATMU setup for PCIe1 T2080 ATMUのPCIe1向け設定に関する詳細情報は、ハードウェア構成や最適化を検討しているすべての人にとって有益な情報となる。議論は有益で、さらに関連情報はダラス評価データ を通じてさらに参考にすることができます。設定方法や技術的な更新を追跡することで、システム性能の理解を深めるのに役立ちます。ここで共有された洞察に感謝します。同様の話題でのさらなる議論を楽しみにしています。 Re: T2080 ATMU setup for PCIe1 PCIe1用のT2080 ATMU構成は、特にシステムハードウェアやパフォーマンスチューニングに取り組む人にとって興味深い構成トピックに見えます。信頼できる技術的およびドキュメント関連情報をユーザーが見つけるのに役立つ詳細なリソースを共有することは有用です。参考資料として、体系的に整理された公開情報リソースを調べる上で、セジウィック裁判所の審理記録が役立ちました。明確な説明と共有された経験があれば、複雑なセットアップも他の人が理解しやすく、トラブルシューティングしやすくなります。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?欲しい隠しレジスターは何かあります(NXPが過去にいくつか変更するように言ったので存在することは知っています)。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 [NXP] はい。通常レジスタとPCIeコンフィギュレーション空間のダンプが必要です。RCとEPの両方についてこの作業を実施してください。PCIeオフセットについては、T2080RMの表2-5「CCSRブロックベースアドレスマップ」を参照してください。さらに、LAWレジスタのレジスタダンプも必要です。 PEXアナライザーのダンプで具体的に何を求めているのかよくわかりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 [NXP]PEXアナライザーのダンプは、読み取りが書き込みデータを返さない場合に必要です。通過時の分析ツールのダンプも共有して比較できると助かります。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?隠しレジスタは何でも変更してください（NXPから過去にいくつか変更するように指示されたことがあるので、存在することは知っています）。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 PEXアナライザーのダンプに関して、具体的に何を求めているのかよく分かりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 Re: T2080 ATMU setup for PCIe1 RCとEPのダンプ、そしてLAWレジスタも提供できます。PCIeインターフェースのダンプに使う特定のアドレス範囲はありますか?隠しレジスタは何でも変更してください（NXPから過去にいくつか変更するように指示されたことがあるので、存在することは知っています）。通常のレジスタとPCIe設定メモリスペースの両方を聞いているのですか?(これは少し入手が難しいですが、Lauterbachから画面をダンプできます—これは98%正しいです)。 PEXアナライザーのダンプに関して、具体的に何を求めているのかよく分かりません。もし私の言ったことが本当かどうかの証拠(「書いた内容を返さないで」と書かれているなら、それを示すことができます)。 Re: T2080 ATMU setup for PCIe1   PCIeインターフェース(RCとEPの両方)用のレジスタダンプを教えてください。 コンソールログ全体を提供してください PEXアナライザーのダンプ   LAWレジスタのレジスタダンプも必要です。

MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremetal S Hi,I am using the FLASH_ECC_Error_Injection_MPC5744P demo project from SDK 2.1 to test FLASH ECC fault handling. In the bare-metal SDK example:After calling Generate_noncorrectable_FLASH_ECC_error, the core properly traps the fault and enters Machine_check_handler (IVOR1 Handler) as expected. After porting the identical ECC injection logic to my RTOS-based project:No machine check exception occurs, and the code never jumps into Machine_check_handler. I have already completed the following porting & configuration steps: Fully ported and defined IVOR1_Handler in the startup .s assembly file, consistent with the bare-metal demo; Full FCCU alarm interrupt configuration is implemented, but no FCCU alarm interrupt is triggered either when injecting the uncorrectable FLASH ECC error. I have 3 core questions to troubleshoot this issue: What mandatory hardware/register configurations are required to enable entry to the Machine Check Handler (IVOR1) for FLASH uncorrectable ECC errors? Are there special considerations or constraints when running ECC fault injection and machine check exception handling under an RTOS? Could you provide a step-by-step debug/troubleshooting workflow to locate the root cause of this missing machine check exception? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet I don't know mentioned example, I suppose it is ported version on my appnote I did with using of GHS compiler. https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip If RTOS affects the bahavior, then it is needed to investigate what is does with MSR register. Pay attention to chapter 5. Also you may check section 8 to understand ECC handling. Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet HI, I found during testing: In my project, the IVOR1_Vector handler cannot be triggered when compiling with -O1 optimization level. The exception works normally under -O0. However, the reference demo project works correctly with -O1 using the same optimization setting. I would appreciate it if you could share some suggestions to help me locate the root cause.

T2080 ATMU setup for PCIe1 I have 2 T2080s attached to each other on PCIe. I have 1 setup as the RC and the other setup as the EP. I am only testing traffic (reads/writes) to the EP from the RC. When I run the test for connections between PCIe2 or PCIe4 the test functions correctly and data written to the EP is echoed back correctly on reads from the EP. The test is simply mapping to DRAM on the EP's T2080. So the ATMU registers, LAWs, TLBs are set up correctly. However, the test fails when using PCIe1. The configuration is exactly the same for all three controller setups. The SW simply is compiled to change the bus from PCIe4 to PCIe1 with appropriate memory changes to the controllers. We have a PCIe analyzer on the bus. We see the writes and reads complete as expected. But the data read back does not represent the data written in the prior step by the RC. When we break in with an emulator from the RC and examine the memory space mapped to the EP DRAM (BAR1) through the PCIe bus, it appears to be a repeating pattern. When I break in to the T2080 EP processor and examine DRAM it is unchanged from the original values written during DRAM init. What is different about PCIe1. I realize that PCIe1 supports SR-IOV, but I do not have that enabled. Re: T2080 ATMU setup for PCIe1 I ran into something similar while working through a PCIe configuration, and checking the documentation carefully made a big difference. I also compared a few hardware reference details with Pinal Assessor Portal while organizing related information for another project. Hopefully your setup goes smoothly, and I'd be interested to hear what ended up resolving the issue. Thanks for bringing up this topic. Re: T2080 ATMU setup for PCIe1 The details shared about the T2080 ATMU setup for PCIe1 provide useful information for anyone exploring hardware configuration and optimization. I found the discussion informative and more related information can be explored through Dallas Assessment Data for additional reference. Tracking configuration methods and technical updates can help improve understanding of system performance. Appreciate the insights shared here and look forward to more discussions on similar topics. Re: T2080 ATMU setup for PCIe1 The T2080 ATMU setup for PCIe1 looks like an interesting configuration topic, especially for those working with system hardware and performance tuning. It is useful to share detailed resources that help users find reliable technical and documentation related information. For additional reference I found Sedgwick Court Hearings helpful for exploring organized public information resources. Clear explanations and shared experiences can make complex setups easier for others to follow and troubleshoot. Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). [NXP] Yes. We want the dumps for the normal registers and the PCIe configuration space. Do this activity for both RC and EP. You may refer to Table 2-5. CCSR Block Base Address Map from T2080RM for PCIe offset. In addition, the register dump of LAW registers is also required. I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). [NXP] We need PEX analyzer dumps in the failing scenario, i.e., when reads don’t return the written data. It would be great if you also shared analyzer dumps in the passing case to compare. Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). Re: T2080 ATMU setup for PCIe1 I can provide the RC and EP dumps along with the LAW registers. Do you have a specific address range you want for the PCIe interface dumps? Any hidden registers you want (I know they exist as NXP has told us to change a couple in the past). Are you asking for both the normal registers and the PCIe configuration memory space (that is a little harder to get, but I can dump the screen from Lauterbach – which is 98% correct). I am not sure what exactly you are asking for with the PEX analyzer dumps. If you are just looking for proof that what I said is true (that reads don’t return what was written, I can show that). Re: T2080 ATMU setup for PCIe1   Please provide me the register dumps for PCIe interface, both RC and EP. Provide the full console logs PEX analyser dumps   Register dump of LAW registers is also required.

MPC5744P IVOR1 机器检查处理程序在 RTOS 和裸机上未触发不可纠正的 FLASH ECC 错误 您好，我正在使用 SDK 2.1 中的FLASH_ECC_Error_Injection_MPC5744P演示项目来测试 FLASH ECC 故障处理。 在裸机 SDK 示例中：调用 Generate_noncorrectable_FLASH_ECC_error 后，内核正确地捕获了故障，并按预期进入了 Machine_check_handler（IVOR1 Handler）。 将相同的 ECC 注入逻辑移植到我的基于 RTOS 的项目中后：没有发生机器检查异常，代码也从未跳转到 Machine_check_handler。 我已经完成了以下移植和配置步骤： 已在启动文件中完全移植并定义了 IVOR1_Handler。与裸机演示一致的汇编文件； 已实现完整的 FCCU 报警中断配置，但注入不可纠正的 FLASH ECC 错误时，也不会触发 FCCU 报警中断。 为了解决这个问题，我有三个核心问题： 要使机器检查处理程序 (IVOR1) 能够处理 FLASH 不可纠正的 ECC 错误，需要哪些强制性的硬件/寄存器配置？ 在实时操作系统 (RTOS) 下运行 ECC 故障注入和机器检查异常处理时，是否存在特殊考虑或限制？ 能否提供一份分步调试/故障排除工作流程，以查找此机器检查异常缺失的根本原因？ Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 我不了解提到的例子，我猜它是我在应用笔记中使用 GHS 编译器编写的移植版本。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip 如果 RTOS 影响了行为，那么就需要调查它对 MSR 寄存器做了什么。请注意第五章。 您还可以查看第 8 节以了解 ECC 处理方法。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 您好， 我在测试过程中发现： 在我的项目中，使用 -O1 优化级别编译时，无法触发 IVOR1_Vector 处理程序。在 -O0 下，该异常处理程序可以正常工作。 但是，参考演示项目在使用相同的优化设置 -O1 时可以正常工作。 如果您能提供一些建议，帮助我找到问题的根本原因，我将不胜感激。

frdm-i.mx93 无法在 M33 之后启动准备就绪；Linux 和 Windows 上的 UUU SDPS 启动超时 您好，恩智浦技术支持、 我正在请求帮助恢复 FRDM-i.MX93 主板。在 “M33 准备就绪” 之后，板在早期的 SPL 启动期间会立即停止，并且不会继续运行 BL31 或完全 U-Boot。在 SDPS 启动期间，UUU 恢复也会因超时而失败。 董事会详情： 板：FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的串行输出： U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok 重建的 2025 SPL 也出现了同样的停止点： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000） PMIC：PCA9451A PMIC：过载电压模式 DDR：3733MTS DDR：3733 MTS DDR：3733MTS M33 准备好了 使用的硬件设置： P1 = 外部电源，使用 45 W USB-C 墙式适配器进行测试 P16 = 调试串行控制台 P13 = microSD 卡插槽 P2 = 用于 UUU / 串行下载器模式的 USB-C 连接 我还测试了用墙壁适配器供电，而不是用电脑 USB 供电。行为没有改变。 测试的主机系统： Linux Mint / Ubuntu 主机 Windows 主机 已测试的 UUU 版本： uuu 1.5.141 uuu 1.5.243 主要问题是电路板达到 SPL，初始化 PMIC 和 DDR，然后打印 “M33 准备就绪”，然后什么也没发生。它永远不会达到 “正常启动”、“正在尝试从 BOOTROM 启动”、“注意：BL31” 或完整 U-Boot。从 SD 和 eMMC 启动时会发生这种情况。 在 USB 串行下载器模式下，UUU 会检测到主板： sudo ./uuu-lsusb 连接的已知 USB 设备 路径芯片 Pro Vid Pid bcdVersion 5:2 MX93 SDPS： 0x1FC9 0x014E 0x0001 但是，在 SDPS 启动期间，UUU 会失败。使用的命令是 sudo ./uuu-V-b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst 在 Linux 系统上，故障是 启动 cmd: sdps: boot-scanterm-f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT 在 Windows 系统中，故障是 启动 cmd: sdps: 启动-scanterm-f。\ imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 14% 失败 HID (W)：LIBUSB_ERROR_TIMEOUT (-7) 在 Linux 和 Windows 上进行了测试，结果相同。 测试过的图像： 我测试了恩智浦官方 frdm-i.mx93 Rev 4.0 演示映像包： LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 启动映像哈希值为： 7aba6102e5ec64add64add632cd6667e77fa3f6f6f6f6f6f6fd72c314e4c01f2964c0fc056a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 我还测试了自己的 Yocto 镜像 imx93frdm，它使用相同的启动映像哈希值。 我验证了 SD 启动选择是否有效。在未插入 SD 卡的 SD 启动模式下，没有串行输出。在插入 SD 卡的 SD 启动模式下，SPL 在 “M33 准备就绪” 时开始和停止。因此，SD 启动开关似乎正在工作。 我还验证了恩智浦官方的 .wic映像包含预期偏移量为 32 KiB/0x8000 的启动映像。使用的命令 wic=nxp.wic 启动=imx -启动-imx93frdm-sd.bin-flash_singleBoot xxd -l 64 -s $((32*1024))"$WIC" xxd -l 64 -s 0"$BOOT" cmp-n " $ (stat-c%s " $BOOT ") "-i $ ((32*1024)): 0 " $WIC " " $BOOT " & & echo " " NXP WIC 包含 32K 的启动映像" 恩智浦 WIC 不包含 32K 的启动映像 " 结果： 恩智浦 WIC 包含 32K 的启动映像 因此，SD 映像似乎正确包含了启动容器。 为了排除只有 2024.04 SPL 映像是问题所在，我使用 Flexbuild/U-Boot 构建了一个更新的启动映像。内置映像中的 SPL 显示： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000）恩智浦 FRDM-IMX93 我将这个新的 flash.bin 文件写入 SD 卡，偏移量为 32 KiB： sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync 然后，主板打印了新的 SPL 标语，确认它正在执行新的 SD 启动映像： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000） PMIC：PCA9451A PMIC：过载电压模式 DDR：3733MTS DDR：3733 MTS DDR：3733MTS M33 准备好了 但是，它仍然在同一时间停止了，没有继续使用BL31/Full U-Boot。 eMMC 状态： 最初，eMMC 启动到足以登录 Linux 的程度，但由于根文件系统中缺少 /bin/sh，根登录被中断。在尝试恢复过程中，eMMC 使用 .wic 文件从 SD Linux 重写。图像之后，在 “M33 准备就绪” 之后，eMMC 启动也会停止。但是，使用恩智浦官方镜像启动SD时以及重建的2025 SPL也会出现同样的停止点，因此当前的问题似乎早于Linux/rootFS。 我所相信的已经被排除： 串行端口错误：串行端口正常工作并显示 SPL 输出。 电脑电源不良：使用外置 45 W 墙式适配器测试。 错误的 SD 启动开关：没有 SD 卡的 SD 启动模式没有输出。 SD 映像中缺少启动映像：经过验证的启动映像存在于恩智浦官方 WIC 中的 0x8000/32 KiB。 Linux/rootFS 问题：故障发生在 BL31/Full U-Boot/Linux 之前。 UUU 的主机操作系统问题：UUU SDPS 启动超时出现在 Linux 和 Windows 上。 只有旧的 2024 SPL 是坏的：重建的 2025.04 SPL 也在 "M33 准备就绪 "后停止。 你能帮忙确定这是否是已知的 frdm-i.mx93 提前启动问题吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你在使用我们发布的 BSP 版本吗？ 适用于i.MX应用处理器的嵌入式Linux|恩智浦半导体 您正在使用并选择哪个版本的 BSP？ 劳动节回来后，我会尝试在我们的电路板上进行测试，我将在下周三回到办公室然后进行测试，然后给你回复我的测试结果。 祝您有美好的一天 顺祝商祺！ Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我使用的是 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93。图像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我回到办公室将在我们的板上进行测试，然后告诉你结果。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你想出来了吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 我也遇到了同样的问题…… 我从未见过 BL31 使用我的 imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap 版本启动。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 您好，我目前也遇到了同样的问题。请问您找到解决方法了吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到同样的问题。是否有任何更新需要进行哪些操作才能使 imx93 从 SD 卡启动，或者使 UUU 正常工作？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我们注意到该主板上的内存芯片与其他frdm-imx93主板有所不同。或许这有助于找到问题所在。 正常工作的板是微米级的，而故障板的品牌我不认识。     Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到了同样的问题。 这应该标记为高优先级，因为唯一可用的映像是出厂时在 eMMC 上提供的映像！如果重新刷写固件，我的 FRDM-IMX93 就彻底报废了，直到找到解决方案为止，我怀疑这与 DDR 内存时序有关。 我的程序也卡在了“M33 prepare ok”这里，这表明DDR配置/时序存在问题，而且我的主板也和上面@SynchronicIT帖子中的一样，使用了相同的“无名”DDR IC（制造商标志带有“J”）。 为什么这些电路板可以出厂时就带有 eMMC 上的可用镜像，而 NXP 提供的所有可用镜像都无法使用？ 当我通过（出厂预装的）eMMC启动时（启动正常），u-boot 版本为： U-Boot SPL 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） 而从 NXP 下载的最新版本 (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip)“imx-boot-imx93frdm-sd.bin-flash_singleboot”文件是 u-boot 版本： U-Boot SPL 2024.04+gde16f4f1722+p0（2024年9月2日 10:44:35 +0000） 下面显示的是正常工作的工厂镜像 eMMC 的完整输出，以及不正常工作的 SD 卡刷入镜像和 UUU 上传的 u-boot 的完整输出。 * 工作正常（出厂预装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 U-Boot 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） 重置状态：POR CPU：NXP i.MX93(52) Rev1.2 A55，频率 1700 MHz CPU：工业级温度范围（-40℃至105℃），工作温度24℃ 型号：NXP FRDM-IMX93 动态随机存取存储器(DRAM)：2 GiB 板：V1.0（ADC2：684，ADC3：271） TCPC：供应商 ID [0x1fc9]，产品 ID [0x5110]，地址 [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0：0 型，5000 mV，3000 mA [E] PDO 1：0 型，9000 mV，3000 mA [] PDO 2：0 型，12000 mV，3000 mA [] PDO 3：0 型，15000 mV，3000 mA [] PDO 4：0 型，20000 mV，3250 mA [] PDO 5：类型 3，未定义 请求 PDO 4：20000 mV，750 mA 源接受请求 PD源已准备就绪！ tcpc_pd_receive_message：轮询 ALERT 寄存器，TCPC_ALERT_RX_STATUS 位失败，返回值为 -62 TCPC：供应商 ID [0x1fc9]，产品 ID [0x5110]，地址 [I2C2 0x50] 核心：229 个设备，32 个微类，设备树：独立 MMC：FSL_SDHC：0，FSL_SDHC：1 从 MMC 加载环境... 从 MMC(0) 读取... *** 警告 - CRC 校验错误，使用默认环境 视频链接设置失败 输入：串行 输出：串口 错误：串行 构建信息： - ELE固件版本2.0.5-7a34cee 切换到分区 #0，确定 mmc0（第 0 部分）是当前设备 UID：4a7ff07fa81b46d8b2b59146dfa5af84 闪存目标是 MMC:0 网络：eth0：以太网@42890000，eth1：以太网@428a0000 [PRIME] Fastboot：正常 正常启动 按任意键停止自动启动：0 u-boot=> * 无法正常工作 * U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok - 悬挂 - Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到了同样的问题。我无法通过 uuu.exe 刷入任何镜像，输出相同的“HID(W): LIBUSB_ERROR_TIMEOUT (-7)”错误。我主板上的内存芯片也是“J”牌的，而不是美光的。

FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hello NXP Support, I am requesting help recovering an FRDM-i.MX93 board. The board consistently stops during early SPL boot immediately after “M33 prepare ok” and does not continue to BL31 or full U-Boot. UUU recovery also fails during SDPS boot with a timeout. Board details: Board: FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS Typical serial output: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok The same stop point also occurs with a rebuilt 2025 SPL: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Hardware setup used: P1 = external power supply, tested with 45 W USB-C wall adapter P16 = debug serial console P13 = microSD card slot P2 = USB-C connection for UUU / serial downloader mode I also tested powering from a wall adapter instead of PC USB power. The behavior did not change. Host systems tested: Linux Mint / Ubuntu host Windows host UUU versions tested: uuu 1.5.141 uuu 1.5.243 The main issue is that the board reaches SPL, initializes PMIC and DDR, and prints “M33 prepare ok”, then nothing else happens. It never reaches “Normal Boot”, “Trying to boot from BOOTROM”, “NOTICE: BL31”, or full U-Boot. This happens when booting from both SD and eMMC. In USB Serial Downloader mode, the board is detected by UUU: sudo ./uuu -lsusb Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 However, UUU fails during SDPS boot. The command used was: sudo ./uuu -V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst On Linux, the failure is: Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT On Windows, the failure is: Start Cmd:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7) This was tested on both Linux and Windows, with the same result. Images tested: I tested the official NXP FRDM-i.MX93 Rev 4.0 demo image package: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 The boot image hash is: 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot I also tested my own Yocto image for imx93frdm, which uses the same boot image hash. I verified that SD boot selection works. In SD boot mode with no SD card inserted, there is no serial output. In SD boot mode with an SD card inserted, SPL starts and stops at “M33 prepare ok”. So the SD boot switch appears to be working. I also verified that the official NXP .wic image contains the boot image at the expected 32 KiB / 0x8000 offset. Commands used: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WIC contains boot image at 32K" || echo "NXP WIC does NOT contain boot image at 32K" Result: NXP WIC contains boot image at 32K So the SD image appears to contain the boot container correctly. To rule out only the 2024.04 SPL image being the issue, I built a newer boot image using Flexbuild/U-Boot. The SPL inside the built image shows: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) NXP FRDM-IMX93 I wrote this new flash.bin to the SD card at 32 KiB offset using: sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync The board then printed the new SPL banner, confirming it was executing the new SD boot image: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok However, it still stopped at the same point and did not continue to BL31/full U-Boot. eMMC status: Originally, the eMMC booted far enough to reach Linux login, but root login was broken because /bin/sh was missing in the root filesystem. During recovery attempts, the eMMC was rewritten from SD Linux using a .wic image. After that, eMMC boot also stops after “M33 prepare ok”. However, the same stop point occurs from SD boot using the official NXP image and also with the rebuilt 2025 SPL, so the current issue appears to be earlier than Linux/rootfs. What I believe has been ruled out: Wrong serial port: serial works and shows SPL output. Bad PC power: tested with external 45 W wall adapter. Wrong SD boot switch: SD boot mode with no SD card gives no output. Missing boot image in SD image: verified boot image exists at 0x8000 / 32 KiB in the official NXP WIC. Linux/rootfs issue: the failure happens before BL31/full U-Boot/Linux. Host OS issue for UUU: UUU SDPS boot timeout occurs on both Linux and Windows. Only the old 2024 SPL being bad: a rebuilt 2025.04 SPL also stops after “M33 prepare ok”. Could you please help determine whether this is a known FRDM-i.MX93 early boot issue? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Are you using the BSP version we released? Embedded Linux for i.MX Applications Processors | NXP Semiconductors Which version BSP are you using and choose?  I will try to test on our board when I back from Labor holiday, I will back to office on Next Wednsday then will test, then give you reply my test result. Wish you have a nice day Best Regards Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I'm using the LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 image Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am back to office and will test on our board, then tell you the result. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Did you figure it out?  Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang  Having the same issue... I have never seen the BL31 to start booting with my imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap build. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi, I'm currently having the same issue. May I ask if you've figured out the solution yet? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Same issue here. Is there any update what's needed to allow the imx93 to boot from SD or alternatively let UUU work properly? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows We noticed there's a difference in the memory chip on the board in respect to other frdm-imx93 boards. Perhaps this helps finding the issue.  Working board has micron and faulty board has a brand I don't recognize.     Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am having the same issue. This should be marked as HIGH PRIORITY as the only working image is the one factory supplied on the eMMC! If that's re-flashed, I'll have a bricked FRDM-IMX93 until a solution is found, which I suspect is related to DDR memory timings. I too hang at "M33 prepare ok" which indicates DDR config/timing issues and my board also has the same 'no-name' DDR IC as @SynchronicIT post above (manufacturer logo with a 'J'). How is it that these boards can be shipped out with a working image on eMMC but none of the available images from NXP work? When I boot via (factory loaded) eMMC - which WORKS - the u-boot version is: U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) whereas the LATEST download from NXP (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip), the "imx-boot-imx93frdm-sd.bin-flash_singleboot" file is u-boot version: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) Below is the full output from working factory image eMMC and also from non-working SD flashed image and UUU uploaded u-boot. * WORKING (factory loaded eMMC) * U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot Trying to boot from BOOTROM Boot Stage: Primary boot image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from 0x57800 by ROM_API NOTICE: TRDC init done NOTICE: BL31: v2.12.0(release):lf-6.18.2-1.0.0 NOTICE: BL31: Built : 07:53:18, Feb 10 2026 U-Boot 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) Reset Status: POR CPU: NXP i.MX93(52) Rev1.2 A55 at 1700 MHz CPU: Industrial temperature grade (-40C to 105C) at 24C Model: NXP FRDM-IMX93 DRAM: 2 GiB BOARD: V1.0(ADC2:684,ADC3:271) TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0: type 0, 5000 mV, 3000 mA [E] PDO 1: type 0, 9000 mV, 3000 mA [] PDO 2: type 0, 12000 mV, 3000 mA [] PDO 3: type 0, 15000 mV, 3000 mA [] PDO 4: type 0, 20000 mV, 3250 mA [] PDO 5: type 3, undefined Requesting PDO 4: 20000 mV, 750 mA Source accept request PD source ready! tcpc_pd_receive_message: Polling ALERT register, TCPC_ALERT_RX_STATUS bit failed, ret = -62 TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x50] Core: 229 devices, 32 uclasses, devicetree: separate MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... Reading from MMC(0)... *** Warning - bad CRC, using default environment Fail to setup video link In: serial Out: serial Err: serial BuildInfo: - ELE firmware version 2.0.5-7a34cee switch to partitions #0, OK mmc0(part 0) is current device UID: 4a7ff07fa81b46d8b2b59146dfa5af84 flash target is MMC:0 Net: eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME] Fastboot: Normal Normal Boot Hit any key to stop autoboot: 0 u-boot=> * NOT WORKING * U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok -- HANG -- Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I've got the same issue. I was not able to flash any image via uuu.exe, with the same "HID(W): LIBUSB_ERROR_TIMEOUT (-7)" error output. The memory chip on my board is also the "J" branded one, not Micron.

T1042 LAW vs CCSR メモリマップ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私は LAW と CCSR の概念と LAW と CCSR のメモリ マップの違いを理解しようとしていますが、T1040 RM を読んでも自分の見解を明確にすることができませんでした。たとえば、T1040 RM の表 2-3 (LAWs メモリ マップ) では、IFC がアドレス 0x80000000 にマップされていると示されていますが、表 2-5 (CCSR メモリ マップ) では、IFC が 0xFF124000 にあると示されています。 ドライバがデバイスにアクセスするために実際に使用するアドレス (LAW または CCSR) を明確に説明できる人はいますか。 QorIQ T1デバイス Re: T1042 LAW vs CCSR Memory Maps これは本当に興味深い質問です。そして、あなたが指摘している違いは、最初は確かにCANで混乱を招くことがあります。私が学んだことによると、ドライバは通常、ハードウェア ブロックと対話するときに CCSR ビューに依存しますが、LAW はそれらの領域がより高いレベルでどのように変換されるかを記述します。Montgomery County Courtを確認しているときに、さまざまなアクセス目的に合わせてさまざまなマッピングが共存できる仕組みを説明した役立つ背景情報を見つけました。LAW を変換ルール、CCSR を実際に使用されるレジスタ アクセス ビューとして考えると役立つかもしれません。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> これらは、それぞれの FCM (フラッシュ コントロール マシン) コントローラーが使用するベース アドレスです。たとえば、NAND はバッファに SRAM を使用し、0xFF800000 でそれに到達できます。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ありがとう、 alexander.yakovlev‌ 。理論的には違いをある程度理解していますが、T1042D4RDB ボードの次のデバイス ツリー スニペットに記載されているのは、IFC コントローラ (ローカルバス) が 0xFFE124000 (CCSR メモリ マップ) にあるということです。アドレス変換プロパティ「範囲」は、LAWアドレス空間からの親アドレスを示します（アドレス0xfe8000000、0xfff800000、0xfffdf0000は、u-bootのlaw.cのnor、nand、cpldに設定されています）。ファイル） localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; 私が混乱している点が何なのか理解していただければ幸いです。 Re: T1042 LAW vs CCSR Memory Maps <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ローカル アクセス ウィンドウ (LAW) は、プロセッサ アドレス空間を DDR コントローラ、IFC コントローラ、PCI-E などのターゲット インターフェースにマップする方法を構成するために使用されます。 CCSR 空間は、内部プロセッサのメモリマップ レジスタがアドレス空間にマップされる空間です。 表 2-3 では、IFC が「ターゲット」として表示されています。IFC コントローラにコネクテッドされたターゲット デバイスには、このウィンドウからアクセス CAN できます。 表 2-5 は、IFC 関連のメモリ マップ レジスタ、つまり IFC コントローラを構成するために使用されるレジスタを示しています。 すてきな一日を、 アレクサンダー TIC ----------------------------------------------------------------------------------------------------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう！ ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps T1042 LAWとCCSRメモリマップの違いは興味深いもので、特にメモリ領域の整理やアクセス方法を見る際に注目されます。アドレス範囲の明確なドキュメントは、技術的な比較をはるかに容易にします。また、構造化されたグリーンビル郡記録のレビュー は、整理された情報が効率的な研究を支える良い例になると感じています。全体として、これは記憶マッピングの概念に取り組む人にとって有益なトピックです。

T2080 ATMU PCIe1 设置 我有两块T2080显卡通过PCIe接口连接在一起。我有一套设备作为遥控器，另一套设备作为执行遥控器。我只是在测试从 RC 到 EP 的流量（读/写）。当我运行 PCIe2 或 PCIe4 之间的连接测试时，测试功能正常，写入 EP 的数据在从 EP 读取时也能正确回显。该测试只是将数据映射到 EP 的 T2080 上的动态随机存取存储器(DRAM)。所以 ATMU 寄存器、LAW、TLB 都已正确设置。 但是，使用 PCIe1 时测试失败。三种控制器配置完全相同。该软件只需进行编译，即可将总线从 PCIe4 更改为 PCIe1，并对控制器进行相应的内存更改。我们在总线上连接了一个 PCIe 分析仪。我们看到读写操作按预期完成。但是，读取回来的数据并不代表 RC 在前一步写入的数据。当我们使用 RC 模拟器入侵并检查通过 PCIe 总线映射到 EP 动态随机存取存储器\(DRAM\) (BAR1) 的内存空间时，它似乎是一个重复的模式。当我进入 T2080 EP 处理器并检查 动态随机存取存储器(DRAM) 时，发现它与 动态随机存取存储器(DRAM) 初始化期间写入的原始值相比没有变化。PCIe1 有何不同？我知道 PCIe1 支持 SR-IOV，但我没有启用该功能。 Re: T2080 ATMU setup for PCIe1 我在配置 PCIe 时也遇到过类似的问题，仔细查阅文档起到了很大的作用。在为另一个项目整理相关信息时，我还将一些硬件参考细节与Pinal Assessor Portal进行了比较。希望你的安装过程一切顺利，我很想知道最终是什么解决了这个问题。感谢你提出这个话题。 Re: T2080 ATMU setup for PCIe1 分享的有关 PCIe1 的 T2080 ATMU 设置的详细信息，可为任何探索硬件配置和优化的人员提供有用的信息。我发现这次讨论很有启发性，更多相关信息可通过达拉斯评估数据进行参考。跟踪配置方法和技术更新有助于提高对系统性能的理解。感谢各位分享的真知灼见，期待就类似话题展开更多讨论。 Re: T2080 ATMU setup for PCIe1 T2080 ATMU PCIe1 的配置看起来是一个有趣的配置话题，特别是对于那些从事系统硬件和性能调优工作的人来说。分享详细的资源有助于用户找到可靠的技术和文档相关信息。另外，我发现Sedgwick Court Hearings为探索有组织的公共信息资源提供了有用的参考资料。清晰的解释和经验分享可以让其他人更容易理解和排除复杂的故障。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储有特定的地址范围要求吗？您需要哪些隐藏寄存器（我知道它们存在，因为 NXP 之前要求我们修改过几个）？您是需要常规寄存器还是 PCIe 配置内存空间（这部分比较难获取，但我可以提供 Lauterbach 的屏幕截图——准确率高达 98%）？ [NXP] 是的。我们需要普通寄存器和 PCIe 配置空间的转储数据。请对 RC 和 EP 都执行此操作。您可以参考 T2080RM 中的表 2-5“CCSR 块基址映射”来获取 PCIe 偏移量。此外，还需要 LAW 寄存器的转储数据。 我不确定你具体想从 PEX 分析器转储文件中获取什么信息。如果你只是想证明我所说的是正确的（读取操作不会返回写入的内容，我可以证明这一点）。 [NXP] 我们需要故障情况下的 PEX 分析器转储文件，即读取操作未返回写入数据的情况。如果也能分享成功情况下的分析器转储文件以便对比，那就更好了。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储文件有特定的地址范围要求吗？任何你想要的隐藏寄存器（我知道它们存在，因为 NXP 过去曾要求我们更改几个）。您是想要获取普通寄存器和 PCIe 配置内存空间吗？（这有点难获取，但我可以从 Lauterbach 导出屏幕截图——准确率达 98%） 我不太明白您具体需要 PEX 分析器转储文件是什么。如果你只是想寻找证据来证明我所说的是正确的（读取操作不会返回所写的内容，我可以证明这一点）。 Re: T2080 ATMU setup for PCIe1 我可以提供 RC 和 EP 转储以及 LAW 寄存器。您对 PCIe 接口转储文件有特定的地址范围要求吗？任何你想要的隐藏寄存器（我知道它们存在，因为 NXP 过去曾要求我们更改几个）。您是想要获取普通寄存器和 PCIe 配置内存空间吗？（这有点难获取，但我可以从 Lauterbach 导出屏幕截图——准确率达 98%） 我不太明白您具体需要 PEX 分析器转储文件是什么。如果你只是想寻找证据来证明我所说的是正确的（读取操作不会返回所写的内容，我可以证明这一点）。 Re: T2080 ATMU setup for PCIe1   请提供 PCIe 接口的寄存器转储文件，包括 RC 和 EP。 请提供完整的控制台日志 PEX 分析器转储   还需要提供 LAW 寄存器的转储文件。

T1042 LAW vs CCSR Memory Maps I am trying to understand concept of LAW & CCSR and difference between LAW and CCSR memory maps but could not clarify my view after reading T1040 RM. For example table 2-3 (LAWs memory map) in T1040 RM says that the IFC is mapped at address 0x80000000 whereas table 2-5 (CCSR memory map) says that the IFC is at 0xFF124000. Can someone clarify which addresses (LAWs or CCSR) are actually used by drivers to access devices. QorIQ T1 Devices Re: T1042 LAW vs CCSR Memory Maps This is a really interesting question, and the distinction you’re pointing out can definitely be confusing at first. From what I’ve learned, drivers typically rely on the CCSR view when interacting with hardware blocks, while LAWs describe how those regions are translated at a higher level. I came across some helpful background while reviewing Montgomery County Court that explained how different mappings can coexist for different access purposes. It might help to think of LAWs as the translation rules and CCSR as the actual register access view used in practice. Re: T1042 LAW vs CCSR Memory Maps These are base addresses where respective FCM (Flash Control Machines) controllers use. For example nand use SRAM for buffer and with 0xFF800000 you can reach that. Re: T1042 LAW vs CCSR Memory Maps Thanks alexander.yakovlev‌. I have somewhat understood the difference theoratically, but what is mentioned in the following device tree snippet of T1042D4RDB board is that the IFC controller (localbus) is @ 0xFFE124000 (CCSR mem map). While the address translation property 'ranges' mentions the parent addresses from LAW address space (The addresses 0xfe8000000, 0xfff800000, 0xfffdf0000 are set for nor, nand and cpld in u-boot's law.c file) localbus@ffe124000 {         reg = <0xf 0xfe124000 0x0 0x2000>;         ranges = <0x0 0x0 0xf 0xe8000000 0x8000000 0x2 0x0 0xf 0xff800000 0x10000 0x3 0x0 0xf 0xffdf0000 0x8000>;         #address-cells = <0x2>;         #size-cells = <0x1>;         compatible = "fsl,ifc", "simple-bus";         interrupts = <0x19 0x2 0x0 0x0>;         nor@0,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "cfi-flash";             reg = <0x0 0x0 0x8000000>;             bank-width = <0x2>;             device-width = <0x1>;         };         nand@2,0 {             #address-cells = <0x1>;             #size-cells = <0x1>;             compatible = "fsl,ifc-nand";             reg = <0x2 0x0 0x10000>;         };         cpld@3,0 {             compatible = "fsl,t1040d4rdb-cpld", "fsl,deepsleep-cpld";             reg = <0x3 0x0 0x300>;         };     }; I hope you are able to understand what is my point of confusion. Re: T1042 LAW vs CCSR Memory Maps Local Access Windows (LAWs) are used to configure, how processor address space is mapped to target interfaces - DDR controller, IFC controller, PCI-E and etc. CCSR space is space, where internal processor memory-mapped registers are mapped to address space. Table 2-3 shows IFC as "target" - target devices, connected to IFC controller, can be accessed via this window. Table 2-5 shows IFC-related memory mapped registers, i.e. registers used to configure IFC controller. Have a great day, Alexander TIC ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- Re: T1042 LAW vs CCSR Memory Maps The distinction between T1042 LAW and CCSR memory maps is interesting, especially when looking at how memory regions are organized and accessed. Clear documentation of address ranges can make technical comparisons much easier. I’ve also found that reviewing structured Greenville County Records can be a useful example of how organized information supports efficient research. Overall, this is a helpful topic for anyone working with memory mapping concepts.

MPC5744P IVOR1 マシンチェックハンドラがRTOS、ベアメタルSで訂正不能なFLASH ECCエラーでヒットしない こんにちは、SDK 2.1の FLASH_ECC_Error_Injection_MPC5744P デモプロジェクトを使ってFLASH ECCの故障処理をテストしています。 ベアメタルSDKの例では、Generate_noncorrectable_FLASH_ECC_errorを呼び出した後、コアは正しく故障を捕捉し、期待通りMachine_check_handler(IVOR1ハンドラー)に入ります。 RTOS ベースのプロジェクトに同一の ECC インジェクション ロジックを移植した後、マシン チェック例外は発生せず、コードは Machine_check_handler にジャンプしません。 私は既に以下の移植および設定手順を完了しました。 起動時の.sファイルにIVOR1_Handlerを完全に移植して定義しました。アセンブリファイル（ベアメタルデモと互換性あり）。 FCCUアラーム割り込みの設定は完全に実装されていますが、訂正不可能なFLASH ECCエラーを注入してもFCCUアラーム割り込みは発生しません。 この問題を解決するために、3つの重要な質問があります。 FLASHの訂正不能なECCエラーに対してマシンチェックハンドラ（IVOR1）へのアクセスを可能にするために、必須となるハードウェア/レジスタ構成は何ですか？ RTOS上でECC障害注入とマシンチェック例外処理を実行する際に、特別な考慮事項や制約はありますか？ この欠損マシンチェック例外の根本原因を特定するためのステップバイステップのデバッグやトラブルシューティングのワークフローを提供できますか? Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet 挙げられている例は知りませんが、おそらく私がGHSコンパイラを使用して作成したアプリケーションノートの移植版だと思います。 https://www.nxp.com/docs/en/application-note/AN13179.pdf https://www.nxp.com/docs/en/application-note-software/AN13179SW.zip RTOSが動作に影響を与える場合、RTOSがMSRレジスタに対してどのような処理を行っているかを調査する必要がある。第5章に注意してください。 また、ECCの処理方法については、セクション8を参照してください。 Re: MPC5744P IVOR1 Machine Check Handler not hit with uncorrectable FLASH ECC error on RTOS, baremet こんにちは、 テスト中に以下のことが分かりました。 私のプロジェクトでは、-O1最適化レベルでコンパイル中にIVOR1_Vectorハンドラーをトリガーできません。-O0 オプションでは例外処理は正常に機能します。 しかし、参照デモプロジェクトは、同じ最適化設定を使用して-O1オプションで正しく動作します。 根本原因を特定するための提案をいただけるとありがたいです。

iw612 setup mfg mode on i.mxrt1060evkc This document takes i.MXRT 1060 evkc and iw610 M.2 module as example to share how to setup manufactory mode in i.MXRT platform for NXP wifi product.  Hardware Host platform: i.MXRT 1060 evkc Wi-Fi chip: iw610 M.2 evk Software RT1060EVKC SDK 25.12.00 MFG TOOL: MFG-SD-IW610-MF-LABTOOL-Native-BRG-WIN-X86-2.0.0.39.0-18.80.5.p77

Performance degradation in Facemesh Landmark model ptq conversion We were using Google's FaceMesh model released by NXP after ptq in this repo: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 · nxp-imx-support/nxp-demo-experience-demos-list But this model is based on Google's old FaceMesh model, which had 468 landmark points. Now we want to move to Google's new FaceMesh model, which has 478 landmark points. We want to run this on iMX 95 FRDM board NPU. So, we wanted to quantize this. We are using NXP's eIQ-neutron-sdk-linux-3.1.3 to quantize this model. After this quantization, we are seeing significant degradation in model performance, almost unusable for actually using it. Initially we were quantizing it with MIN-MAX option. That model was unusable. Then we tried using percentile option and found a better performance with percentile set to 95 (even though this was regressor outputs). But this is still not giving great performance 1) When NXP created the ptq file for old FaceMesh(468) model which option did they use, MIN-MAX? Or percentile? 2) Is there anything else we need to check when the performance degrade drastically after quantization 3) we profiled with the CelebA dataset used the serialize_image.py in scripts dir with model options specific options, should we run the full media pipe and create the calibration dataset or make changes in serialize script  options supplied serialize_image.py:  -i            //218 x 178 front facing RGB images  -o -f bin -t float32 -m 0to1 -s 256, 256 -layout NHWC -co RGB tflite-profiler: --input  --dataset --output tflite-quantizer: --input  --profile  --quantize-inputs=false      --quantize-outputs=false --quantization-calibration-method= //MinMax or Percentile Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @dhilshad, Thank you for contacting NXP Support! 1) Unfortunately, we do not have that information available at this time. 2) This behavior is expected. Quantization is only one part of the deployment process; converting and optimizing a model for execution on embedded hardware involves several additional steps, such as graph optimization, operator mapping, hardware-specific transformations, and runtime validation. As a result, model behavior and performance can vary even when the model is already quantized. For new designs and evaluations, I recommend using eIQ Olive, as it provides a more modern framework for model optimization and deployment on NXP i.MX platforms. It includes updated workflows and improved support for current machine learning deployment scenarios. Please refer to the following tutorials and documentation for more information: https://eiq.nxp.com/learning-hub/tools/olive/index.html These resources cover the recommended workflows and best practices for deploying machine learning models on i.MX devices. Best regards, Chavira Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @Chavira , Thanks for the replay. And pointing out to the documentation Just to clarify here, our main concern is the accuracy of the model . In case of FaceMesh model, we see that the output landmark points are not accurate enough for our application. As I said earlier, we had found that keeping a 95 percentile cutoff was giving a slightly better result than the MIN MAX. But still not comparable to the accuracy we see in the NXP's ptq model (FaceMesh 468).  We have one more observation: 1) We tried by giving just 8 samples from our production environment as representative dataset. This was slightly improving the result. Then we added 250 images from the same environment and profiled and quantized. But this caused the accuracy to degrade.  Do you have any idea why this kind of behaviour might come? 2) Also, has NXP already converted the Google's new FaceMesh model (with 478 landmark) model to ptq?

Does dtb change the LAW configuration (T2080RDB)? Hi, I am using the T2080RDB. I want to change the memory location for a PCI device. I have changed the dtb. However, it does not work because the LAW register are not modified. I want to know if I must to change uboot and dtb (both of them) in order to get a proper functionality. BR QorIQ T4 Devices Re: Does dtb change the LAW configuration (T2080RDB)? That’s an interesting question about changes in LAW configuration. In many cases, even small adjustments can impact functionality, so it’s always best to cross-check with reliable resources. I found that reviewing structured guides such as Hive Planner Settings can really help in understanding how configurations align with different setups. Keeping track of updates and testing changes in a controlled environment is also highly recommended. Re: Does dtb change the LAW configuration (T2080RDB)? Device Tree only reflects the local address map established by the bootloader. Linux does not change LAWs. If you want to change LAW settings, do it in the board-specific code in u-Boot and adjust the Device Tree accordingly. Re: Does dtb change the LAW configuration (T2080RDB)? Interesting question. From what I've seen, updating the DTB usually changes the hardware description and boot settings rather than modifying the LAW configuration directly, unless the firmware or board support package specifically ties them together. I found some useful background while checking Tarrant Property Details and it reminded me how important it is to verify configuration changes instead of assuming they're automatic. Comparing the before-and-after settings is probably the safest way to confirm whether LAW has actually been affected. Re: Does dtb change the LAW configuration (T2080RDB)? DTB behavior with LAW configuration on the T2080RDB can depend on the specific settings and software version being used. It may be helpful to review the configuration files and related documentation to confirm how parameters are applied. For additional reference on organized record systems resources like DeSoto Court Appeals can provide examples of structured data access. Checking logs and testing changes in a controlled setup can also help identify the exact impact.

iMXEBOOKDC5のタッチコントローラーIC部品番号 チームの皆様へ 私はiMXEBOOKDC5とi.MX8ULP EVKを組み合わせて使用しています。 今のところ、すべて順調に動いています。Eインクディスプレイは正常に動作しており、ボタンとジョイスティックも期待どおりに動作しています。 それでは、ディスプレイのタッチパネルを有効にしたいと思います。しかし、EPDモジュールに使われているタッチコントローラーICの部品番号は特定できません。ICのマーキングがレーザーマーキングで消されているように見えます。 私自身も情報を探してみましたが、見つけることができませんでした。 ぜひ教えていただけますか: iMXEBOOKDC5ディスプレイで使用されるタッチコントローラーのIC部品番号。 タッチ機能をサポートする利用可能なLinuxドライバ、ライブラリ、ソフトウェアパッケージのいずれかです。 ご協力ありがとうございます。 よろしくお願いいたします。 評価ボード Re: Touch Controller IC Part Number for iMXEBOOKDC5 こんにちは、 使用されているタッチコントローラーICはGoodix Technology製のGT911です。 次のリンクでドライバーについてご覧いただけます: https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c よろしくお願いいたします。 Re: Touch Controller IC Part Number for iMXEBOOKDC5 親愛なる、 よろしくお願いいたします。 ちなみに、e-inkパネル用のWayformビンファイルを提供してもらえますか? よろしくお願いいたします。 ライダー

如何评价基于NXP i.MX处理器的Android TV设备上的IPTV服务质量？ 大家好， 我目前正在评估搭载 NXP i.MX 处理器的 Android TV 设备上的 IPTV 播放性能。我不想仅仅根据频道数量来比较服务提供商，我更感兴趣的是影响播放质量的技术方面。 我正在测试的一些指标包括： 高峰观看时段的视频流稳定性 硬件视频解码性能 HLS 和 MPEG-TS 兼容性 通道切换延迟 缓冲区管理 EPG加载性能 以太网与 Wi-Fi 的可靠性比较 对于任何使用 Android TV 或嵌入式多媒体系统的人来说，在评估流媒体服务时，您认为最重要的标准是什么？ 作为我研究的一部分，我最近写了一篇文章，讨论了美国、加拿大和英国用户在选择 IPTV 提供商时需要考虑的因素。它侧重于技术评估，而不是市场营销。如果有人感兴趣，这篇文章可以在Medium上找到。 我也很想了解您在 i.MX 平台上使用 ExoPlayer、VLC 或其他播放框架的体验。 谢谢！

DPAA2イーサネット・スイッチ(dpsw)はパケットを受信ポートに送ります DPAA2のLX2160プロセッサ搭載のイーサネット・スイッチ(DPSW)で問題や制限に直面しました。 dpsw は、パケットの宛先 MAC が既にそのポートで学習されている場合 (つまり、宛先 MAC がそのポートの FDB に登録されている場合) に、そのパケットを受信ポートに返送します。 これにより、スイッチがCiscoのイーサネット・スイッチに接続されている場合に問題が生じます。Cisco イーサネット・スイッチ CDPは、同じ送信元と宛先MACでパケットを送信することでループバックテストを行うためです。DPSWはCisco Switchがポートをシャットダウンさせます。 NXP社が提案している回避策があります。各ポートのFDBに登録されているMACアドレスをスキャンし、それらをACLに追加して、受信ポートへの送信をブロックするスクリプトを作成してください。 例えば、eth2 の問題を修正する必要がある場合は、次のスクリプトを使用します。 tc qdisc add dev eth2 clsact dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'` for dmac in $dest; do tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done コマンドの機能： - qdiscを作成します（ACLについては、お送りしたリンクを参照してください）。 - ブリッジFDBをダンプし、宛先ポートがeth2で、かつタイプが「self」であるすべてのエントリを表示します。 ダンプの結果はawkに渡され、FDBからdmacのみを出力します。 例: 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2 -結果をdestに保存します。- dest を反復処理し、dest 内の各 MAC に対してイングレスに ACL フィルタを追加します。 eth2で受信されるすべてのフローのうち、上記の範囲内のdmacを持つものは、作成されたACLルールによって破棄されます。 しかし、この回避策は場当たり的なやり方のように思える。いくつか問題点があります。 - MACが学習されACLに割り当てられる間には小さなウィンドウが存在し、パケットが受信ポートにループバックされる可能性があります。 - また、デバイスが移動しても、ACL内のMACアドレスは削除されません。移動したデバイスは現在アクセスできない可能性があります。 - 継続的な走査、ACLへの追加およびACLプロセッシングによるパフォーマンスへの影響。 私の質問：これに対処するもっと良い方法はありますか？ Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 「もしかしたら」この方法が効果的か、役立つかもしれませんか?内容を確認し、動作するか、あるいは理にかなっているかどうかについてフィードバックをお願いします。 -------------------------------------------------------------------------------------------------- DPSWポートに受信するeth型ループバック検出フレーム0x9000ドロップするための代替サンプル方法 ---------------------------------------------------------------------------------------------- 例えば、ループバック検出フレーム（ethタイプ0x9000）パケットがeth5 dpswポート経由で受信されている場合（そして、例えばdpmac-18がこのdpswポートにリンクされている場合）、 その場合、汎用的なethタイプ0x9000フレーム（MACアドレスに関係なく）を破棄することで、ハードウェアオフロードルールを実行する方がより良い選択肢となるでしょう。 1. 一時的または既存の設定をすべて削除します。 tc qdisc del dev eth5 clsact 2>/dev/null tc qdisc add dev eth5 clsact 2. 厳格なハードウェアオフロードのドロップルールを適用する tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop ---------------------- 3. ステータスチェック： tc -s filter show dev eth5 ingress restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame" または while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18"| grep "fltr_frame"; sleep 1; done Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port 簡単に言えば、お客様に実装を提供する可能性は非常に低いです: -ハードウェアはソースポートのプリミュニングをサポートしておらず、その機能を実現するにはファームウェアも大幅な変更が必要です(実現可能かどうかも不明です)。なぜなら、プリンを自律的にエミュレートする方法が不可能なからです。 Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port AEチームと話し合っています。

dtb は LAW 構成 (T2080RDB) を変更しますか? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 T2080RDBを使用しています。PCI デバイスのメモリ位置を変更したい。dtbを変更しました。ただし、LAW レジスタが変更されていないため、機能しません。 適切な機能を得るために、uboot と dtb (両方) を変更する必要があるかどうかを知りたいです。 BR QorIQ T4デバイス Re: Does dtb change the LAW configuration (T2080RDB)? これは LAW 構成の変更に関する興味深い質問です。多くの場合、小さな調整でも機能に影響を与える可能性があるため、信頼できるリソースでクロスチェックすることが常に最善です。Hive Planner 設定などの構造化されたガイドを確認すると、構成がさまざまなセットアップにどのように適合するかを理解するのに非常に役立つことがわかりました。管理された環境で更新を追跡し、変更をテストすることも強くお勧めします。 Re: Does dtb change the LAW configuration (T2080RDB)? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> デバイス ツリーは、ブートローダによって確立されたローカル アドレス マップのみを反映します。Linux は LAW を変更しません。 LAW設定を変更したい場合は、u-Bootのボード固有のコードで変更し、デバイスツリーを調整します。 それに応じて。 Re: Does dtb change the LAW configuration (T2080RDB)? T2080RDB上のLAW設定でのDTBの挙動は、使用されている特定の設定やソフトウェアバージョンによって異なります。パラメータの適用方法を確認するために、設定ファイルや関連ドキュメントを確認すると役立つかもしれません。組織化された記録システムに関する追加の参考として、DeSoto Court Appeals のようなリソースが構造化データアクセスの例を提供できます。ログの確認や制御されたセットアップでの変更のテストも、正確な影響を特定するのに役立ちます。 Re: Does dtb change the LAW configuration (T2080RDB)? 興味深い質問ですね。私が見た限りでは、DTBを更新すると通常はハードウェアの記述や起動設定が変更されるもので、直接LOWの設定を変更することはほとんどありません。ファームウェアやボードサポートパッケージがそれらを特に連携させている場合を除きます。タラントの物件詳細を確認している際に、いくつか役立つ情報を見つけました。それによって、設定変更は自動的に行われると決めつけるのではなく、必ず確認することの重要性を改めて認識しました。LAWが実際に影響を受けたかどうかを確認する最も確実な方法は、変更前と変更後の設定を比較することだろう。

NXP i.MX プロセッサベースのAndroid TVデバイスでのIPTVサービス品質はどのように評価しますか? こんにちは、みんな、 現在、NXP i.MX プロセッサを搭載したAndroid TVデバイスでのIPTV再生性能を評価しています。チャネル数だけでプロバイダを比較するのではなく、再生品質に影響を与える技術的な側面に興味があります。 私がテストしている指標には以下のようなものがあります。 ピーク視聴時間帯のストリームの安定性 ハードウェアビデオデコード性能 HLSおよびMPEG-TSとの互換性 チャネル切り替えレイテンシ バッファ マネジメント EPG読み込みパフォーマンス イーサネットとWi-Fiの信頼性の比較 Android TVや組み込みマルチメディアシステムに取り組んでいる方へ、ストリーミングサービスを評価する際に最も重要な基準は何だと考えますか? 私の調査の一環として、最近、米国、カナダ、英国のユーザーがIPTVプロバイダーを選ぶ際に考慮すべき要素について論じた記事を書きました。マーケティングよりも技術評価に重点を置いている。興味のある方は、 Mediumに掲載されている記事をご覧ください。 また、i.MX プラットフォームでのExoPlayerやVLC、その他の再生フレームワークの経験もぜひ聞かせてください。 ご回答をお待ちしています。

DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port I encountered a problem or limitation with their Ethernet Switch (dpsw) in the DPAA2 with LX2160 processor. dpsw sends a packet back to its incoming port if the destination MAC of the packet is already learned on that port (i.e., the destination MAC is in FDB on that port). This creates a problem when the switch is connected to a Cisco Ethernet Switch. Because Cisco Ethernet Switch CDP will perform loopback test by sending packets with the same source and destination MAC. dpsw will cause Cisco Switch shutting down the port. There is a workaround suggested by NXP. Write a script that scans the MAC addresses in FDB on each port, and add them to ACL to block them sending back to incoming port. For example, if I need to fix the problem on eth2, use the following script tc qdisc add dev eth2 clsact dest=`bridge fdb show | grep -i eth2 | grep -i self | awk  '{print substr($1,0,17)}'` for dmac in $dest; do tc filter add dev eth2 ingress flower dst_mac $dmac skip_sw action drop done What commands do:  - create a qdisc (see the link I sent you with the ACLs)  - dump the bridge FDB and display all the entries with dest port eth2 that also are of type "self" The result of the dump is passed to awk that will print only the dmacs from the FDB: e.g.: 00:04:9f:05:c3:c8 00:04:9f:05:c3:c9 00:04:9f:05:85:b2 -save the result in dest. -iterate in dest and add ACL filter on ingress for each mac in dest. All the flows that will be received on  eth2  and will have a dmac in the above range will be dropped by the ACL rules created. But this workaround seems kluge.  Here are some issues.  - There is still a small window (between MAC is learned and MAC is placed on ACL), packets still could loopback to incoming port.  - Also when device moves, the MAC in the ACL will not be removed. The moved device may not be reachable now.  - The performance impact with constant scanning, adding to ACL and processing ACL. My question: Are there any better ways to handle this? Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port "Maybe" this below method would work/help? Please check it and provide feedback whether it works or makes sense: -------------------------------------------------------------------------------------------------- Alternate sample method to drop 0x9000 eth-type loopback-detection frames inbound on dpsw ports ---------------------------------------------------------------------------------------------- say if the loopback-detection frames (eth-type 0x9000) packets are coming in through eth5 dpsw-port (and for example if dpmac-18 is linked to this dpsw-port), then running the hardware-offloaded rule would be better option by dropping the generic eth-type 0x9000 frames (irrespective of the mac-addresses) 1. Clean up any temporary/existing configuration tc qdisc del dev eth5 clsact 2>/dev/null tc qdisc add dev eth5 clsact 2. Apply the strict hardware-offload drop rule tc filter add dev eth5 ingress protocol 0x9000 flower skip_sw action drop ---------------------- 3. Status checks: tc -s filter show dev eth5 ingress restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame" OR while :; do restool dpsw info dpsw.0 | grep -A 10 "dpmac.18" | grep "fltr_frame"; sleep 1; done Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port The short answer is that it is very unlikely to provide an implementation for the customer: -hardware does not support source port pruning and the firmware requires significant changes (not even sure if it's feasible) for such a feature as there is no possibility to emulate the  pruning in an autonomous way. Re: DPAA2 Ethernet Switch (dpsw) sends packets back to incoming port Discussing with the AE team.