私は自分の開発に at91sam9260 を使用しています。その中で実行されている Linux カーネルがあり、その上で独自のソフトウェアを起動します。
JTAG デバッガーを使用して、Linux カーネルで何が起こっているかをほとんど確認せずに、現在取り組んでいるソフトウェアをデバッグできるかどうか疑問に思っていました。
Linux の完全な実行を見ながらソフトウェアをデバッグするのは非常に複雑になるかもしれないと思うので、私はそれを求めています。
言い換えれば、JTAG プローブを使用してデバッグするときに抽象化レイヤーが存在する可能性があるかどうかを知りたいですか?
おそらくそうではありません-私が知る限り、ほとんどのJTAGデバッガーは、プロセッサーにブレークポイントを設定する機能を想定しています。マルチタスクOSでは、OSカーネルも停止します。
QNXのような組み込みOSには、OSカーネル上で動作し、イーサネットを介して通信するデバッガがあります。
一般的には、デバッガーはそのプロセッサーで実行しているソフトウェアとはまったく関係がないため、jtagを使用できます。問題が発生する可能性があるのはキャッシュです。たとえば、プロセッサを停止してRAM内の一部の命令を変更して再起動した場合、RAM内の命令の変更はデータアクセスであり、命令キャッシュではなくデータを通過します。キャッシュ、個別の命令とデータキャッシュがある場合、それらは有効になっており、変更した命令の一部は命令キャッシュにあるアドレスにあります。新しい古い命令がプロセッサに供給されると、かなり速く混乱する可能性があります。 。Linuxは、キャッシュがある場合はそれを使用するのが好きです。
2番目はmmuです。プロセッサ/jtagは、物理アドレスではなく、mmuのプロセッサ側の仮想アドレスで動作している可能性があります。したがって、ハードウェアの動作に応じて、たとえば、でデバッグユニットのアドレスごとにブレークポイントを設定した場合プロセッサとオペレーティングシステムのタスクが同じアドレス空間にある別のプログラム/スレッドに切り替わると、正しいアドレスにある間違ったプログラムにブレークポイントが設定されます。デバッガー/プロセッサーがRAM内の命令を変更してブレークポイントを設定すると、上記のキャッシュの問題が発生します。キャッシュされていない場合は、適切なスレッドで適切な命令を中断しますが、キャッシュの問題が発生します。
要するに、プロセッサがjtagベースのデバッグをサポートしている場合、そのプロセッサで実行することを選択したソフトウェアに基づいて変更されることはありません。
JTAG デバイスとそのドライバーに依存します。個人的には、それが可能なデバイスを 1 つだけ知っています: XDS560 + Code composer studio (CCS)。しかし、他にもあり得ます。
お使いのデバイスの製造元に相談することをお勧めします。
ARM の場合、Asset Arium ファミリはアプリケーション コードをデバッグできると主張されています。でも、試したことはありません。