Armadilloフォーラム

省電力モードから復帰しない

vector

2023年8月16日 16時51分

お世話になっております。
armadillo-610 で、Suspend-to-RAM状態から、UART1で復帰させようとしているのですが、復帰しません。
過去のフォーラム「省電力モードからの復帰動作が安定しない」を見ましたが 復帰できている方もおられる様です。
root権限にて「echo mem > /sys/power/state」 を実行後、UART1にデータ受信させても、復帰しません。

何か情報ございましたら、お願いします。

カーネルのバージョンは、以下になります。
Linux version 4.14-at27 (atmark@atde7) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #11 Mon Apr 18 19:03:17 JST 2022

UART1のサスペンド機能は以下の様に有効になっております。
root@armadillo:~# cat /sys/class/tty/ttymxc0/power/wakeup
enabled

以下Suspend-to-Idleでは、普通に復帰します。
echo freeze > /sys/power/state

以下Power-On Suspendでは、復帰しますが、UARTデータの欠けが発生します。(1Byteデータ送信後の待ちが足りないと思っています。)
echo standby > /sys/power/state

以下Suspend-to-RAMでは、復帰しません。
echo mem > /sys/power/state

カーネルソース4.14-at27では、以下が対応済みなのを確認しております。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm…

よろしくお願いいたします。

コメント

at_akihito.irie

2023年8月17日 10時01分

入江です。

> armadillo-610 で、Suspend-to-RAM状態から、UART1で復帰させようとしているのですが、復帰しません。

原因究明のため、現在Armadillo-610で使用しているdtbファイルを送っていただけますでしょうか。

具体的には、U-bootの環境変数を何も操作していないのであれば、

[armadillo]# mount /dev/mmcblk0p2 /mnt
[armadillo]# ls /mnt/a610.dtb
/mnt/a610.dtb

a610.dtbを送っていただけますでしょうか。

以上、よろしくお願いいたします。

vector

2023年8月17日 13時50分

すません。
mmcblk0p2は、別用途に使用しております。
/boot/a610.dtbを添付します。

ファイル ファイルの説明
a610.dtb

at_akihito.irie

2023年8月17日 14時21分

入江です。

dtbを確認させていただきました。ありがとうございます。

このdtbを作成するためにat-dtwebを使用されたと思いますが、
ご使用のat-dtwebのバージョンが古い可能性があります。

可能であれば最新のat-dtwebをご使用いただき、改めてdtbを作成しなおして、
そのdtbを使用してSuspend-to-RAM からの復帰をお試しいただけますでしょうか?

at-dtweb のアップデートにつきましては、ATDEにて以下を実行してください。

[ATDE]$ sudo apt update
[ATDE]$ sudo apt upgrade -y

vector

2023年8月17日 15時04分

ありがとうございます。
前任の担当者に確認してみます。

vector

2023年8月17日 16時32分

お世話になっております。

追加で1件 確認させてください。

echo standby > /sys/power/state を実行後、 UART1で起床はするのですが、
先頭1Byte欠けます。

具体的には、対向のマイコンから、0x24 送信後、10msec 待って 0x52 0x51 0x31 を送信するのですが、先頭の0x24が受信できません。

10msec待つ部分の時間を延ばせば、受信できるものなのか、それとも、起床イベントに使用されたデータは受信できないものなのかが知りたいです。

よろしくお願いします。

at_akihito.irie

2023年8月18日 18時56分

入江です。

> echo standby > /sys/power/state を実行後、 UART1で起床はするのですが、
> 先頭1Byte欠けます。

これはArmadillo-610のSoCであるi.MX 6ULLの仕様による現象の可能性が高い
です。

i.MX 6ULLにおいて、サスペンドなどからUARTで起床させる場合の起床タイミ
ングは、スタートビットの立ち下がりエッジです(ハードウェアフロー制御を
行わない場合)。

スタートビットを受信して起床後、SoCはUARTが内部で使用するクロックを生
成して供給し始めます。
しかし、クロックがUARTに供給される前にシリアルから受信したデータは捨て
られてしまいます。

すなわち、スタートビット受信〜先頭データ受信までの間に、UARTにクロック
が供給されていなければならないのですが、クロックの供給が間に合っていな
いのだと思います。

