linux設定の続き(u-dma-bufとuio以外)

GPIO周りの設定

前回の設定がちゃんと行われていれば，おそらくですがuioとu-dma-bufはlinux上で認識されるようにはなっていると思います．
一方で，デバイスツリーが刷新された影響か，beagleV-fireにデフォルトで焼かれていたUbuntuとはLinuxから見えるGPIOの様子が異なっていました．というかfabric側のGPIOがほとんど正しく見えていない…もう一歩進んではまた壁が出てくるのホントにやめてくれ…

今回のは1週間以上全く進展がない状態でした．というのもちょっと起きている現象が2つ以上同時に発生していそうです．

簡潔に言うと，GPIOデバイスの「一部」が見えていない状況です．

今回のビットストリームの構成とデバイスツリーの構成だと，想定している状態としてはgpiochipが0~5の計6つ見えるはずでしたが，実際には見えているのは3つだけでした．

内訳としては

@20120000 : MSSのGPIO① ⇦ 見えている
@20121000 : MSSのGPIO② ⇦ 見えている
@20122000 : MSSのGPIO？ ⇦ 見えない
(※なぜかたまにこれはfabricのGPIOと書かれているのだけどよくわからない．多分MSS側．)
@41100000 : fabric GPIO (cape P8) ⇦ 見えない
@41200000 : fabric GPIO (cape P9) ⇦ 見えない
@44000000 : fabric GPIO (hsio) ⇦ 見えている

という感じです．基本的にはfabric GPIOが全部見えていないように見せかけて一個だけ@44000000のHSIOだけLinux側から見えているという状況です．

ただし，@44000000のHSIOも様子がおかしく，デバイスツリーから当該GPIOの記述を削除してビルドしなおしたlinuxでも認識されているし，デバイスツリーを記述している場合でも，そのデバイスツリーに記載したはずのpin名が登録されていません．(※MSSのGPIOは同じデバイスツリーで登録したpin名が見えている．)

こうやって整理するとどっからどう見てもfabric GPIOの認識が正常になされていなさそうです．

一旦ここではなぜ@44000000だけ認識されて見えるのか，ただしpin名は反映されないのかは置いておきます．多分ですがここに書きこんでも実際のGPIOは変化しないんじゃないかなあと予想はしているのですが…

めんどくさいというクソみたいな理由で12/23現在，オシロで確認するみたいなことはしていないです．

—————–年末年始を挟み—————–

結局，年明けまでちまちま検討した結果，microchip公式のYoctoでOSをビルドするのは諦め，beagleboard社の

BeagleV-Fire / BeagleV-Fire-ubuntu · GitLab

Git repositories for BeagleBoard.org projects

を使用しました．まずは一旦これをそのまま利用してビルドしたOSと，これまたbeagleboard社が用意しているgatewareのデフォルトを作成して

BeagleV-Fire / Gateware · GitLab

Git repositories for BeagleBoard.org projects

これらの組み合わせで確認すると，当然と言えば当然ですがGPIOが全部(gpiochip0~6)見えるようになりました．

再びu-dma-bufとuioへ

上述の通り，beagleboard社謹製のdebianビルド環境一式から作成したdebianでGPIOがちゃんと見えるのが確認できたので，そこからu-dma-bufやuioの設定をmenuconfigでモジュールに変更して再ビルドしました．

入っててほしいものが！全部！入ってる！！
とりあえずinsmodでちゃんと入るかの確認のためだけに一回ビルドした奴なので，今度こそデバイスツリーを本命に入れ替えて同じことができるか再確認する．
それが終わったら… pic.twitter.com/9PxLj5C7z4
— どらび (@DRB_lab) January 10, 2025

というわけで欲しいものが全部入っている状態のカスタムOSができた(はず)です．

副産物

beagleboard社作のDebianを使ったことによって，Yoctoで1から作る場合と比べて2倍近くのイメージサイズになってしまいました…

(Yoctoだと最小構成(core-image-minimal-dev)で300MBくらい，開発ツール等込み(mpfs-dev-cli)でも1.2GBに対してDebianだと2.4GB)

ちょっと残念ですが，その代わりに

M.2への対応(これはどちらかというとOS周りよりもgatewareその他諸々全体の組み合わせとして)
SSHやCockpitが最初から設定されてる
そもそもYoctoよりDebian(系)ディストリビューションの方が慣れてる

などは個人的に恩恵として得られているので，自分としてはこっちでよかったかなあとなってます

GPIOをlinuxから操作するためのライブラリ(libgpiod)に関して

この記事を読んでいる人は恐らくですが普段から電子工作されている人が多いと(勝手に)思っていますので，そういう体で話を進めます．

2019年頃からsysfsによるGPIOの操作が非推奨となり，代わりにlibgpiodという，キャラクタデバイスとしてGPIOを扱うライブラリがメインで使われるようになっています．

特にraspi5が出たあたりでこの話題が一番盛り上がっていたように思います．そんな訳で「libgpiod」などのキーワードでググると2024/2頃の記事が出てくる訳ですが…
(下記にからあげさんの記事を貼っておきます)

ラズパイ5のlibgpiodでGPIO制御（Lチカ）する

実はここで紹介されているlibgpiodはver1.6のもので，その後2024年の夏ごろ？にlibgpiodはメジャーアップデートをし，現在aptでpythonのラッパーをインストールするとv2.1.3が入ってきます．

何が厄介かって，これメジャーアップデートなのでv1.6.3とスクリプトの互換性が保たれていません．

libgpiod v2.0

This is a major release that breaks compatiblity with the v1.6.x series. The
entire data model has been overhauled in order to make using the library more
intuitive and less cumbersome, while also making the code future-proof and
extensible. Please refer to the documentation for details.

New features: