デバッガのバグという可能性は、最後まで疑いたくない物です。やりたいのはデバッガのデバッグではないので。
これまでの検証作業で、一つ気づいたことがありました。ベアメタル・アプリケーションが使用しているLDファイルは、32kBある命令メモリのうち、実際には下位16kBしか使っていません。と言うことは、ツールチェーンのリリース時に、小さなプログラムでしか試験をしていない可能性があります。そうすると、次のような事が考えられるわけです。
- 実はADSP-BF592の命令メモリ上位16kBはキャッシュに構成されており、デバッガから書き込み不能である。
- GDB ServerがADSP-BF592の命令メモリ上位16kBに書き込めない。
上の1は十中八九無視してかまいません。Blackfinは共通スペックとしてリセット後にすべてのキャッシュがディセーブルになっています。BF592のマニュアルをさらってみましたが、キャッシュがイネーブルであるという記述がありません。そもそも、BF592は外部メモリを持つことができませんので、キャッシュには意味がありません。
とすると、2です。ツールチェーンのデフォルトのLDスクリプトは、命令メモリの上位16kBをキャッシュと仮定するため、メモリにオブジェクトを配置できません。この制限のため、bfin-gdbproxyに見えないバグが潜んでいる可能性はあります。
試しに、sample1をスリムダウンしてみました。sample1のアプリケーション・タスクのループ内を削り、JSPカーネル内部のポストモーテム・ダンプをリンクから外すと、.textセクションのサイズが16kBを切ります。セクションサイズは以下のコマンドで確認します。
$ bfin-elf-readelf –S jsp
さて、これをbfin-elf-gdbでACB-BF592にロードしたところ、見事にstart:以下にプログラムが現れました。ということは、
bfin-gdbproxyにはバグがあり、命令メモリの上位16kB領域にプログラムをロードしようとすると、全体のロードに失敗する
と言う可能性を否めなくなってきました。
引き続き調べてみますが、Blackfin Koopに投げた方が早い気がしてきました。
類似の問題が報告されていた
Analog DevicesのフォーラムであるEngineerZoneに、 BF592 debug code > 16kBという、そのもののタイトルで同様の問題が報告されています。ただ、報告者は.text + .dataのサイズを問題視しており、R2011では解決積みとしています。私の手元ではR2011でも解決していません。.text + .dataというのは、報告者の勘違いでしょう。
解決しました
問題解決しました。ツールチェーン2011Rでは動作します。詳細はこちら。