サポートチームの皆様へ、
当社では、IMX9332Cを搭載したカスタム基板を設計しています。
私たちはU-Bootをブートローダーとして使わず、代わりにBareboxを選んだため、残念ながらuboot-imxで既に行われた作業の恩恵を受けることができません。私たちのブートチェーンは以下の通りです:TF-A → Barebox → Linux。
バージョン: imx-atf lf-6.18.20-2.0.0、ベアボックス 2025.09.0(カスタムボードポート)、Linux 6.18.13。
リアルタイム制約機能にはCortex-M33の補助コアを使いたいと考えています。アイデアは、SDKでベアメタルコードをコンパイルし、Linuxのremoteprocフレームワークを通じて得られたバイナリを読み込むことです。
私は入出力デバイスを点滅させる非常にシンプルなC言語プログラムを作成し、コンパイルしました。remoteprocを使って読み込むと、フレームワークは読み込まれたと報告するのですが、実際には何も起こりません。停止しようとすると必ずクラッシュします。
最初はコアの設定が正しくなかったのではないかと思い、NXPのFRDMリファレンスボードでU-bootがM33をどう準備しているかを調べました。M33コアは「準備」する必要があることがわかりました。つまり、RAMをゼロにし、ウォッチドッグを設定し、TCMをセットアップするなどです。これらの操作の一部をBareboxの低レベル初期化コードに移植しましたが、remoteprocでコードをロードすると、すぐにリセットされてしまいます。
この時点で、リセットの根本原因を突き止めるためにSRSRレジスタを確認したところ、M33_REQビットが設定されていました。
ドキュメントを見ると、これはCortex-M33自体からリセットが要請されたことを意味します。
なぜこのリセットリクエストが出るのか、今のところ全く分かりません。自分のコードのどこにもトリガーされていません。
私の質問は以下のとおりです。
M33の「準備」に関する完全な要件に関するドキュメントはありますか?
CM33_REQUESTリセットの可能な原因は何でしょうか?これはどこから来たのでしょうか?
ありがとう。
こんにちは、 @jlablancheさん
image.pngimage.png