上記内容は、『i.MX 6ULL Applications Processor Reference Manual』の、
「55.4.2.3 Clocking in Low-Power Modes」に記載があります。
(私が所持しているpdfファイルはRev. 1, 11/2017のものなので、バージョン
によっては章番号など異なる場合があります)

対応策としましては、ハードウェアフロー制御を有効化し、RTS割り込みで起
床することが挙げられます。
この場合はスタートビットの前にクロックがUARTに供給されるので、データが
失われることはありません。
(これについても「55.4.2.3 Clocking in Low-Power Modes」に記載があります)
ただし、対向機との間のシリアル通信にハードウェアフロー制御が必須になり
ます。

もしくは、先頭データは必ず捨てられてしまうものとして運用することも手段
の一つかもしれません。

以上、よろしくお願いいたします。

vector

2023年8月21日 15時36分

> 対応策としましては、ハードウェアフロー制御を有効化し、RTS割り込みで起
> 床することが挙げられます。
> この場合はスタートビットの前にクロックがUARTに供給されるので、データが
> 失われることはありません。
> (これについても「55.4.2.3 Clocking in Low-Power Modes」に記載があります)
> ただし、対向機との間のシリアル通信にハードウェアフロー制御が必須になり
> ます。
ありがとうございます。
HWフローの線はつながっていませんので、別の方法を検討いたします。

> もしくは、先頭データは必ず捨てられてしまうものとして運用することも手段
> の一つかもしれません。
こちらの方法を検討いたします。

ありがとうございました。

■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

省電力から、起き上がらない件、ツールを新しくして、確認しました。
結果、memで、起床する様になりました。
ありがとうございます。

で、dtbをdtsにして、比較を行いましたが、最新版のat-dtweb の出力で、気になるところがありました。

