GENMAIボードでのブートについて２

Hiro さん

> ご回答ありがとうございます。以下にご質問の回答をします。
初心者フォーラムとは思えない適切な回答、有難うございます。非常に助かります。
余談ですが、よろしければ、初心者フォーラムを卒業してＲＺフォーラム（あるいは、英語版の
RZ Forum）へどうぞ。 最近、少し寂しいもので(笑)

＞ ＞(1) シリアルフラッシュを書き換えた後、一旦、GENMAI の電源を落とし、再投入する。
＞
＞ シリアルフラッシュ書込み後、GENMAI電源OFF。ICEの出力画面に"ターゲット電源OFF"表示
＞ GENMAI電源ON。ICEの出力画面に"ターゲット電源ON"表示
＞
＞ ＞(2) 0x18000000 番地にハードウェアブレークポイント（ソフトウェアブレークポイントは
＞
＞ 不可）を設定し、ブートモード３で実行する。
＞ ハードウェアブレークはICEに拒否されたので、OCD（On Chip Debug）ブレークを使用しました。
＞ ブレーク時のレジスタは以下の通りです。
＞ PC:0x18000000、LR:0x00000000、CPSR:0x600001d3、SPSR:0x5b0d7f31

ここまでは、特に問題ありません。

RZ/A1 内蔵ROM のファームウェアが SPIBSC チャネル０の初期化に成功した後、
シリアルフラッシュの先頭（0x18000000 番地）から書き込まれている u-boot に
ジャンプしようとしてブレークがかかったものです。

＞ ＞(5) 十秒ほど実行し、暴走しているようなら、強制ブレークして、その時のレジスタの値を
＞ ＞確認する。
＞
＞ (4)→(5)まで実行した結果のレジスタは以下の通りです。
＞ PC:0x18000004、LR:0x18000008、CPSR:0x600001db、SPSR:0x600001db
＞ GENMAIボードを2枚用意して2枚ともですので、故障ではないと思っております。


この結果で見る限り、その後、シリアルフラッシュの先頭（0x18000000 番地）から
書き込まれている u-boot を実行しようとして、あるいは、実行中に、
未定義命令例外を多重に起こして無限ループに入り込んでしまっているようです。

CP15 の設定前に不動小数点演算命令や除算命令を実行した場合にも、この例外が
発生しますが、今回のケースでは考えにくく、
何らかの原因で、シリアルフラッシュが正しく読めない、あるいは、読めなくなる、
と考えた方が良さそうです。

こちらで試した限り、再現しない（特に問題無く u-boot が立ち上がる）ので、
申し訳ありませんが、次のことを試してみていただけますか？

先のメールの手順の (1)～(3) は、そのままで、
(4) 0x18000000 でブレークしたら、その後、0x18000000 番地からメモリダンプして
シリアルフラッシュが正常に読めることを確認する。
(5) 次に 0x18000004 にハードウェアブレークポイントを設定し、(0x18000000 から)
継続実行する。
(6) 0x18000004 でブレークしたら、その時のレジスタ(PC, LR, CPSR, SPSR) を
確認する。
(7) (6) の LR のアドレスの前後１０命令程度を逆アセンブルする。

もし、(6) でブレークしなかったら、(1)～(3) は、そのままで、
(4) 0x18000000 でブレークしたら、次に 0x18000004 にハードウェアブレーク
ポイントを設定し、(0x18000000 から) 継続実行する。
(5) 0x18000004 でブレークしたら、その時のレジスタ(PC, LR, CPSR, SPSR) を
確認する。
(7) (5) の LR のアドレスの前後１０命令程度を逆アセンブルする。

をしてみてください。

pecteilisさん。
＞こちらで試した限り、再現しない（特に問題無く u-boot が立ち上がる）ので、
　そちらでは問題ないとのことですの、こちらのボードの設定をお伝えしておきます。
　「r20ut2596jj_r7s72100evum.pdf」で示されているJP、SWで初期値以外は以下の通りです。
　JP5=1-2、JP8=1-2、SW1-1:1-3:1-4=OFF

　JP5とSW1-4は初期値でも実施しましたが、動作に変わりはありません。

以上

Hiroです。
最初の掲示で

＞シリアル通信によるPC画面上での確認では、一切動いてない状態です（メッセージが一切出力されません）。

としたように、シリアル通信によるPC画面上にメッセージが出力されない＝起動しない、で考えていました。
もしかしたら、シリアル通信が出来ていないだけかと思ってもいましたので、ブートのポート設定時にP4_10と
P4_11を出力ポートの設定に変更してみました。
結果、LEDが点灯しましたので、ブートプログラムの少なくともレジスタ設定は走っているようです。
この情報から何か探れることは有りますでしょうか。

以上

Hiro さん

丁度、良いタイミングでした。上の

> ブートのポート設定時にP4_10とP4_11を出力ポートの設定に変更してみました。

は、include/configs/rskrza1.h の中で定義している値を変更したのだと思います。

