hito
2018年8月9日 19時28分
お世話になっております。
以下、ご教授願います。
起動中のArmadilloに対して「echo mem > /sys/power/state」を実行しSuspend-to-RAM状態にし、
UART2(メインユニットCON4)にデータ受信させて起床させようとしています。
しかし、root権限にて「echo mem > /sys/power/state」を実行して試していたところ、
起床動作が安定していないように思いました。
実際には以下のような動作が起きました。
１．Suspend-to-RAM状態遷移5秒後にデータ受信させたらすぐ起床（Linuxのbootを行わない）するときもあれば、
Linuxのbootから起動する時もある。
２．ある時はSuspend-to-RAM状態30分以内ぐらいにデータ受信させればすぐ起床していてたが、
Suspend-to-RAM状態1時間程経過後にデータ受信させたらLinuxのbootから起動したときもある。
３．一度、Power-On Suspend状態からの起床後、Suspend-to-RAM状態から起床させると、
Linuxのbootを伴わず即時起動した。
※「１」と「２」に関しては「３」も関係しているかもしれません。
本来このような動作にならない想定でしょうか？
マニュアルを見ると、
Power-On Suspend standby Suspend-to-RAMよりも短時間で復帰することができる。
Suspend-to-RAM mem Power-On Suspendよりも消費電力を抑えることができる。
とありますので、当方の想定では、
Power-On Suspend ：Linuxのbootを伴わない（即時起動が可能）
Suspend-to-RAM ：Linuxのbootを伴う
と思っているのですが、認識はあっていますでしょうか？
また、Power-On Suspend状態から起床する際、経過時間によりLinuxのbootを伴うこともあるのでしょうか？
煩雑なご質問で申し訳ありませんが、ご回答お願いいたします。
コメント
hito
2018年8月10日 19時34分
お世話になっております。
ご連絡有難うございます。
ソフトウェアバージョンですが、uname -aで表示したものを転記いたします。
・Linux armadillo 3.14.79-at21 #2 SMP PREEMPT Tue Feb 27 09:49:09 JST 2018 armv7l GNU/Linux
その他使用しているもののバージョンは、
・armadillo_iotg_g3l-v21.00.dtb
・debian-jessie-armhf_aiotg3l_20180501.tar.gz
・u-boot-x1-sd-at15.bin
・uImage-x1-v21.00
になります。
基本的な確認動作の流れは以下になります。
１．起動時にサスペンド機能を有効にする。
（rc.localに「echo enabled > /sys/bus/platform/drivers/imx-uart/30890000.serial/tty/ttymxc1/power/wakeup」を追加）
２．atmarkログイン後「su root」を行う。
３．「echo mem > /sys/power/state」を実行しサスペンド状態に移行。
４．数秒、数分経過後、シリアルによるデータ入力で起床。
本日色々と試しておりましたところ、現象が起きる場合と起きない場合でログが取れました。
[添付資料]
・Armadilloサスペンドテスト(OK)_180810.log
・Armadilloサスペンドテスト(NG)_180810.log
OKの場合ですと、「echo standby > /sys/power/state」と「echo mem > /sys/power/state」ともに
Linuxのbootは発生しませんでした。
NGの場合ですと、「echo standby > /sys/power/state」と「echo mem > /sys/power/state」ともに
Linuxのbootが発生しました。
色々と試していて気づいたのですが、コマンド実行後、シリアルからデータ入力する前に
「Enter」を入力しているとLinuxのbootが動くようでした。
（コマンドラインは全てシリアルポート(CON5)を使用して検証しています）
[OKパターン]
「echo standby > /sys/power/state」入力
↓
「数秒経過」
↓
「シリアルデータ入力」
↓
「起床」
[NGパターン]
「echo standby > /sys/power/state」入力
↓
「Enter」入力
↓
「数秒経過」
↓
「シリアルデータ入力」
↓
「Linux boot起動」
本来想定する運用ではこのようなことはしないため大丈夫だとは思いますが、
原因がわかれば教えていただけないでしょうか？
申し訳ありませんが、よろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| Armadilloサスペンドテスト(OK)_180810.log | |
| Armadilloサスペンドテスト(NG)_180810.log |
at_mizo
2018年8月21日 17時13分
溝渕です。
> 原因がわかれば教えていただけないでしょうか？
恐らく以下が原因です。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm…
linux-3.14に適用可能なパッチを用意したので、試してみてください。
| ファイル | ファイルの説明 |
|---|---|
| linux-3.14-x1-at21-fix_uart_suspend.patch | |
| linux-3.14-x1-at21-fix_uart_suspend.patch |
hito
2018年8月23日 20時56分
To．溝渕様
パッチのご提供有難うございます。
原因についても承知いたしました。
取り急ぎのご連絡なのですが、
頂いたパッチを当てて確認してみたのですが、サスペンド状態からの復旧が出来なくなりました。
linux-3.14-x1-at21.tar.gzのソフトにパッチを当て、initramfs_x1-v1.1.0.cpio.gzを使用してビルドをしました。
出来たuImageとarmadillo_iotg_g3l.dtbを置き換えて使用しました。
G3Lのマニュアルを見ながら行ったのですが、そもそも手順が間違っていましたでしょうか？
今一度試してみますが、ひとまずご連絡をと思い連絡いたしました。
（もし私のミスでしたら申し訳ございません）
以上、よろしくお願いいたします。
at_mizo
2018年8月10日 9時06分
溝渕です。
ご利用のソフトウェアバージョンをご教授ください。また、問題を再現させる
ために必要なコマンドと、コマンドの実行ログもあれば確認を行いやすいです。
> 実際には以下のような動作が起きました。
>
> １．Suspend-to-RAM状態遷移5秒後にデータ受信させたらすぐ起床（Linuxのbootを行わない）するときもあれば、
> Linuxのbootから起動する時もある。
> ２．ある時はSuspend-to-RAM状態30分以内ぐらいにデータ受信させればすぐ起床していてたが、
> Suspend-to-RAM状態1時間程経過後にデータ受信させたらLinuxのbootから起動したときもある。
> ３．一度、Power-On Suspend状態からの起床後、Suspend-to-RAM状態から起床させると、
> Linuxのbootを伴わず即時起動した。
>
> ※「１」と「２」に関しては「３」も関係しているかもしれません。
>
> 本来このような動作にならない想定でしょうか？
ならない想定です。
suspendからの復帰は、Linuxのbootを伴わず、resume処理を行った後の即時復
帰となる想定です。
> マニュアルを見ると、
> Power-On Suspend standby Suspend-to-RAMよりも短時間で復帰することができる。
> Suspend-to-RAM mem Power-On Suspendよりも消費電力を抑えることができる。
> とありますので、当方の想定では、
> Power-On Suspend ：Linuxのbootを伴わない（即時起動が可能）
> Suspend-to-RAM ：Linuxのbootを伴う
> と思っているのですが、認識はあっていますでしょうか？
違います。
> また、Power-On Suspend状態から起床する際、経過時間によりLinuxのbootを伴うこともあるのでしょうか？
無いと認識しています。