以下のexpansion_interfacehoggrpのところですが、昔作成したものは、0x400010b0となっており、最新のat-dtwebを使用した場合、0x10b0となっています。
正しいのかどうか気になりました。
確認していただけないでしょうか。
気にしなくてもよい箇所であれば無視しときます。

			iomuxc@20e0000 {
				compatible = "fsl,imx6ul-iomuxc";
				reg = <0x20e0000 0x4000>;
				pinctrl-names = "default";
				pinctrl-0 = <0x16>;
				linux,phandle = <0xa>;
				phandle = <0xa>;
 
				~省略~
 
				expansion_interfacehoggrp {
					fsl,pins = <0x90 0x31c 0x0 0x5 0x0 0x400010b0 0x1d4 0x460 0x0 0x5 0x0 0x400010b0 0x6c 0x2f8 0x0 0x5 0x0 0x400010b0 0x60 0x2ec 0x0 0x5 0x0 0x400010b0 0x118 0x3a4 0x0 0x5 0x0 0x400010b0 0x11c 0x3a8 0x0 0x5 0x0 0x400010b0 0x120 0x3ac 0x0 0x5 0x0 0x400010b0 0x124 0x3b0 0x0 0x5 0x0 0x400010b0 0x128 0x3b4 0x0 0x5 0x0 0x400010b0 0x12c 0x3b8 0x0 0x5 0x0 0x400010b0 0x130 0x3bc 0x0 0x5 0x0 0x400010b0 0x134 0x3c0 0x0 0x5 0x0 0x400010b0 0x138 0x3c4 0x0 0x5 0x0 0x400010b0 0x13c 0x3c8 0x0 0x5 0x0 0x400010b0 0x140 0x3cc 0x0 0x5 0x0 0x400010b0 0x144 0x3d0 0x0 0x5 0x0 0x400010b0 0x148 0x3d4 0x0 0x5 0x0 0x400010b0 0x14c 0x3d8 0x0 0x5 0x0 0x400010b0 0x150 0x3dc 0x0 0x5 0x0 0x400010b0 0x154 0x3e0 0x0 0x5 0x0 0x400010b0 0x158 0x3e4 0x0 0x5 0x0 0x400010b0 0x15c 0x3e8 0x0 0x5 0x0 0x400010b0 0x104 0x390 0x0 0x5 0x0 0x400010b0 0x10c 0x398 0x0 0x5 0x0 0x400010b0 0x110 0x39c 0x0 0x5 0x0 0x400010b0 0x108 0x394 0x0 0x5 0x0 0x400010b0 0x1b8 0x444 0x0 0x5 0x0 0x400010b0 0x44 0x2d0 0x0 0x5 0x0 0x10b0 0x1dc 0x468 0x0 0x5 0x0 0x400010b0 0x1e0 0x46c 0x0 0x5 0x0 0x400010b0 0x1ec 0x478 0x0 0x5 0x0 0x400010b0 0x1e8 0x474 0x0 0x5 0x0 0x400010b0 0x1f0 0x47c 0x0 0x5 0x0 0x400010b0 0x1e4 0x470 0x0 0x5 0x0 0x400010b0 0x1d8 0x464 0x0 0x5 0x0 0x400010b0 0x19c 0x428 0x0 0x5 0x0 0x400010b0 0x198 0x424 0x0 0x5 0x0 0x400010b0 0x194 0x420 0x0 0x5 0x0 0x400010b0 0x190 0x41c 0x0 0x5 0x0 0x400010b0 0x174 0x400 0x0 0x5 0x0 0x400010b0 0x170 0x3fc 0x0 0x5 0x0 0x400010b0 0x16c 0x3f8 0x0 0x5 0x0 0x400010b0 0x168 0x3f4 0x0 0x5 0x0 0x400010b0 0x164 0x3f0 0x0 0x5 0x0 0x400010b0 0x160 0x3ec 0x0 0x5 0x0 0x400010b0 0x70 0x2fc 0x0 0x5 0x0 0x400010b0 0xbc 0x348 0x0 0x5 0x0 0x400010b0 0x84 0x310 0x0 0x5 0x0 0x400010b0 0xc0 0x34c 0x0 0x5 0x0 0x400010b0 0x88 0x314 0x0 0x5 0x0 0x400010b0 0xa0 0x32c 0x0 0x5 0x0 0x400010b0 0x9c 0x328 0x0 0x5 0x0 0x400010b0 0x5c 0x2e8 0x0 0x5 0x0 0x400010b0 0xac 0x338 0x0 0x5 0x0 0x400010b0 0xb0 0x33c 0x0 0x5 0x0 0x400010b0>;
					linux,phandle = <0x16>;
					phandle = <0x16>;
				};
 
				~省略~
 
				reg80grp {
					fsl,pins = <0x7c 0x308 0x0 0x5 0x0 0x8>;
					linux,phandle = <0x28>;
					phandle = <0x28>;
				};
			};
			iomuxc@20e0000 {
				compatible = "fsl,imx6ul-iomuxc";
				reg = <0x20e0000 0x4000>;
				pinctrl-names = "default";
				pinctrl-0 = <0x16>;
				linux,phandle = <0xa>;
				phandle = <0xa>;
 
 
				~省略~
 
				expansion_interfacehoggrp {
					fsl,pins = <0x90 0x31c 0x0 0x5 0x0 0x400010b0 0x1d4 0x460 0x0 0x5 0x0 0x400010b0 0x6c 0x2f8 0x0 0x5 0x0 0x400010b0 0x60 0x2ec 0x0 0x5 0x0 0x400010b0 0x118 0x3a4 0x0 0x5 0x0 0x400010b0 0x11c 0x3a8 0x0 0x5 0x0 0x400010b0 0x120 0x3ac 0x0 0x5 0x0 0x400010b0 0x124 0x3b0 0x0 0x5 0x0 0x400010b0 0x128 0x3b4 0x0 0x5 0x0 0x400010b0 0x12c 0x3b8 0x0 0x5 0x0 0x400010b0 0x130 0x3bc 0x0 0x5 0x0 0x400010b0 0x134 0x3c0 0x0 0x5 0x0 0x400010b0 0x138 0x3c4 0x0 0x5 0x0 0x400010b0 0x13c 0x3c8 0x0 0x5 0x0 0x400010b0 0x140 0x3cc 0x0 0x5 0x0 0x400010b0 0x144 0x3d0 0x0 0x5 0x0 0x400010b0 0x148 0x3d4 0x0 0x5 0x0 0x400010b0 0x14c 0x3d8 0x0 0x5 0x0 0x400010b0 0x150 0x3dc 0x0 0x5 0x0 0x400010b0 0x154 0x3e0 0x0 0x5 0x0 0x400010b0 0x158 0x3e4 0x0 0x5 0x0 0x400010b0 0x15c 0x3e8 0x0 0x5 0x0 0x400010b0 0x104 0x390 0x0 0x5 0x0 0x400010b0 0x10c 0x398 0x0 0x5 0x0 0x400010b0 0x110 0x39c 0x0 0x5 0x0 0x400010b0 0x108 0x394 0x0 0x5 0x0 0x400010b0 0x1b8 0x444 0x0 0x5 0x0 0x400010b0 0x44 0x2d0 0x0 0x5 0x0 0x400010b0 0x1dc 0x468 0x0 0x5 0x0 0x400010b0 0x1e0 0x46c 0x0 0x5 0x0 0x400010b0 0x1ec 0x478 0x0 0x5 0x0 0x400010b0 0x1e8 0x474 0x0 0x5 0x0 0x400010b0 0x1f0 0x47c 0x0 0x5 0x0 0x400010b0 0x1e4 0x470 0x0 0x5 0x0 0x400010b0 0x1d8 0x464 0x0 0x5 0x0 0x400010b0 0x19c 0x428 0x0 0x5 0x0 0x400010b0 0x198 0x424 0x0 0x5 0x0 0x400010b0 0x194 0x420 0x0 0x5 0x0 0x400010b0 0x190 0x41c 0x0 0x5 0x0 0x400010b0 0x174 0x400 0x0 0x5 0x0 0x400010b0 0x170 0x3fc 0x0 0x5 0x0 0x400010b0 0x16c 0x3f8 0x0 0x5 0x0 0x400010b0 0x168 0x3f4 0x0 0x5 0x0 0x400010b0 0x164 0x3f0 0x0 0x5 0x0 0x400010b0 0x160 0x3ec 0x0 0x5 0x0 0x400010b0 0x70 0x2fc 0x0 0x5 0x0 0x400010b0 0xbc 0x348 0x0 0x5 0x0 0x400010b0 0x84 0x310 0x0 0x5 0x0 0x400010b0 0xc0 0x34c 0x0 0x5 0x0 0x400010b0 0x88 0x314 0x0 0x5 0x0 0x400010b0 0xa0 0x32c 0x0 0x5 0x0 0x400010b0 0x9c 0x328 0x0 0x5 0x0 0x400010b0 0x5c 0x2e8 0x0 0x5 0x0 0x400010b0 0xac 0x338 0x0 0x5 0x0 0x400010b0 0xb0 0x33c 0x0 0x5 0x0 0x400010b0>;
					linux,phandle = <0x16>;
					phandle = <0x16>;
				};
 
				~省略~
 
				reg80grp {
					fsl,pins = <0x7c 0x308 0x0 0x5 0x0 0x8>;
					linux,phandle = <0x29>;
					phandle = <0x29>;
				};
			};

