(toppers-users 2135) Re: SH-3(SH7727)での100MHz超の

[ykominami]

おはようございます。
小南です。

On Mon, 19 Sep 2005 19:39:11 +0900
toshiaki.mizutani ＠ brother.co.jp wrote:

> みなさま、こんばんわ。
 
> 小南さん、ご回答ありがとうございます。
 
> 今一度、ＢＳＣ辺りの設定を再確認してみます。
 
> 重ねて基本的な質問をさせていただきます。
 
> > なぜならJSPのSH3/SH4のターゲット依存部のスタートアップモジュールを見る
> > 限り、キャッシュオフの状態で呼ばれることを前提にしていると考えられるか
> > らです。
 
> 上記のことは、JSPのソースのどの部分辺りに該当するのでしょうか。
> スタートアップでキャッシュをONにしている箇所以外で、
> スタートアップ/カーネルにおいてキャッシュ制御をしているソースを
> 見つけられませんでした。
config/sh3/start.Sのラベル_start以降から、kernel_start()を呼び出すまで
です。
TOPPERSプロジェクトの公式リリースでは、1.3、1.4、1.4.1のどれでも、
まずキャッシュOFFしてから、あらためてキャッシュONにしています。
公式リリースでは、カーネルはP0領域、またはP1領域にロードすることがほとん
どです。
例外は1.3のKZ_SH4ボードでPARTNER_Jで動かす場合で、P2領域に直接ロードして
いたようです。

> > 問題となる現象は、キャッシュオンの状態でカーネルを呼び出した後に
> > 発生するのでしょうか。
 
> 具体的に書かせていただきます。
> ブート時（start.srcの先頭）にキャッシュを有効に設定しています。
> 例えば、
>   while(1) dly_tsk(xxxx);
> というコードを、startup.cのkernel_start()の最後尾の

>   /* カーネル動作の開始 */
>   exit_and_dispatch();
> の直前に加えると問題なく動きます（何事も無く無限ループします）。
> しかし、このコードを、サンプルソースsample1.cのmain_task()の
> 先頭に加えると、CPU例外が発生してしまいます。

> 「前者は偶然動いているだけではないか」という気もしますが
> もっと複雑で意味のあるコードを書いても同じ結果になります。
私がキャッシュONの状態でカーネルのエントリールーチン(config/sh3/
start.Sの_start)を呼んだ時は、kernel_start()内のexit_and_dispatch()
の直前までは到達していることは確認しました。
ただしICEとかは持っていないため、LEDを点灯するルーチンを追加して
LEDのどの部分が光っているかで判断しました。
この場合でも、起動メッセージの文字列が途中で途切れましたが、どこで
途切れるかも、実行させるたびに変わりました。
私の場合は、exit_and_dispatch()内で暴走してどこかにいってしまてい
ました。そしてどこにいったかまでは追跡できませんでした。

キャッシュONの状態で_startを呼んでいるのは、ローダとして用いたT-Monitor
がキャッシュONにしていたからです。

SH3はパワーオンリセット時にはキャッシュOFFですので、ICEとかローダとか
GDBスタブとかがキャッシュコントローラを初期化していなければ、start.S
でキャッシュOFF->キャッシュONになります。
JSPはこの状態を想定しているということです。

しかし私の場合、ローダがキャッシュONした後、JSPカーネルがP1領域のコード
でキャッシュOFF->キャッシュONにしていたため、CPUが不安定になっていました。

それから、御承知の上で実行されているのかも知れませんが、kernel_start()
内では非タスクコンテキストですので、
>   while(1) dly_tsk(xxxx);
はdly_tsk()の頭の方にあるマクロCHECK_DISPATCH()内でラベルexit:に
goto文でジャンプしているはずです。
ですから見掛けよりは、ずっと短く単純なパスを通っていると思います。
#タスクコンテキストで呼ばれた場合、dispatch()をコールしますので
#割込み処理と並ぶJSPカーネルの中で最も複雑で重要な心臓部分を通る
#ことになります。

> ターゲット依存な質問になってしまったような気がします。
> メーリングリストの趣旨から離れているようでしたら、すみません。
メーリングリストの趣旨から離れているとは思っていません。
ただし独自に移植された場合、公式リリースのものと比べて、どこをどのよう
に変更したかとか、動作条件はどこが違うのかとか、開発環境の違いがどのよう
に影響しているかといったことが、移植者以外のML参加メンバには不明だったり、
経験がなかったり、確認する手段がないなどの理由で、レスポンス自体が少なく
ても不思議でないというぐらいでしょう。

--------------------------
小南 ykominami ＠ nifty.com