それは、変更したままで、更に、board/renesas/rskrza1/lowlevel_init.S の赤字の
部分(ポート4の設定部分)を青字の部分(ポート9の設定部分) の後ろに移動したブート
プログラムで、同じことをしてみていただけますか？　♯ 最初の数字は、行番号です。

点灯しないことが私の期待なのですが。

100 write16 PM3, PM3_S
101 write16 PIBC3, PIBC3_S
102
103 /* Port4 Control register Reset */
104 write16 PIBC4, PIBC4_D
105 write16 PBDC4, PBDC4_D
106 write16 PM4, PM4_D
107 write16 PMC4, PMC4_D
108 write16 PIPC4, PIPC4_D
109
110 /* Port4 Control register Set */
111 write16 PBDC4, PBDC4_S
112 write16 PFC4, PFC4_S
113 write16 PFCE4, PFCE4_S
114 write16 PFCAE4, PFCAE4_S
115 write16 PIPC4, PIPC4_S
116 write16 PMC4, PMC4_S
117 write16 P4, P4_S
118 write16 PM4, PM4_S
119 write16 PIBC4, PIBC4_S
120
121 /* Port5 Control register Reset */
122 write16 PIBC5, PIBC5_D
123 write16 PBDC5, PBDC5_D

（途中、略）

190 write16 PM8, PM8_S
191 write16 PIBC8, PIBC8_S
192
193 /* Port9 Control register Reset */
194 write16 PIBC9, PIBC9_D
195 write16 PBDC9, PBDC9_D
196 write16 PM9, PM9_D
197 write16 PMC9, PMC9_D
198 write16 PIPC9, PIPC9_D
199
200 /* Port9 Control register Set */
201 write16 PBDC9, PBDC9_S
202 write16 PFC9, PFC9_S
203 write16 PFCE9, PFCE9_S
204 write16 PFCAE9, PFCAE9_S
205 write16 PIPC9, PIPC9_S
206 write16 PMC9, PMC9_S
207 write16 P9, P9_S
208 write16 PM9, PM9_S
209 write16 PIBC9, PIBC9_S
210
211 /* Port10 Control register Reset */
212 write16 PIBC10, PIBC10_D
213 write16 PBDC10, PBDC10_D

Hiroです。
>> ブートのポート設定時にP4_10とP4_11を出力ポートの設定に変更してみました。
>は、include/configs/rskrza1.h の中で定義している値を変更したのだと思います。
PM4_S：0xffff→0xf3ff　としました。

ご指示の通り、Port4の設定をPort9の設定の後に移動させたところ、期待されたとおりにLEDは点灯しませんでした。が、PC画面上には何も表示されません。
この後の対応をお聞かせください。

以上

Hiroさん

＞ ご指示の通り、Port4の設定をPort9の設定の後に移動させたところ、
＞ 期待されたとおりにLEDは点灯しませんでした。が、PC画面上には何も
＞ 表示されません。

ＰＣ画面上に何も表示されない(言い換えれば、ポート４の設定箇所の前で
暴走するので、ポート４の設定箇所以降は、実行されない)ことを含めて、
期待通りです。

Hiro さんに幾つかの実験をお願いし、結果を戴きましたが、現時点では、
未だ、辻褄が合わない結果があります。予め、ご承知ください。

----
今回の問題は、u-boot の不具合で、
u-boot がシリアルフラッシュから命令などを読み出しながら実行している
最中に、シリアルフラッシュとの接続に使用している端子(ポート９の端子)
の設定を変更(初期化)しているために、命令などが正しく読み出せず、
誤動作を起こしていると考えています。
つまり、先のメールの青色部分に問題があります。

ただ、私の所で不再現であったり、Hiroさんの所で NOR フラッシュの
u-boot を一回実行すると不再現になったりするように、暴走するか否かは、
ボードの個体差やその時の状態にも依存するようです。

で、対策ですが、最小限の変更で済ませるには、青色部分の処理を、
・ ブートモード０で起動した場合には、現状と同じ処理を、
・ ブートモード３で起動した場合には、次の４本の兼用端子の設定は
変えずに、残りの端子は、現状と同じ処理を、
それぞれ行うように、include/configs/rskrza1.h の中で定義している、
ポート９関連の値を調整してください。
・ P9_2/SPBCLK_0
・ P9_3/SPBSSL_0
・ P9_4/SPBIO00_0
・ P9_5/SPBIO10_0

注意する点は、ブートモード３で起動した場合、RZ/A1 内蔵 ROM の F/W が
上記の４端子を設定して、シリアルフラッシュからの読み出しが可能な状態
にし、0x18000000 番地から始まる u-boot にジャンプするわけですから、
上で言っている「次の４本の兼用端子の設定は変えずに」の「設定」とは、
リセット直後の設定ではなく、0x18000000 番地到達時点の設定であるという
ことです。

具体的には、

