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…
よろしくお願いいたします。
コメント
vector
at_akihito.irie
入江です。
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
vector
at_akihito.irie
入江です。
> 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
> 対応策としましては、ハードウェアフロー制御を有効化し、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
at_akihito.irie
入江です。
> 以下の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を取るという方法もあります。
at_akihito.irie
2023年8月17日 10時01分
入江です。
> armadillo-610 で、Suspend-to-RAM状態から、UART1で復帰させようとしているのですが、復帰しません。
原因究明のため、現在Armadillo-610で使用しているdtbファイルを送っていただけますでしょうか。
具体的には、U-bootの環境変数を何も操作していないのであれば、
の
a610.dtb
を送っていただけますでしょうか。以上、よろしくお願いいたします。