vector

2023年8月21日 18時55分

追加で質問させてください。

こちらで、使用しています、at-dtweb は2.4.0でした。
で、最新版を取得したところ、at-dtwebは、2.9.1でした。
この間の修正履歴は、見れるものでしょうか。

UARTでデータ化けの疑いがあり、確認したいです。

at_akihito.irie

2023年8月21日 19時55分

入江です。

> 以下のexpansion_interfacehoggrpのところですが、昔作成したものは、0x400010b0となっており、最新のat-dtwebを使用した場合、0x10b0となっています。

まさしくこの箇所が、Suspend-to-RAMからUART起因で起床するための修正です。
具体的には、MX6UL_PAD_JTAG_MOD__GPIO1_IO10のPAD設定を0x400010b0から
0x10b0に変更しています。
これにより、当該ピンのSIONという機能を無効化しています。
SIONについては『i.MX 6ULL Applications Processor Reference Manual』の
「SW Loopback through SION bit」を参照してください。

基本的にこの修正による他の動作への影響はありませんのでご安心ください。

> この間の修正履歴は、見れるものでしょうか。

Git のコミットログのような修正履歴は公開していません。

「製品アップデートのお知らせ」内で、アップデート内容の概要を説明してい
ますので、そちらを参照してください。
(以下は、製品カテゴリ「Armadillo-610」、キーワード「at-dtweb」で検索し
たページです)
https://armadillo.atmark-techno.com/news/software-updates?field_taxonom…

詳細な変更点を知りたい場合は、以下からat-dtwebのバージョン毎のソースコー
ドをダウンロードできます(at-dtweb_[VERSION].tar.xz)。
https://download.atmark-techno.com/debian/pool/main/a/at-dtweb/

こちらから当該の2つのバージョンをダウンロードしていただき、tarコマンド
などで展開した上でdiffを取るという方法もあります。