355 #define PM8_S 0xffff
356 #define PIBC8_S 0x0000
357
358 /* Port9 Control register Reset */
359 #if !defined(CONFIG_BOOT_MODE0)
360 #define PIBC9_D 0x0000
361 #define PBDC9_D 0x0000
362 #define PM9_D 0xff03 ★
363 #define PMC9_D 0x003c
364 #define PIPC9_D 0x003c
365 #else
366 #define PIBC9_D 0x0000
367 #define PBDC9_D 0x0000
368 #define PM9_D 0xffff
369 #define PMC9_D 0x0003

の★の所の値を 0xff03 から 0xffff に変更すれば良さそうですが、確認は
していません。

Hiroです。
ご指示の通り、
#define PM9_D 0xff03　⇒　0xffff
にしたところ、シリアルフラッシュからの起動が出来ました。
Pecteilisさんのおっしゃる通り、NORフラッシュ起動後には起動できる理由が説明付きませんが、
何とか動いたので、このまま進めたいと思います。
本題とは異なりますが、本掲示の中で1点気になったことが有りますので質問させてください。

ボードの設定についてご報告させていただいたとき、
＞また、SW1-4の設定では、カーネルが管理する時間が、計算上４％程度、遅れます。
とのご説明が有りましたが、4%の遅れを踏襲する技は有るのでしょうか。
設定の方法などが有りましたら、ご教示願います。

以上

わわいさん。
Hiroです。

わわいさんのおっしゃる通り、ブートプログラムに問題が有ったようです。提供されているBSPだったことと、
発生する場合の状況から、問題ないように思っていました。
色々なご助言ありがとうございました。
本件は、これで完了とします。

以上

Hiro さん

＞ #define PM9_D 0xff03　⇒　0xffff
＞ にしたところ、シリアルフラッシュからの起動が出来ました。

良かったです。
ソースを見る限り、この部分を作成した人も、シリアルフラッシュからの読み出しに
使用している４本の兼用端子の設定は変えてはいけない（誤動作の危険がある）、と
いうことを認識して値を定義しているようですが、偶々、上の１箇所を間違え、その後、
その人の環境では、特に問題なく動作してしたため間違いに気付かなかったのでしょう。

＞ ＞また、SW1-4の設定では、カーネルが管理する時間が、計算上４％程度、遅れます。
＞ とのご説明が有りましたが、4%の遅れを踏襲する技は有るのでしょうか。
＞ 設定の方法などが有りましたら、ご教示願います。

誤変換？(踏襲?吸収?) で、ご質問が良く解りませんが、時間を正しくしたいなら、
以前に申し上げた通り、

| ジャンパ等の設定は、BSPに含まれていたリリース通知の「4-1.DIPSW,ジャンパの設定」に
| 従って、行ってください。

リリース通知に従った設定は、SW1-4=ON です。

時間が遅れるのは、Hiro さんが SW1-4=OFF と異なる設定にして、RZ/A1 の入力クロックを
切り替えているためです。

Hiroです。
「踏襲」日本語的に間違っていました。分かりづらくすみません。
SW1-4を変更することで、4%程度の遅れが発生することが分かっているのであれば、その遅れを無くすようなレジスタの設定方法が有るのではないかと思いました。
ただ、「カーネルが管理する時間」と有りましたので、マイコン制御で差異を無くすことは難しいのでしょうかね。
クロックをUSB_X1としたシステムを構築した場合の弊害や対応を知っておきたいので、何か手段をご存知でしたら、お教えください。

以上

Hiro さん

＞ SW1-4を変更することで、4%程度の遅れが発生することが分かっているのであれば、
＞ その遅れを無くすようなレジスタの設定方法が有るのではないかと思いました。

お察しの通り可能です。
但し、このソフトが対応している設定や環境ではありませんので、自助努力、自己責任で
お願いします。

補足しておきます。お気づきだと思いますが、理解しやすいので時間を取り上げましたが、
入力クロックを切り替える（入力クロックの周波数が変わる）と、それから生成される
クロックを入力している RZ/A1 の内蔵周辺デバイス全般の動作に影響を与えます。

周辺デバイスにより、影響の有無は様々です。別クロックを入力している周辺デバイスの
場合は、影響が無いかもしれません。あるいは、周波数分、動作速度が変わるだけかも
しれません。例えば、UART、I2C、SPI など、外部デバイスと通信を行うものは、通信用の
クロック周波数（と実際の周波数）との誤差が大きくなりますから、何らかの影響がある
かもしれません。

いずれにせよ、ご使用になる周辺デバイスについて、影響の有無を調べ、影響する部分は
見直す必要があります。

Hiroです。
クロック同期の通信に関しては影響は少ないと思っていますが、UARTへの影響は考慮しないといけないと思います。クロックを変更する場合は、影響箇所を検討することにします。
長い間、対応してくださりありがとうございました。
本件は完了とさせていただきます。
以上

Hiroです。
クロック同期の通信に関しては影響は少ないと思っていますが、UARTへの影響は考慮しないといけないと思います。クロックを変更する場合は、影響箇所を検討することにします。
長い間、対応してくださりありがとうございました。
本件は完了とさせていただきます。
以上