2020年12月さすがに寒い日が続きます、Advent Calendarを続けています。
何の因果か1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。
今日は、Linux Gadget driverについて。
linux-cdc-acm の前に、Linux Gadget driver ってみなさん利用されていますか?
![]()
Raspberry Pi Zeroが登場した辺りから、Linux Gadget driver の知名度がぐんと上がった気がしているのですが、Linux Gadget driver 機能をメインに使っている製品以外では、製品で利用しているケースってどれぐらいあるのですかね?
あっ、未来ガジェット研究所の話ではないです。(そんなのはいいですね。
今回はじめて Linux Gadget driver を利用してみたのですが、思った以上に便利ですね。
OpenWrt でも普通にモジュールとして定義されていたのは驚きでしたが。
ハード的には、USBポートを外部に露出させておけば良いというのは本当に最高ですよ。
まぁ、USBホストとゲストに同時にはなれないという説明を何度もしないといけない羽目になりましたがw
で、Linux Gadget driver 便利だなぁと思っていたので、開発作業で利用しようとは思っていたのですよ。
旧世代機BOCCOでは、みんな気軽にテストパターンにケーブルを半田付けしてしまう傾向があるのですが、問題が起きた際に、ハードを触ってしまっている事による影響が0にはならないというのがあまり意識されないという開発傾向をみていると、なんとしてでもハードは弄らずにソフト開発作業をさせる方法を確立しておかなくてはという執念めいた衝動に駆られまして。
半分冗談、半分本当の事なのですが、emoでもやはりすぐシリアルケーブル生やす傾向は抜けませんでしたね。。。
まぁ、ハードを弄らなくても作業できる様になった事自体は、ハードを触らないエンジニアを開発チームに取り入れるハードルをさげる事には役立ったかとは考えています。
ほんと年々ハード触らない人増えてますね。(ハードの会社だったとしても
Linux Gadget driverなのですが、様々な種類ありますよね。
OpenWrt 19.07だと、以下6種類が利用できる様になっていますね。
シリアル、ネットワークインタフェース、オーディオ、ストレージ、HID、カメラ、プリンター、MIDI、なんか沢山ありすぎて、コンフィグの仕方がわかりません。
この沢山ある中から、g_ether、g_serial、g_cdc 辺りは、比較的扱いやすいものの様に思えます。
それ以外は、configfs で設定しないといけない項目が難解です。
また、configfs の内容が kernel バージョンによって異なったりで、解りやすい資料がなかなか見つからない。。。
もぅ、コードを読んだ方が早いのかと思ってしまいます。
オーディオは少し気になってるのですがね、emoがUSBオーディオ化できるのも愉しいかもしれないと。
Audio Class 1.0、Audio Class 2.0、も対応している様にも見えるので夢が広がります。
そのうち遊びたいですね。
BOCCO emoでは、この種類があるなかから、g_ether と g_cdc を開発作業に利用しました。
正確には、主に g_ether になりますが
g_cdc をメインで使えなかった理由には3つあります。
1つ目の理由は、g_cdc の Ethernet側のドライバが、Windowsには無いことです。(これはどうにも手が出せません
ソフトウェア開発作業では、Linuxコンソール操作とファイル転送がどうしてもさせたかったので、Ethernet側が使えないのは困ります。
ちなみに、g_cdc のシリアル側のドライバなのですが、Windows10 だと少し面倒で、署名付きで該当するのがなかなか見つからないのですよね。
私は、昔$8コンピュータとかいって登場したシングルボードコンピュータの「C.H.I.P.」で配布されていたドライバを利用しています。
「C.H.I.P.」自体、会社が解散してしまってサイトも消えているのですが、幸いにも Internet Archive に残っています。
https://archive.org/details/chip-flashing-mode-driver
2つ目の理由は、シリアルコンソールを有効にOpenWrtで出来ない。
はじめは、CONFIG_VT_HW_CONSOLE_BINDING 辺りの話かと思ったのですがね、まったく違う話だったのですよ。
正確にいうと、initタイミングで Linux Gadget driver が読み込まれている場合は、コンソールが有効に出来るのだが、後から Linux Gadget driver を読み込むと、ttyを起動するタイミングを失ってしまいます。
inittab 再読み込みの為に、シグナルを送ればいいじゃないかと思われるかもしれませんが、OpenWrtではシグナルを送っても、inittab 再読み込みは走ってくれないのです。
答えは、openwrt-develのメーリングリストのアーカイブに眠ってました。
Re: [OpenWrt-Devel] Q: procd: re-evaluation of inittab entries
Busybox initを弄るのは少しリスキーですね。
というか、詳細情報がもっと欲しいです。使えそうな資料といえばコレぐらいですかね。
https://openwrt.org/docs/techref/process.boot
結局、コードを読んでいって、対応させる事はできるけど、マスターのコードに追従しつつ維持するのは、大変だと言う事で、シリアルコンソールを有効にするのは諦めました。
3つ目の理由は、g_cdc の Ethernet 側なんか不安定じゃない?
薄々気がついてはいたのですが、g_cdc の Ethernet 側、内部での usb0 がなんか不安定な気がしています。
原因追えてないですが、なんか、シリアル側は安定してるのに、Ethernet側を使うと不安定なきがしています。
g_ether が使いやすい。
RNDISとして認識してくれるので、Windows、macOS、Linux、ソフトウェア開発者が使ってる端末でとりあえず困らなさそう。
最近は、macOS使ってるなら、自分でなんとかしてくれるやろという過信は禁物です。
意外とLinuxユーザの方がなんとかしてくれます。(そこじゃない?
ちょっと面倒なのは、Windows10ユーザぐらいですかね?
Windows10だと何故かシリアルとしてはじめ認識するんですよね。。。ドライバ更新すればちゃんとEthernet認識するのですが。。。
あと、g_cdc より安定している気がする。
Linux Gadget driver、configfsで設定を作っていかないといけないもので無ければ、本当に手軽に使えるのでお勧めです。
まぁ、本当にやりたいものって、configfs触らないとできないのですが。。。
年末休み使って、Audio Gadget は動かしてみたいですね。(時間取れるのか解りませんが。。。
今日は予定変更した事で、出せていなかったネタについて記載しました。Advent Calendar 2020、18日目でした。
次は パーツ変更 について書きたいと思います。
ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。これぞシュタインズ・ゲートの選択!!
19日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...
何の因果か1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。
今日は、Linux Gadget driverについて。
linux-cdc-acm の前に、Linux Gadget driver ってみなさん利用されていますか?

Raspberry Pi Zeroが登場した辺りから、Linux Gadget driver の知名度がぐんと上がった気がしているのですが、Linux Gadget driver 機能をメインに使っている製品以外では、製品で利用しているケースってどれぐらいあるのですかね?
あっ、未来ガジェット研究所の話ではないです。(そんなのはいいですね。
今回はじめて Linux Gadget driver を利用してみたのですが、思った以上に便利ですね。
OpenWrt でも普通にモジュールとして定義されていたのは驚きでしたが。
ハード的には、USBポートを外部に露出させておけば良いというのは本当に最高ですよ。
まぁ、USBホストとゲストに同時にはなれないという説明を何度もしないといけない羽目になりましたがw
で、Linux Gadget driver 便利だなぁと思っていたので、開発作業で利用しようとは思っていたのですよ。
旧世代機BOCCOでは、みんな気軽にテストパターンにケーブルを半田付けしてしまう傾向があるのですが、問題が起きた際に、ハードを触ってしまっている事による影響が0にはならないというのがあまり意識されないという開発傾向をみていると、なんとしてでもハードは弄らずにソフト開発作業をさせる方法を確立しておかなくてはという執念めいた衝動に駆られまして。
半分冗談、半分本当の事なのですが、emoでもやはりすぐシリアルケーブル生やす傾向は抜けませんでしたね。。。
まぁ、ハードを弄らなくても作業できる様になった事自体は、ハードを触らないエンジニアを開発チームに取り入れるハードルをさげる事には役立ったかとは考えています。
ほんと年々ハード触らない人増えてますね。(ハードの会社だったとしても
Linux Gadget driverなのですが、様々な種類ありますよね。
OpenWrt 19.07だと、以下6種類が利用できる様になっていますね。
- kmod-usb-gadget-cdc-composite.USB CDC Composite (Ethernet + ACM)
- kmod-usb-gadget-ehci-debug. USB EHCI debug port Gadget support
- kmod-usb-gadget-eth. USB Ethernet Gadget support
- kmod-usb-gadget-hid. USB HID Gadget Support
- kmod-usb-gadget-mass-storage. USB Mass Storage support
- kmod-usb-gadget-serial. USB Serial Gadget support
シリアル、ネットワークインタフェース、オーディオ、ストレージ、HID、カメラ、プリンター、MIDI、なんか沢山ありすぎて、コンフィグの仕方がわかりません。
この沢山ある中から、g_ether、g_serial、g_cdc 辺りは、比較的扱いやすいものの様に思えます。
それ以外は、configfs で設定しないといけない項目が難解です。
また、configfs の内容が kernel バージョンによって異なったりで、解りやすい資料がなかなか見つからない。。。
もぅ、コードを読んだ方が早いのかと思ってしまいます。
オーディオは少し気になってるのですがね、emoがUSBオーディオ化できるのも愉しいかもしれないと。
Audio Class 1.0、Audio Class 2.0、も対応している様にも見えるので夢が広がります。
そのうち遊びたいですね。
BOCCO emoでは、この種類があるなかから、g_ether と g_cdc を開発作業に利用しました。
正確には、主に g_ether になりますが
g_cdc をメインで使えなかった理由には3つあります。
1つ目の理由は、g_cdc の Ethernet側のドライバが、Windowsには無いことです。(これはどうにも手が出せません
ソフトウェア開発作業では、Linuxコンソール操作とファイル転送がどうしてもさせたかったので、Ethernet側が使えないのは困ります。
ちなみに、g_cdc のシリアル側のドライバなのですが、Windows10 だと少し面倒で、署名付きで該当するのがなかなか見つからないのですよね。
私は、昔$8コンピュータとかいって登場したシングルボードコンピュータの「C.H.I.P.」で配布されていたドライバを利用しています。
「C.H.I.P.」自体、会社が解散してしまってサイトも消えているのですが、幸いにも Internet Archive に残っています。
https://archive.org/details/chip-flashing-mode-driver
2つ目の理由は、シリアルコンソールを有効にOpenWrtで出来ない。
はじめは、CONFIG_VT_HW_CONSOLE_BINDING 辺りの話かと思ったのですがね、まったく違う話だったのですよ。
正確にいうと、initタイミングで Linux Gadget driver が読み込まれている場合は、コンソールが有効に出来るのだが、後から Linux Gadget driver を読み込むと、ttyを起動するタイミングを失ってしまいます。
inittab 再読み込みの為に、シグナルを送ればいいじゃないかと思われるかもしれませんが、OpenWrtではシグナルを送っても、inittab 再読み込みは走ってくれないのです。
答えは、openwrt-develのメーリングリストのアーカイブに眠ってました。
Re: [OpenWrt-Devel] Q: procd: re-evaluation of inittab entries
Busybox initを弄るのは少しリスキーですね。
というか、詳細情報がもっと欲しいです。使えそうな資料といえばコレぐらいですかね。
https://openwrt.org/docs/techref/process.boot
結局、コードを読んでいって、対応させる事はできるけど、マスターのコードに追従しつつ維持するのは、大変だと言う事で、シリアルコンソールを有効にするのは諦めました。
3つ目の理由は、g_cdc の Ethernet 側なんか不安定じゃない?
薄々気がついてはいたのですが、g_cdc の Ethernet 側、内部での usb0 がなんか不安定な気がしています。
原因追えてないですが、なんか、シリアル側は安定してるのに、Ethernet側を使うと不安定なきがしています。
g_ether が使いやすい。
RNDISとして認識してくれるので、Windows、macOS、Linux、ソフトウェア開発者が使ってる端末でとりあえず困らなさそう。
最近は、macOS使ってるなら、自分でなんとかしてくれるやろという過信は禁物です。
意外とLinuxユーザの方がなんとかしてくれます。(そこじゃない?
ちょっと面倒なのは、Windows10ユーザぐらいですかね?
Windows10だと何故かシリアルとしてはじめ認識するんですよね。。。ドライバ更新すればちゃんとEthernet認識するのですが。。。
あと、g_cdc より安定している気がする。
Linux Gadget driver、configfsで設定を作っていかないといけないもので無ければ、本当に手軽に使えるのでお勧めです。
まぁ、本当にやりたいものって、configfs触らないとできないのですが。。。
年末休み使って、Audio Gadget は動かしてみたいですね。(時間取れるのか解りませんが。。。
今日は予定変更した事で、出せていなかったネタについて記載しました。Advent Calendar 2020、18日目でした。
次は パーツ変更 について書きたいと思います。
ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。これぞシュタインズ・ゲートの選択!!
19日目の記事も早速書かないとですね。がんばります。
でわ、また明日 ...