(toppers-users 2296) Re: 時間計測とsyslog

[ykominami]

小南です．

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