(toppers-users 2296) Re: 時間計測とsyslog
ykominami
ykominami @ nifty.com
2006年 2月 4日 (土) 13:53:50 JST
小南です.
On Fri, 3 Feb 2006 23:51:49 +0900
Tetsuo TAKAHASHI <tetsu-t @ mbd.ocn.ne.jp> wrote:
> 高橋です。
>
> On 2006/02/03, at 10:12, ykominami wrote:
> > 小南です.
>
> > メインタスク起動時に、CCRの値がstart.Sで設定したは
> > ずの値になって
> > いないというのは、CCRの操作に失敗している確率が高いです.
> > CCRを正しい方法で設定しないと、以後のCPUの挙動が不安定に
> > なる可能性
> > が高くなります.
> はい。それについても疑っていて、ハードそのものも故障しているので
> は?と
> 考えています。
> ただ、全部疑っていても先に進めないので、とりあえずソフト面から
> 疑って
> います。
> > 実はTOPPERS/JSPのSH3/4ターゲット依存部の
> > start.Sでのキャッシュ
> > コントローラの設定方法は、start.Sに来た時点でキャッシュ
> > が無効に
> > なっていることが前提になっています。
> > そのため、もしブートローダ等でキャッシュを有効にした状態で
> > start.S
> > にくると、CCRを正しい設定方法で設定しないことになり、
> > CPUの動作が
> > 不安定になりやすいです。
> しかし、config/sh3/start.Sの下記の部分は、
> _start:
> /*
> * キャッシュの初期化
> */
> mov.l _ccr_addr,r1
> mov.l _ccr_disable,r2
> mov.l r2, @ r1
> mov.l _ccr_mode,r2
> mov.l r2, @ r1
> 一旦無効化して、その後CCR_MODEで定義しているモードに設定し
> ている
> のではないでしょうか?
> この無効化は、小南さんのおっしゃっている上記の「無効」とは違う
> 物ですか?
SH3/SH4ターゲット依存部のユーザーズマニュアル(doc/sh3.txt)
の「3.4 メモリマップ」では以下のように記述されています.
・Solution Engine
コード領域を 0x0c003000 〜 0x0c0fffff 約1MB,データ領域を 0x0c100000
〜 の約3MB,非タスクコンテキスト用のスタック領域を 〜0x0c3fffff に確
保している.0x0c000000 〜 0x0c000fff は,GDBスタブのワークエリアとなっ
ており,使用することができない.
この領域はキャッシュ可能な領域です。
ところが、例えば「SH7727ハードウェアマニュアル 5.2.1 キャッシュ制御レジスタ
(CCR)」の説明にはこう書いてあります.
「CCRの内容を変更するプログラムは、キャッシングしないアドレス空間に配置して
ください」
もしstart.Sに来たときにキャッシュが有効になっていると,start.Sで一旦
キャッシュを無効にする操作そのものが、ハードウェアマニュアルに書かれた制約に
反することになります。
しかし、キャッシュが無効になっていれば、どのアドレス空間もキャッシングしてい
ないので制約に反しないことになります。
これを回避するには、
1.start.Sが呼ばれる前に、キャッシュを有効にしない.
2.キャッシュを有効にする事自体が回避できなければ,start.Sを呼び出す前に、
正しい方法でキャッシュを無効にする.
3.start.SでCCRを操作しない。(コメントアウトする等)
4.start.SでCCRを操作するときは、キャッシングしないアドレス空間にとんで
からする、サブルーチンコールする。
(アドレス空間の異なるエリアから、同一の物理メモリを参照するようになっています)
などが考えられます.
ハードの故障以外にも、こういう可能性が考えられると重います。
------------------------------------------------------------------
小南 ykominami @ nifty.com