Armadilloフォーラム

ソフトウェアウォッチドックタイマ発動後による再起動を確認する方法

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

2019年12月4日 11時00分

溝渕です。

> 今検討している機能として、再起動の要因を以下のように判断したいと考えております。
>
> ①プログラムによる再起動
> ②ウォッチドックタイマーによる再起動

デフォルトソフトウェアでは、再起動後に②を判断することはできません。

Hermit-Atをカスタマイズすること判断可能にできそうです。

R-Mobile A1 データシートの、
RCLK Watchdog Timer Control/Status Register A (RWTCSRA)
の"WOVF(Bit 4)"は、ウォッチドッグタイマーによる再起動が生じたかどうか
を示しています。このビットはウォッチドッグタイマーによる再起動後も保持
されます。

at_mizo

2019年12月4日 11時30分

溝渕です。

すみません。ミスリードしていました。

私が書いたのは、ハードウェアウォッチドッグタイマーについてです。

ソフトウェアウォッチドッグタイマーについては、RCLK Watchdog Timerのレ
ジスタによる判別が不可能です。

ソフトウェアウォッチドッグタイマーによるリセット時には、以下のコードを
通ります。

arch/arm/mach-shmobile/board-armadillo810.c:
static void a810_restart(char str, const char *cmd)

ここに何かしらの仕掛けをすると、判別可能にできるかもしれません。

junya.yasuda

2019年12月5日 14時29分

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)
> 

>
> ここに何かしらの仕掛けをすると、判別可能にできるかもしれません。
>