junya.yasuda
2019年12月3日 20時56分
いつもお世話になっております。
Armadillo810 にてソフトウェアウォッチドッグの使用を試みております
以下を参考にLinuxカーネルのコンフィギュレーションを変更し、
/dev/watchdogへのアクセスでタイムアウトによるリブートが発生することまでは確認できました。
https://users.atmark-techno.com/blog/53/1319
http://lists.atmark-techno.com/pipermail/armadillo/2013-November/009308…
今検討している機能として、再起動の要因を以下のように判断したいと考えております。
①プログラムによる再起動
②ウォッチドックタイマーによる再起動
①については、作成するプログラムにて判断できるため（不揮発領域に印を残しておく等）、問題ないのですが、
②についてはどう判断すべきか分かりません。
自前で
①以外の場合は、②と判断するといった方法以外に、何か方法があればご教授頂けると幸いです。（再起動後、あるファイルを見ればわかる等）
＃armadilloのアーキテクチャーを想定すると、再起動後は、もろもろ揮発してしまうため、記録として残っていないと想定はしています・・・）
コメント
at_mizo
溝渕です。
すみません。ミスリードしていました。
私が書いたのは、ハードウェアウォッチドッグタイマーについてです。
ソフトウェアウォッチドッグタイマーについては、RCLK Watchdog Timerのレ
ジスタによる判別が不可能です。
ソフトウェアウォッチドッグタイマーによるリセット時には、以下のコードを
通ります。
arch/arm/mach-shmobile/board-armadillo810.c: static void a810_restart(char str, const char *cmd)
ここに何かしらの仕掛けをすると、判別可能にできるかもしれません。
junya.yasuda
yasudaです。
ご回答ありがとうございます。
下記の件、勉強になります。
頂いた情報をもとに、色々と検証させていただきます。
誠にありがとうございました。
> ソフトウェアウォッチドッグタイマーによるリセット時には、以下のコードを
> 通ります。
>
>
> arch/arm/mach-shmobile/board-armadillo810.c: > static void a810_restart(char str, const char *cmd) >
>
> ここに何かしらの仕掛けをすると、判別可能にできるかもしれません。
> 溝渕です。
>
> すみません。ミスリードしていました。
>
> 私が書いたのは、ハードウェアウォッチドッグタイマーについてです。
>
> ソフトウェアウォッチドッグタイマーについては、RCLK Watchdog Timerのレ
> ジスタによる判別が不可能です。
>
> ソフトウェアウォッチドッグタイマーによるリセット時には、以下のコードを
> 通ります。
>
>
> arch/arm/mach-shmobile/board-armadillo810.c: > static void a810_restart(char str, const char *cmd) >
>
> ここに何かしらの仕掛けをすると、判別可能にできるかもしれません。
>
at_mizo
2019年12月4日 11時00分
溝渕です。
> 今検討している機能として、再起動の要因を以下のように判断したいと考えております。
>
> ①プログラムによる再起動
> ②ウォッチドックタイマーによる再起動
デフォルトソフトウェアでは、再起動後に②を判断することはできません。
Hermit-Atをカスタマイズすること判断可能にできそうです。
R-Mobile A1 データシートの、
RCLK Watchdog Timer Control/Status Register A (RWTCSRA)
の"WOVF(Bit 4)"は、ウォッチドッグタイマーによる再起動が生じたかどうか
を示しています。このビットはウォッチドッグタイマーによる再起動後も保持
されます。