Armadilloフォーラム

Armadillo-640のUSB電源制御

nawasiro

2024年10月28日 15時02分

VBUSの挙動についてご教授ください。
https://armadillo.atmark-techno.com/blog/10899/4222
を参考に、4.14-at55のカーネルで実施してみました。
このうち上側の挙動が意図したとうりに動かないので、ご教授ください。

GPIOのエクスポート完了後、電源OFFする
echo 0 > /sys/class/gpio/gpio19/value (下)
echo 0 > /sys/class/gpio/gpio113/value (上)
ここまでは問題ありません。
lsusbで見てもUSBデバイスはありません。
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

電源ONする、その1
echo 1 > /sys/class/gpio/gpio113/value
echo 1 > /sys/class/gpio/gpio19/value
この順番で実行した場合は、どちらも電源ONし、USBデバイスは認識します。
Bus 002 Device 005: ID 1eab:2a06
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 1eab:2a06
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

電源ONする、その2
echo 1 > /sys/class/gpio/gpio19/value
echo 1 > /sys/class/gpio/gpio113/value
この順番で実行した場合は、どちらも電源ONするが、上側だけUSBデバイスとして認識しない。
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 1eab:2a06
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
再度、両者ともVBUSの電源OFFしてから、その1の順番で実行させると上側のUSBデバイスも現れてきます。
なお、上側の接続デバイスの種類で変化あるかどうか確認しましたが、いずれも同じ状況です。
試したのは、USBシリアル、HUB、ストレージ(SD)です。

状況から見てみると、gpio19(下)はgpio113(上)が、どのような状況であっても電源ONによって復帰しますが、
gpio113(上)は、gpio19(下)が電源OFF状態の時のみ復帰します。
現状は、gpio113(上側)側で問題があったときに、gpio19(下側)も連動して電源OFFをせざるを得ません。

確認よろしくお願いします。

コメント

溝渕です。

恐らく以下の影響と思われます。

https://www.nxp.jp/docs/en/errata/IMX6ULLCE.pdf
> ERR010661 USB: VBUS leakage occurs if USBOTG1 VBUS is on and USBOTG2 VBUS transitions from on to off

i.MX6ULLのUSB Core電源は、VBUSから供給されます。OTG1とOTG2のどちらからCore電源を供給するかは、anatopの設定により行います。

VBUSの制御をLinuxカーネルで行う限りは、以下のdriverが適切にanatopを設定するので問題ありませんが、
linux-4.14-at/arch/arm/mach-imx/vbus_sel-imx6.c
userlandからVBUSを制御する場合はその限りではありません。

以上より、userlandからanatopの設定を変更する必要があります。

該当レジスタは、
Regulator 3P0 Register (PMU_REG_3P0n)
Address: 20c_8120
で、該当ビットは。
VBUS_SEL(bit 7)
になります。

以下のようなアプリケーションを利用すると、userlandから任意のアドレスにアクセスできるようになります。
https://armadillo.atmark-techno.com/blog/15288/12380
https://github.com/katsuster/memaccess

しかしながら、userlandから本来Linuxカーネルで管理する必要のあるハードウェアリソースを制御する事は、意図しない不具合が発生したり、最悪ハードウェアを故障させる可能性がある為おすすめしません。

可能であれば、VBUSの制御はLinuxカーネル任せた運用をしていただきたいと思います。

> 溝渕です。
>
> 恐らく以下の影響と思われます。
>
> https://www.nxp.jp/docs/en/errata/IMX6ULLCE.pdf
> > ERR010661 USB: VBUS leakage occurs if USBOTG1 VBUS is on and USBOTG2 VBUS transitions from on to off
>
> i.MX6ULLのUSB Core電源は、VBUSから供給されます。OTG1とOTG2のどちらからCore電源を供給するかは、anatopの設定により行います。
>
> VBUSの制御をLinuxカーネルで行う限りは、以下のdriverが適切にanatopを設定するので問題ありませんが、
> linux-4.14-at/arch/arm/mach-imx/vbus_sel-imx6.c
> userlandからVBUSを制御する場合はその限りではありません。
>
> 以上より、userlandからanatopの設定を変更する必要があります。
>
> 該当レジスタは、
> Regulator 3P0 Register (PMU_REG_3P0n)
> Address: 20c_8120
> で、該当ビットは。
> VBUS_SEL(bit 7)
> になります。
>
> 以下のようなアプリケーションを利用すると、userlandから任意のアドレスにアクセスできるようになります。
> https://armadillo.atmark-techno.com/blog/15288/12380
> https://github.com/katsuster/memaccess
>
> しかしながら、userlandから本来Linuxカーネルで管理する必要のあるハードウェアリソースを制御する事は、意図しない不具合が発生したり、最悪ハードウェアを故障させる可能性がある為おすすめしません。
>
> 可能であれば、VBUSの制御はLinuxカーネル任せた運用をしていただきたいと思います。
>
さっそくの細かい情報付の回答ありがとうございます。

ERR010661 確認させていただきました。
また、該当レジスタの説明もありがとうございます。
なお、ご紹介いただいた、ダイレクトにレジスタ変更する事は考えていません。
おっしゃるとおり、リスクは大きいと考えます。

>可能であれば、VBUSの制御はLinuxカーネル任せた運用をしていただきたいと思います。
echoコマンドによるGPIOドライバー経由の操作は、Linuxカーネル任せの範疇に入ると考えていいですか。
それが問題ないのであれば、上記の制限の中で対応していきたいと思います。

よろしくお願いします。

溝渕です。

> echoコマンドによるGPIOドライバー経由の操作は、Linuxカーネル任せの範疇に入ると考えていいですか。

いえ、入りません。

GPIO sysfs経由で操作した場合、そもそもGPIOとしてしか扱われない為、先に示しました
> linux-4.14-at/arch/arm/mach-imx/vbus_sel-imx6.c
の制御が実行されない為です。

ですので、userlandからVBUSの制御を行なわない運用が好ましいのですが、どうしても必要である場合は、USB driverをカスタマイズし、vbus regulator制御部をuserlandに出すのが良いかと思います。

もしくは、すでに試されております通り、userlandでOTG1/OTG2の電源投入順を必ず守るよう実装していただけたらと思います。

> 溝渕です。
>
> > echoコマンドによるGPIOドライバー経由の操作は、Linuxカーネル任せの範疇に入ると考えていいですか。
>
> いえ、入りません。
>
> GPIO sysfs経由で操作した場合、そもそもGPIOとしてしか扱われない為、先に示しました
> > linux-4.14-at/arch/arm/mach-imx/vbus_sel-imx6.c
> の制御が実行されない為です。
>
> ですので、userlandからVBUSの制御を行なわない運用が好ましいのですが、どうしても必要である場合は、USB driverをカスタマイズし、vbus regulator制御部をuserlandに出すのが良いかと思います。
>
> もしくは、すでに試されております通り、userlandでOTG1/OTG2の電源投入順を必ず守るよう実装していただけたらと思います。
>

> いえ、入りません。
たしかに、関連する記述ありませんね。ご指摘ありがとうございます。

>もしくは、すでに試されております通り、userlandでOTG1/OTG2の電源投入順を必ず守るよう実装していただけたらと思います。
はい、とりあえずこちらで実施します。
色々と、ありがとうございました。