Luckfox

 V3sを見つけたときに、カメラモジュールを使ってなにか作ろうとしたときに面白そうだな…と思っていじってきてみていたものの、残念ながら過程で壊してしまったのでストーリーは一旦お蔵入り。Lichee Zeroを先に調達しても良かったのだけど、dockとはコネクタ配置が違うし、ちょうどMilk-VとかLuckFoxとか出てきたこともあってそれを先に眺めてみることにした。

両方、入手してはいるけど、問題は、Lichee Zeroとは世代的に違いどちらのボードもMIPIサポート主眼のようであること。MIPIは、解像度などによって使用するレーン数は違うし、信号レベル的規格は共通とはいえ使用するコネクタは統一されていないので、ラズパイでさえ1mmピッチ15pinと、0.5mmピッチ22pinの2種の実装がある。流石に1mmピッチはコネクタサイズが大きくなる関係で、Luckfox、Milk含め0.5mmピッチ品が主流になってきているみたいだけど、ピン数は15、22、24といったところで、ラズパイ用のカメラモジュールが入手しやすいとは言っても、ほぼ間違いなく「ピッチ・ピン数変換コネクタ」が必要になる。

変換コネクタさえ作れてしまえればどちらのボードでも良いのではあるけど、LuckFoxのほうであれば、BT.656を含めCMOS parallelを実装しようとする動きがあるように思えた（あくまでも検索できた範疇で）。

環境づくり

　LuckfoxでもMilkでも、結構webを使って一通りの情報が出されてるんじゃないかと思う。Licheeでは中国語主体記事が多くgoogle翻訳使って読む、みたいなケースがあったけど、Luckfox、Milk共英語で書いてくれているのでなんとかならないわけではない。

カメラ（モジュール）を使おうとすると、デバイスドライバをビルドしないとならないとか起こるので、buildrootやらyoctoやらを使ったSDKを、最低一度は通しておく必要がある。LuckfoxにしてもMilkにしても、実際に活用するかどうかは別として、ヘテロなマルチコアSoCを使っている関係で、汎用的に入手できるコンパイラを使えばビルドできるとは限らず、SDKが提供されているならまずそれを使うことになる。必要な情報はwikiにあるのでその内容をたどればよいのだが。ヘテロマルチコアであっても負荷分散とか機能してくれると良いのだけど、どちらも２つコアが入ってまっせーという構成らしい。タスク分けみたいなことができてくれたら良いのにな。

ハマった？

　wiki掲載の開発用推奨環境はubuntu Jammy (22.04)ということになっているのだけど、不幸にも？自宅ではDebian使いでtrixieになっている。親戚とはいえ基礎としているツールバージョンが異なることには注意が必要になる。結果として、２つ問題発生。

一つはSDKで使用しているlibffiが若干古いバージョンであることで、そのbuildに失敗する。内容としては　https://github.com/mxe/mxe/issues/3082　に記載されているものと同一で、libffiのバージョンを3.4.6にしてしまえばよい。libffi.mk内で、使用するバージョン（＝ダウンロードしてくるソース）が指定されているのでそれを書き換えるとともに。予めlibffiソースtgzのsha256を確認し、合わせてlibffi.hashの内容も書き換えてやる必要がある。

もう一つはatmb-wifiドライバのビルド部分で、これ、特にコンパイラなどがリソース食い合いしているとかということが起こっているわけではなく、単にmakeが進まない。一連のbuild script (build.sh)を確認して見ても、特に問題はなさそうに思われるのだけど。

スクリプトを部分実行などしながら確認してみると、trixieとjammyでは、gnutoolsバージョンが違っていると思うけどgccバージョンは関係なく、makeのバージョンが問題であった。

trixieはmake4.4、jammyはmake4.3なのだけど、trixieのmakeを入れ替えるためにbookwormから持ってくるのはリスクがあるように思い、ソースからmakeしてしまう方を選んだ。つまりtrixieデフォルトのmake4.4は/usr/bin/makeのまま、/usr/local/bin/makeにmake4.3を置くことにして、後々alternativesを使って切り替える、か、な…。

atbm-wifiは、make4.3を使えばbuildできたので、全体をビルドし直すことで整った。

とりあえず。

　で、こいつをインストールするのか？というと、まだそこまでは試してない。とにかく、開発環境サイドで、必要ならデバドラのビルドなど可能になったので、この先順を追って試していきたい。

Lichee Zero Dock その２

 忘れてたわけじゃないんですがちょいと手を付けられずでいたLichee Zero Dock。改め、カメラを動かそうと、持ち出して、buildrootで再始動、したのは実は２年ちょっと前で、その後の紆余曲折。

このボードを手に入れた直後ではまだカメラサポートも怪しく、その後MIPIサポートが出来上がったのなんの、という記事は見たりしていたのだけど、これはLinxu5.19改め6.0で取り込まれているようです。前回は5.10あたりで足踏みしたので、今回は6.0で見ていこう、と思っていたら、もう6.1に移りそうですんで、書いている時点での最新6.1.4で行こうとおもいます。

buildroot

buildroot.orgから新しいものを持ってきて、一旦ビルドを試してみると、ubootをビルドする際、sun8iサポートのethernetを有効にするとエラーになってしまうのでそれは追求せず、一旦その前の版で(2022.02.8)、エラーなくbuildできることを確認。この版のデフォルトのLinuxカーネルは5.3。しかしdevice treeをいじってないので、このままでは「動いてますねー」とシリアルコンソールで見えてるだけなので、本番に取り掛かることにします。Ethernetのdevice treeについては、こちらのサイトを参照しています、翻訳なしには到底読めませんが、googleのおかげで翻訳でき、このようにドキュメント化してくれているのは助かります。そのサイトの記述の通りu-bootのdevice treeを修正します。Kernelの方は、それより進んでいるため、少し調整が必要です。他に必要なこととして、うちではdhcpでアドレス割当しているのでdhcpcdをbuildするように設定しました。buildは問題なく進み、75Mbytesほどのイメージが出来上がります。これをmicroSDに書いて、ブートしてみると、ちゃんと動いて、ネットワークにもぶら下がってくれました。しかしusbが、ドライバは読まれているものの動いてくれません。

その後。Buildroot-2022.11に含まれるuboot-2022.01では、device tree修正無しでethernet動きましたので、上記は、逆に、行うべきではない修正をdevice treeに行っていた、ということになります。しかし、依然としてusbは動かず‥。

カメラ

手元に、昔秋月で調達したMTV-54K0DNがあります。これ、息が長くて、今でも販売しているようですが、CCDだけに？それともアナログビデオがあるから？電源として12V必要なのが少々ネックです。

このカメラモジュールには、アナログビデオ出力以外にBT.656があるし、AWBなどスイッチもついているのでこういうボードでの制御は面白みがあると思うのだけども、V3s自体、デバイスとしてBT.656への対応はあるものの、デバドラ事例がまだ見つからないこともあり、このボードでカメラを使うには、CMOSパラレルがまず先決、だよね。

カメラモジュールとして安価で手に入りやすかったのは次の２種、一つはov7670、もう一つはov2640。ov7670の方は、Arduino向けにレートを落として使う事例が見つかりますが、手に入れたモジュールは故に3.3V単一動作になるよう構成されていてかつフラットケーブルでつなぐようになっている関係で、Lichee zero側がフレキコネクタになっている以上中継用のボードを作る必要がある。その関係で、フレキ上に実装されていてかつ信号配置を変更する必要がないov2640のほうが楽なので、ov2640をまず動かそう。なお、ov7670は、FIFO載ってないやつなので、Arduinoなボードでは、多分低フレームレートにしか対応できません。まとにかく、3.3v → 3.0vと1.8vだったかに落とすLDOが搭載されているだけなので、LDOを取っ払って、LDO出力端子に必要な電源を配線してやれば良さげです。

Build & test...　

　で、ov2640を使うようbuildrootをconfigし、device treeを作って動かしてみると、実のところ結構すんなり動いてくれたんですが、あれこれ試したり整理したりしているうちに、Lichee zeroがフリーズするようになり、その際V3sがチンチンになるように…　カメラドライバをロードしなければLinuxは動いているので、ISPが壊れてしまったようだ。

さいごに

　というわけで、残念ながらこの記事は完成できず…。記録を残せてないので、動いた、という証拠がなく申し訳ない。

なお、Lichee Zero Dockでは、ボードマニュアル上CMOS parallelとMIPIがどちらも使えそうに見えるのだけど、MIPIにはコネクタは載っておらず、1mmピッチ15pinフレキコネクタを搭載してやれば使えるのではないかとは思いますが、回路図面見ればCMOS他と共用ピンがあるため、device tree含めての見直しが必要になるだろうと思います。流石にMIPIのカメラモジュールまでは入手してなかったんですが、いずれLichee Zeroを使って監視カメラ的なことは試したいと思っているので、そのときに再戦したいと思います。

なお、CMOS parallelを搭載しているデバイス、ひいてはボードは減ってきていて、MIPIに移ってきているので、ov2640を活かすためにはLichee Zeroを少し押さえておかんといかんなー。

Time server, reloaded

 前回書いてから、家のリフォームがあったり、Jetson Nanoでarmbianがどうにもうまく動かないとかLichee Zero DockでDVPなカメラ(モジュール)を動かすためにbuildrootするとか結局DVP I/F周りが壊れてしまったらしくV3Sがチンチンになっちまう（Linux自体は走行している）、みたいな、ネタになりそうなことはそれなりに無くはなかったのだけど、まとめるモチベはちょっと無かった。

とはいえ、ぼーっとPrimeVideoばっかり眺めてても仕方ない。

GPSとgpsd

昔制作したtime server、Trimbleの古いGPSを使っているのだけどもバックアップバッテリが切れてしまっていて、再起動が必要になるたびに、NMEAモード及び通信モード切り替え（Trimbleなのでデフォルトは、TSIPでかつUARTによるシリアル通信モードは9600bps 8O1であるため、NMEAモード切替と通信モード9600N1への設定変更を、Windowsを使って実施）をしてやらないとならない。最初に製作したときは、テキストでgpsデータを読むことができるNMEAモードを使ってちゃんと衛星掴めているかどうかなど目視していたのだけど、実際、gpsdとクライアントが使えていれば、ASCIIテキストである必要はもうない。通信モード（パリティ設定）を変えないとならないのは、Jammyに含まれているgpsdが、8N1じゃないと通信できないためで、バッテリが切れてしまったとき、初期状態のgpsを使えないが故だった。

systemd

gpsdのクライアントであるcgpsでは、NMEAじゃなくともTSIPをハンドリングできるので（gpsmonはだめだが）、Linuxサイドで起動時にUARTの通信モードを8N1から8O1へ変更してやればよい。それをやるにはsystemdを使って、gpsdが立ち上がる前にsttyしてやれば良い（のだけど、gpsdは、nobleのものならparityを自動判別しているようには思うので、仮にgpsモジュールのデフォルトが8N1ではないとしても、何もしなくても動くかもしれない…）。

gpsは、Nanopi NeoのttyS2に接続、ppsはPA6に接続しているので、armbianEnv.txtに

param_pps_pin=PA6

追加し、gpsdを起動するgpsd.serviceに：

ExecStartPre=/bin/stty speed 9600 parenb parodd cs8 -cstopb -F /dev/ttyS2

を追加してリロードさせてやれば良いことになる。

pps

念の為（…）、Windows用の設定ツールを使ってgpsのpps出力が有効であることを確認、armbian側で設定が認識されているようではあるのだけど、ppstestではなかなかうまくfetchできていない。

$ sudo ppstest /dev/pps0

trying PPS source "/dev/pps0"

found PPS source "/dev/pps0"

ok, found 1 source(s), now start fetching data...

time_pps_fetch() error -1 (Connection timed out)

...

PPS信号の立ち上がりを使うのか立ち下がりを使うのか？デフォルトは立ち上がりのはず。

$ sudo cat /sys/kernel/debug/gpio

gpiochip0: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:

 gpio-6   (                    |pps@0               ) in  lo IRQ 

 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW

 gpio-204 (                    |usb0_id_det         ) in  hi IRQ 

立ち下がりで割り込み検出？

なら、armbianEnv.txtにparam_pps_falling_edge=1を追加して立ち下がりにしてみると、ppstest上は検出できるようになる。

$ sudo ppstest /dev/pps0

trying PPS source "/dev/pps0"

found PPS source "/dev/pps0"

ok, found 1 source(s), now start fetching data...

source 0 - assert 1775693725.000138656, sequence: 55 - clear  0.000000000, sequence: 0

chrony

NTPサーバーとしてはchronyが最近はよく使われるようで、使ってみることにする。よくGPSとの組み合わせではNMEAメッセージも使うように設定されているようだけど、ppsだけ使えれば良いので、次の一行をchrony.confの最後に追加。

refclock PPS /dev/pps0 refid PPS

次の状況。

$ chronyc sources

MS Name/IP address         Stratum Poll Reach LastRx Last sample               

===============================================================================

#* PPS                           0   4   377    16   +737ns[+1442ns] +/- 1891ns

^- alphyn.canonical.com          2   6   337    45  +3332us[+3329us] +/-  120ms

...

ということで、ppsがソースとして使われるようになりました。

TinyDRMとili9328（まだ未完）

 組み込みボード用にLCDがちょっと足りてないので、TinyDRMでサポートされていないili9328ベースのLCDを動かせないか試してみることにした。

「動かせないか」とはすなわち、tinyDRMドライバを作ることになるわけなのだけど、当然ゼロから書けるわけない。いくつか調べてみると、16bitデータで送る必要があるような感じ（2バイトバーストしてるんだと思いますが) で、ili9225のドライバをベースに使えそうなので、それで考えてみる。

初期化コードは、ili9328のapplication noteにあるので…ということで作業開始、初期化コードを入れ替え、device treeを作成して再起動し、ドライバはロードされていることを確認。しかし、真っ白のままで初期化が実行されてない。

このままでは、パネル自体が壊れているのか（だって３〜4年くらい前に買ったやつだし…）ドライバがだめなのかわからない。

先人のみなさんのお知恵を頼ると、ili9328はほぼ皆さんpythonから使っておられるようで、私のように、tinyDRMつかってXアプリを動かそう、という人はどうやら奇特なようだ。ま、パネルのテストとしては全然pythonコードで問題ない。
そこで、同じパネルであるこちらのサイトのコードを利用させていただくことに。

先達は、プラットホームとしてはzynqを使われているのだけども、それ自体がなにかネックになることはない、のだが、問題は、使用されているカーネルがちょっと古く、GPIOアクセスにsysfsを使用されている。これはもう、私が動かそうとしているarmbian上では使えない方法であるため、書き換えなければならない。

こちらのサイトと、こちらのサイトを参考にさせていただいて、スクリプトを修正し…、おぉ、ちゃんと動いてくれんじゃん！（そのうち、その修正コードはgithubにでも掲載します。）

私が修正中のtinyDRMドライバでも、ほぼ同じ（というか全く同じ）初期化を行っても動いてくれていないので、おそらくspiからの書き込みでうまく行っていないポイントがあるようだ。それには10MHzのSPIをキャプチャできるロジアナが必要だ…。

GW中に購入したst7789vパネル(CSなしのst7789ではなくCSのあるst7789v)も届いてしまい、それもtinyDRMで動かすつもりなので、これも色々試す必要があることもあり、またしばらくしまい込むことになりそう…　しかし、どちらかは使えるようにしたい。

Armbian Jetson nano

 今に始まったことじゃないが、なかなか最後まで進められてないことが多いなぁ。これもその一つになるかもしれんけど、Jetson nano dev kitのnVIDIAサイドでのサポートが終了してしまってkernel4から先に進まない。それだと困るところがあって、もっと新しいカーネルで動いてほしい。

Amrbianでcommunityサポートになっているのを見つけ、試してみることにした（Jetson nanoモジュールを搭載している組み込み装置はまだ増えているので、Jetson nanoモジュール自体がEOLを迎えたわけではない、はずだけど、なんだかnanoモジュール自体がEOLになったかのごとく、書いてる人いるよね…　もちろん、nVIDIA自身がカーネルサポートを広げてくれるわけではないことにはなるだろうけど）。

いま、armbianサイトに見えているのは随分と新しいkernel6.6で、しかもちゃんと起動してくれない。これでは仕方ないので、最低限kernel5であって欲しいので、22.11.1イメージをインストール。Armbianお使いの方はよくご存知のとおり、USB HDDにrootを置くスクリプトがあるので、それを使うことにする。

22.11.1はすんなり起動してはくれる。でarmbian-configからHDDにroot転送。作業は順当に進み、再起動すると、あれ、microSDのままじゃん。

HDD内容を調べてみるとちゃんと転送されているのだけども、rootがmicroSDを指したままになっている。/etc/default/grubに、rootとしてHDDに転送されるものを指すよう追加してupdate-grub。

起動すると、今度はmaintenance modeに落ちている。カーネル自体は立ち上がっているので、rootを確認するとちゃんとHDDを向いていた。

なんでmaintenance modeに落ちるのか？と思ったら、microSDのEFIパーティションをext4でマウントするfstabになっていて、それで文句言っていることがわかったので、vfatに直して再起動し、ようやく普通に立ち上がるようになった。

これでupgrade、dist-upgradeして、taskselしてXfce足して… 23.8.1 bookwormに。カーネルは5.19だけど。

再起動してみたら、lightdmが1024x768モードでしか立ち上がってくれん。モニタは一応fullHDなのだけども、しかし1024x768だけしか返答していないようだ。　他のarmbianベースのシステムでも、ましてやx64 bookwormでも、問題なく表示できているので、Jetson nanoでは、何らかの設定を施さないと動かせないということになる。
Jetpackではちゃんと出せていたので、そうかぁ、これはcommunityサポートの洗礼だな…

一番最近、ではないbookwormイメージを試すことを含め、また時間があるときに考えよう。

Nanopi NEOにROS noetic

ちょっと思いついたコトがあり、Nanopi NEO / bullseyeにROSをインストールしようと。

しかし、知られているとおりBullseyeにはpackageが存在していないので、もっとlowレベルな作業が発生。

なので、とりあえず備忘。後で清書する、かも（あるいは、give upして放置するか…）。

Debパッケージはない。

基本的には、つぎの2ヶ所の内容の実施。

https://catkin-tools.readthedocs.io/en/latest/installing.html

http://wiki.ros.org/noetic/Installation/Source

ubuntu用パッケージを一部拾うためのapt source追加とkey追加はしておいた(やんなくてもできるんじゃないかと思う。確認してないだけ)。

# catkin関連のダウンロード

sudo pip3 install -U catkin_tools

git clone https://github.com/catkin/catkin_tools.git

cd catkin_tools/

pip3 install -r requirements.txt --upgrade

sudo python3 setup.py install --record install_manifest.txt

sudo python3 setup.py develop

# ROS -- noetic

sudo apt install python3-rosdep python3-rosinstall-generator python3-vcstools python3-vcstool

# python3-vcstool

python3-vcstoolは存在していないためvcsをインストールできない。なのでpip。

sudo pip3 install -U vcstool

rosinstall_generator desktop --rosdistro noetic --deps --tar > noetic-desktop.rosinstall

vcs import --input noetic-desktop.rosinstall ./src

# python3-rosdep

python3-rosdepはpython3-rosdep2がインストールされる、が、これはうまく動かない?。このパッケージはpurgeしてpip。

sudo pip3 install rosdep

# そしてrosdep実行

rosdep install --from-paths ./src --ignore-packages-from-source --rosdistro noetic -y

# libogreがマッチしない

ERROR: the following packages/stacks could not have their rosdep keys resolved

to system dependencies:

rviz: No definition of [libogre] for OS version [bullseye]

libogre-1.12-dev、libogre-1.9-dev、どちらも試したけど上記変わらず。ROS Indexによるとnot availableとなっていることによるのではないかな…。rosdepに、こいつはローカルにあると設定。このローカル設定は、他の設定よりも先に実行されるように、ファイル名を決める必要がある(数時間これにはまる…）。

で、rosdep updateして、

この設定を行い、無事に？build始まる。

この先は時間かかるのでまた今度。catkin workspaceのビルドにいけるとええな…。

Jetson nanoのセットアップ

メモリ2GB版が出た暁には買おうかな‥と思いつつ、出た当時その他の選択肢もいろいろとあったこともあり、結局手にしていなかったJetson nano。本家の「開発者キット」が終了して、nanoモジュールを採用した3rd party製品がいろいろ手に入るようになっていると思いますが、ひょんなことからB01版を調達しました。

というわけで、セットアップ。

仕事方面でJetson nanoは使ったことがあって、ただ、microSDに一抹の不安を抱えつつ。

そういうわけで、bootには要microSDだけどセットアップしたらとっととUSBにroot持ってこ、と。

手元に残っているものからピックアップしたのはL社、たしかこれ、nanopiで使おうとしてとっても遅くて‥だったような‥と思いつつ、イメージを書き込んで起動。遅いような気はするけど使えてるかな？どうせUSB HDDにするし‥と思ったのが運の尽き。

Jetson nanoのrootを外出しするに、JetsonHacks、rootOnUSBが使われることが多い様子ですが、その手順としては、initramfs にUSB ドライバを足して、USB HDD（、SSDなど）に置かれているrootファイルシステムにアクセスできるようにして、bootloaderにroot をポイントする、ということのようです。

最近のL4Tカーネルは、ドライバの多くはモジュールではなく組み込まれているようなので、initrdに関しては書き換えずとも動きましたが、問題はrootファイルシステムのコピー。copyRootToUSB、これはrsync使ってコピーする定番の手法かなと思います。

まず2.5" HDD用のUSB3.1アダプタ、これにcopyRootToUSBしようとすると、rsync書き込みに失敗してファイルシステムに書き込みできなくなりスクリプトがクラッシュしてしまう。

何度か試すうちにmicroSD側での読み出しエラーも発生、他のmicroSDでやり直すも状況変わらず。

この2.5"アダプタはrock64のboot/rootに使っていたこともあり大丈夫なはず、と思っていたのだが、頭を冷やす意味も込めて、お蔵からパラレルATA版の2.5"を持って来てcopyRootToUSBすると、これはちゃんと最後までrsyncが動く。

しかし、PATAの2.5"アダプタは、USB１ポートでは電力賄えず２ポート必要で、もちろんホスト電源への負担もあり、実際に、消費電力大きすぎ、のワーニングが出てしまう。そうかぁ‥。

残る手段は3.5"のUSB3.1アダプタで、これももとはrock64のboot/rootに使っていたのだけども、ayufanのカーネルでは使えるのに、素のdebianに切り替えようとしていた時点では、rock64でのUSB3サポートをしてくれていなかった関係で（今はどうなのか、は、確認しておりませんが‥）お蔵入りしていたもの。3.5"なので当然セルフパワーであることもあり、ようやく、copyRootToUSBを完了。

rootOnUSB手順的には、次extlinux.confの書き換えを行って、rootがUSBに存在している指定をする。このあたりはblkidからUUID情報を得てそれを使うのが一般的だろうし、事実rootOnUSBでもそれがデフォルト、ということで、UUID得て、initrdは先に述べたとおりUSBは組み込まれているので放っておいて、rootを指定して再起動。ところがrootを見つけられず、再起動を繰り返してしまう。

NanoからmicroSDを外して他の端末でextlinux.conf確認、問題ないはずなので、UUIDではなくdev名で指定して起動、これで動きました。

USBメディアでは何が起こるかわからないので、こういうところではUUIDで指定したいんですけどね‥。誰が妨げているのやら。

ということで、rootOnUSBではなくとも、まず/dev/mmcblk0p1を、新しい USBメディアに、rsyncあるいはdump & restoreするなどにより複製し、そこを、bootloaderのrootとして指定する、という手法だったわけですが、これ、カーネルを何らかの事情でrebuildする場合、USBをカーネル組み込みから外してしまうと、initrdでの対処を忘れちゃうと起動できなくなってしまいますね。注意しておかいと。

Software SPI

 NanoPi NEOを有効活用しようと思うと、個人的には２つ、ネックを感じます。一つはディスプレイインターフェースがないこと、もう一つは、微妙にインターフェースが足らないこと。それでいつも、BeagleBone(Pocket Beagle)でやるか、NEOでやるか、はたまたmbed系でやるか悩むことに。

NanoPi NEOにILI9341ベースの SPI LCDをつなげる話はもう実績があるので、NEOで、spi-gpioを使ってSPIポートを増やしてみることにしました。PocketBeagleだとシングルコアであることが影響しそうなアプリを考えているので、マルチコアSoCを使っているものを使いたかったんです（そのうちSTM32MP15xに侵食されそうなエリアですな‥）。

 Armbian 23.02.2 / Bullseye (Linux5.15.93-sunxi)

空いているNanoPi NEOがあったのでそれを使うのだけど、microSDがなかったので調達、セットアップして、カーネルソースとビルド時のconfigを確認してみると、spi-gpioは作られていない。ということは、ビルドしないとならない。クロスビルドでもネイティブビルドでもどちらでも構わなかったので、ネイティブビルドさせてみました。
ただ、microSD上でカーネルビルドし始めると、ファイルシステムが壊れてしまったときのショックが大きいので、USB HDDを持ってきて、nand-sata-installで、HDD上で作業するようにします。Armbianとしては、カーネルだけビルドするオプションもありそうではあったのだけど、どちらかというとイメージ全体再構築を行うことを考えているように思えたので、debian流儀で、ソース添付の.configを使ってmenuconfigし、spi-gpioをmoduleとしてビルドするよう設定し、make bindeb-pkgしてイメージを得ました。

Device Treeさえできれば‥

ということで、取り掛かりとして超ベーシックなところだけ記述したdevice treeをarmbian-add-overlayしてやって起動・確認しますかね、と始めたわけですが、しばらく逡巡するはめに。どうやらclientセクションをちゃんと作成してやらないと、spi-gpioだけロードはされるもののそれ以上なんのメッセージも残さない模様。Armbianフォーラムにまで投げ込んでみるも反応なし（というか、もうこの辺の話は枯れてるんだよね、きっと）。
投げ込んでみたからと言っても、当然試行錯誤するわけで、試験用に、実績がある、spiのili9341を使えるようセットアップ。最終的には他のLCDにしたいのだけど、最近のカーネルのtinydrmでサポートされていないものであるため、それはそれで戦わないとならないので、まずはspi-gpioを動かすことに専念。ili9341をspi-gpioに接続するclientとして記述することでspiバスがあらわれ、ili9341ドライバ、/dev/fb0まで登録されることを確認。しかしLCDには何も表示されず‥。

GPIO番号の罠

ちゃんとドキュメント読んでればまず間違えないところなんですが、ちょっと斜め読みした資料からGPIO番号勘違いして記述していることに気づかず、結構長いこと格闘するはめに。結果的にfriendlyarmのwikiに立ち返って、冷静に(笑)見直すことで、動きましたよ‥

流石にハードウエアspiと比べるともっさり（設定上は速度半分）、実際にどのくらいの速度のsclkが出ているのかまでは見てないんですが、lightdm表示されるところまで確認できました。

これで、ハードウエアSPIと合わせて２系統のSPIを使えそうです。連休の前半でここまで終わらせたかったんですが、ちょっと時間かけ過ぎちゃったな‥。

WIndows11にupgrade その２

 次の記事を半分書きかけているところで、Windowsを立ち上げてみたら、windows updateに失敗している。Updateをインストールするけど、失敗して前の状態に戻してる。起動する都度それが起こっていて、そのupdateが、.netに関するものだったこともあり、「うーん、updateに問題ありや？当てなくても良いかなー」と思い、そのupdateを当てないようにしようとしたら、そもそもインストールに成功していないので設定できないような感じ（できるのかもしれんけど、方法を見っけられなかった）。

この.net、いるかわからんしパッケージ自体再インストールしてみよ、と思ったら、消すこともできない様子。どうやら、ファイルシステムがreadonly的動作をしている。おー？SSDにして１年経ったっけ？とか思いながら、HDDにインストールしよっかなー、しかしreadonlyステータスが問題なんちゃうん？とか思いながら、あちこち漁っていると、どうも我らが(笑) MicrosoftさんはHDDをお払い箱にしてSSD一本槍で行こうとしているらしい、ということで、SSD買っとくかー、ということでポチッとな。

新SSDにお引越しするには回復イメージだよね、ということで、以前、HDD→SSDに引っ越したときに使った回復イメージでやろうとしたら、なんとMBRで復元してくれて、WIn11に進むためには、プライマリパーティンションを３つ以内にする悪夢にあらため遭遇する。
最大の問題は、どうしてそういうセットアップをするのか、SSDの中間に、uefi bootを置いてくれる。このせいで、パーティションを４つ最初から作ってくれて、かつ、整理しづらい。さんざんあがいてmbr2gptできたーと思ったのだけど、Win11 upgradeできないときたもんだ‥。

旧SSDのWIn11、立ち上がりはするので改めて回復ディスクあるいは、セットアップ用イメージを作ろうとしたら、ファイルシステムに書き込みできないので、それらイメージを作ることすらできない。

結論。

回復イメージ、せっかく作ってもOS世代が変わると、前提条件がきれいに変えられてしまう関係で、OS世代交代が絡むと、使えない。

幸いなことに、WIn10インストールDVDも作ってあったので、そこからやり直しました。

旧SSDには、アーカイブやらまだ使いたいデータやらがたくさん押し込まれているので、USB3なケースに入れて様子見てますが、やはり読み出して停止するので、bad blockがある雰囲気。そういう意味じゃfailsafeで、readonlyでマウントし動いていたわけで、ある程度安全方向には転がってはいるのだけど、そういった情報がログでぱっと見つけられない（そもそも記録されているかどうかを調べる気力が出ないようなロギングなので‥）、それではねーと思うところです。

で、新たにセットアップした形になるWin10→11、新しい回復イメージ作っとかなきゃなーとは思いつつ、如何な局面でも使えるものじゃないってことも今回わかったので、インストールイメージのDVDだけ作っておこうかな、と思ってます。それだと、色々インストールしたツール類もすべて再インストールになるので、どこかにまとめて保管しておかないとね。やっぱそれにはsambaサーバーか‥一時はNFSと連動して使ってはいたんだけど、アカウント管理を連携するのがなかなか維持できない記憶が‥。

Windows11にupgrade

Dual bootでハマるまえから、さすがにE-450でWindows10はキビシー。Windows10が最後のナンバリングwindowsじゃなかったのかよと思いつつ、ならWindows11にできるハードを…と思って、とうとうアマゾンのセールで、Ryzen5/5500とA520に16GのRAMを調達しました。正確には、A520はその価格では欠品していて、入荷未定、だったんですが、２週間ほど待って見て、結局ステータスに変更なく、キャンセルしてドスパラで調達。

ライセンスの移行

Windows、引っ越すべきか、それともイメージ使って再セットアップを試みるか？

仕事ではWindowsノートを使わざるを得ないので使いますが、それ以外はLinux、結果Windowsはエンドユーザー以外の何物でもないのですが、インストール済みのものを考え、HDD(SSDですが…)そのままマザーボード交換、で行ってみることにしました。日頃からそんなに使うわけじゃないんで、過剰っちゃ過剰なんですけど。

まずはE-450で稼働しているWindows10上で、ライセンスを購入して使っているアプリケーション類からすべてライセンスを引き上げます。Windowsライセンスは、これはWindows8からupgradeして使っているものですが、Microsoftアカウントを使っているので、一旦、ローカルアカウントに切り替えを行います。…、という詳しい説明をしてくれていたサイトがこちら。

Scrap & build

Ryzen5 + A520をセットアップします。SSDをつないでやって起動してみると、アプリケーションを正しく起動できませんでした(0xc000007b)と言われる。mmc.exeがアプリケーションエラーを起こしているようで、DISM /Online /Cleanup-Image /RestoreHealth で修復して、立ち上がりました。必要なライセンス再セットアップしておしまい。やれやれ。でもどうしてそうなったかっていう原因はわっかんないままなんだよね…。

Windows11に…

これでハードウエア的にWindows11にも問題なく対応できてるよねーと思ってWindows Updateの状態を確認してみると、引き続き「このPCは現在（以下略）」。
あれれーと思い、windowshealthchecksetup.msiからチェックをかけてみると、セキュアブート対応してないことが問題だとわかる。
セキュアブートのためには、ブートにmbrではなくuefiを使う必要がある。
E-450が載っているE45M1-M自体はuefi biosを搭載しているはずで、dual bootをセットアップしたときもuefiを使っている認識だったんだが…と思いつつ確認してみるとgptではなくmbrになっているという。そういえば、パーティションタイプをgptでセットアップしようとしてたのに、なぜかできずmbrにしてた、ということを思い出した。

mbr2gpt

これが成立するにはプライマリパーティションが３つまでとかよくわからない制限がある。このディスクのパーティションは４つ全部使ってあって、一つは修復用のパーティションになっていました。usbメモリで回復ディスクを再作成しようとすると、「このPCでは回復ドライブを作成できません」？？？WindowsREがDisabledになっていたんだけどこれもよくわかんないなぁ…。だって回復ドライブ前は作れてたじゃん、とは思うものの、確かにWindows8セットアップ当初からあったか、それとも、WindowsREのためにあとからスペースを確保したのか、ちょっと記憶にない。どっちにしろ３つにしなければならないようなので、それに合わせるようパーティション調整。これでmbr2gpt実行してみると、最後にFailed to update ReAgent.xmlと言われる。これは、WindowsREが回復用に使うパーティションの設定の合わせこみをすることで対処。

BIOS変更 → Windows11

これでようやくセキュアブート可能に。

正常に立ち上がったようなので、ようやくWindows11に。

結構トラブルありましたね…もう少しあったような気もしますが、実施してからもう一ヶ月近く経過していることもあって、chromeの履歴から手繰れるだけ手繰ってみました。

Windows8からの持ち上げってのが、結構余計な条件を作っていたのかもしれない。回復ディスクを使って、様々再インストールしたほうが全然早かったかもしれません。

多彩なx86 CPUが存在していたXP時代には、同様、当初セットアップしたPCの故障などでハード変更を余儀なくされたときに、バイナリ互換問題に起因して、そもそも起動できないケースが存在していたことを思うと、楽になった、の、かもしれません（むしろMicrosoftのポリシーが、ハードウエアくくりつけからアカウントくくりつけに変わった- ということでよいのかな…- 、という方が大きいのかもしれませんが）。

後記

E-450は、Linuxを改めてセットアップしたんだけど、エコ設定だと、結構微妙なパフォーマンスだな、やっぱり。Rock64よりはそれでも速いようには思うんだけど、Raspi3でやってるレコーダーを移すほうが優先度は高いかもしれない。

BTヘッドホンのmicroB電源端子を修理してみる

 うちの家族は、いわゆる「インナーイヤータイプ」のヘッドホンと相性が悪いようで、なぜか密閉型、しかもスマホが変わってもプラグ形状の影響を受けないBTタイプを好んで使っているのだけど、概ね海外製で、プラ部品が割れてみたり、これは海外製には限らないけどUSB2.0 microBを給電端子として使っていたりして、ご存知の通りこいつはUSBケーブルもとへ電源ケーブル抜き差しの際に、こじったりすると、覿面に壊れる。

大抵はプラ部品を破壊してくれるんで、破壊した場所によって、ワイヤを埋め込んで溶着させてみたりする（当然見栄えは悪くなる、のだけども、だいたい自宅内でしか使ってないのでかんけいない）。

microBコネクタがほぼ破壊されたものが、まだ捨てられずに残っていたので、直してみる気になった。

ヘッドホンの各部構造については、オーディオテクニカさんのサイトへとリンクさせてもらいました。

構造を一通り見回してみて、スピーカーが収まっているハウジングに一緒にBT受信＋PA、それに電池が入っていることは間違いないので、まずイヤーパッドを外せればなんとかなりそう。電源端子がついているのは左側で、右側に電源とボリュームがついていることから、そちらにBT一式が入っていると分析。なら左だけ分解できればことは足りそう、きっとはめ込みだろうと思って、合わせ目を探って外してみると、ひねると外せる構造となっていた。幸い、爪は破壊されなかったので、もとに戻せそう。
スピーカー部分は３本のネジでハウジングに止められているので、分解してみると、案の定受電用のmicroBと、リチウム二次電池、それと、右側のBT+PAと接続、以上をまとめて行う一枚基板となっていた。念の為、基板裏側の写真。これは、各部配線をこの基板から外し、後に戻すために撮影したものです。

問題のUSB microBの、挿入口だけが見えてます。

microBコネクタは今やアマゾンで手に入るのだけども、こいつには形状が複数あり、同じ形状じゃないとなかなか交換がうまく行かない。

基板を見ると、やはり電源だけ使用していて、USBデバイスとしては機能しないようだ。

もともと搭載されていたのは、おそらくこじり対策を兼ねている、コネクタハウジング自身を、PCBに貫通させはんだ付けができるタイプだった。勘合側電極部分はもう粉々になってしまっているので、到底これでは機能しない、ので取り外す。

手元にあったのは表面実装用のものだったので、まずはこれで交換を試してみたが、やはりハウジングのはんだ付けだけでは強度が足りず、microBオスを差し込んでみると剥がれてしまう（本来、広く取られる必要があるはんだ面積がほぼないので、そういうことが起こる、ことはわかっちゃいたんですが）。と、案の定そのときにコネクタパターンも壊れてしまった。実際問題、電源としてしか使われていないため、ちょっと面倒になっただけでそれ自体対策ができないものではない。

アマゾンに同一形状品があったのでオーダーしたのだけども、届いたのはなんとワニ口クリップと、どこをどう商品登録を誤ったのやらと即刻返品処置。まぁ、この手の業者が何を送ってきても、あんまり驚いちゃいけないのだけど、流石に今回はため息付きました…。結局、若干形状が異なる、他の表面実装品を、何度か購入させてもらっていて大丈夫だと思っている業者から手に入れ（リールカット品が届きました）、ハウジング貫通はんだ付け用のホールを利用して錫メッキ線を渡し、補強的な構造をとってみることにした。
一応、これで、「正確に」（笑）抜き差しする分にはなんとかなりそうなので、組み立て、USB電源をさして起動してみると、ちゃんと動作してくれました。まぁ、ガシガシやられたら、また壊れるのは間違いなさそうですが。

microBコネクタって、結構こじりに弱く、Type-Cが登場するとまたたく間に退場してるんじゃないかと思います。たいていはケーブル側がだめになるんですが、今回のように本体側（デバイス側）がだめになっているケースも少なからずあります。
SBCでも結構使われてますけど、そういうボードでは、できる限り拡張コネクタ側にある電源端子を使うようにしてます。そもそも、特にUSB2.0向けには1A以上供給できる必要もないので、ケーブルや、ACアダプタもほとんど1Aまでしか供給できないこともあり、小規模なボードじゃないと、挙動不審にすぐに陥りますんで。

Dual bootに はまるなんて

 特定のアプリケーション、特にマルチメディア関係のアプリを使うために、Windows10なPCが数台あるのだけども、そのうち使用頻度が高く、しかしもっとも遅いものだけ、ubuntuを別ディスクにインストールしデュアルブートにしてある。部屋の模様替えを含むちょっとした『家庭の事情』で、このPC、概ね2ヶ月ほど電源を入れる機会がなかった。

ようやく事態も落ち着いたので、では久しぶりに、と電源入れてubuntuを立ち上げ。
このPCは、一時、DLに関する調査の関係で、18.40である必要があったんですが、もう20.04でよくなったので、upgradeすることにする（しかしまだ22.04にはできない）。

そもそも、この18.04→20.04て結構手間取るので、終わったやれやれと再起動すると、grubが、"grub_file_filters not found"と言ってくるで、あぁそうそう、自ディスクだけじゃなくてどっちでも起動しやすいようにwindows側もgrub動かしてたんだっけ、と、grub-install、update-grubして、ubuntuはOKOK。
やおらWindows10を立ち上げようとすると、まったく立ち上がらない。最初、窓ガ出て白点の『ぐるぐる』、暗転してマウスカーソルの青い『ぐるぐる』のままでまったくログインが立ち上がらない。

さて…。今までの経験から、犯人はgrubを再インストールしたことにあるんだが…と思い、回復ディスクで起動してbootrec /fixmbrしても解決しない。bootrec /scanosすると、「Windowsのインストールとして認識された合計数：0」と言われる。これに関して調べてみると、大抵、bootrec /rebuildbcdで解決する、で終わってる。それやって再起動してもなぁんも解決してない。
さぁ、どうしたもんかなぁ、もう一日以上費やしてるし、再インストールが頭をよぎるけど、決定打はここでした！最終的にはMicrosoft JPのお世話になった、ということですね…。

uefiになる前は、LinuxとWindowsのデュアルブートなんて長らくやってきて、再起動面倒なのでvmwareだなんだーってやっていたのに。今ではWSL2という手段もあり得るとはいえ、こんなところで引っかかるなんて…。
復旧が都度都度面倒なので、Windowsサイドのディスクには、grub入れんのもうやめよー。

なお、このPC、E-450なので、言うまでもなくWindows10も重たく、到底11対象外でもあるので、更新考えないといかんです。一時、11 upgradeは10月5日までか？？という情報が流れてだいぶ焦りましたが、そうだな、Ryzen5/4500が安くて乗り換えやすいかもなーと思う今日この頃。

ESP32でBTスピーカー、そして。

先週は、pcm5102からの出力が、ステレオミニプラグだけで…と言うところで終わってました。発注していたステレオミニプラグが届きましたので今週はその続き。

オーディオって、昔は真空管アンプとか作りはしてましたけど、そこから置き去りにされているので、5V単一で動いて安くて、ということでD級アンプなんて買っちまったのでハマるとは…。

さて、pam8403の入力側にプラグをつけて、pcm5102にさしてみるとプツプツプツプツ言ってる件。これなんだったかってぇとおマヌケなことに、GND配線を誤っていたからでした。とっても恥ずかしいお話m(_ _)m。

D級アンプって、以前、仕事の関係で、同僚が扱っていたことはあれど私自身はまったく触る機会がなく、なんだか判ってません。しかももう20年くらい前ですかねぇ…。
今回使うスピーカーは、PCにつないで使っていた関係で、これがまたステレオミニプラグになってます。ふつーに、アンプって言えばマイナスコモンでスピーカーにつなげりゃ音出るでしょ、って、大抵思うでしょ?　しかしD級アンプはそうはいかんかったんですよ。

なぁんとなく、マイナスコモンじゃないんですよーって話があったな…と、遠い記憶にはありつつ、どうgoogleにお伺い立てたら良いかも思いつかぬままキーワードを試すも結論でず、まぁ、ヘッドホンアンプみたいにマイナスコモンのステレオミニプラグでOKでしょ？と思い込んだのが運の尽き。

pcm5102の出力を、普通のアンプに食わせてみると問題なく鳴る、それも結構クリアに。おー、これが聴ければOKじゃんと思いpam8403を継げると、プツプツ言うかシーンとしているか。はて、これ電源か?と思ってesp32+pcm5102とpam8403の電源を分離すると、プツプツは言わんけどシーンとしてる。はてこれは壊した?と思い、2台セットの片割れに入れ替えても状況が変わらない。

これはきっとヘッドホンアンプとしてマイナスコモンで使おうというのが誤りなんだと考え直したのがすでに今日着手してから4時間後。改めて、『pam8403 ヘッドホンアンプ 』とお伺い立てると、あるわあるわ…、orz。

https://nheroshi.blogspot.com/2019/08/pam8403.html

などなど複数のサイトを参考にさせていただきました。

トランスを入れるのが本式のようですが、スペースファクタの問題もあり、ジャンク箱漁って10Ωを2つめっけだして使うことで、目的を達することができました。これで娘に渡せます。

使ったもの：

ESP32-SDevKitC-32E
GY-PCM5102
GF1002
ケースは何だっけ、SW-75Bだったかな。ESP32を保持することを目的に、ユニバーサル基板をネジ止めしそこにESP32を載せてあります(写真撮れよ…)。

pam8403/GF1002には電源スイッチついてますが、電源出力がない関係で、ESP32の+5V端子から電源貰っており、pam8403だけの電源切るかたちになってますんで、ほとんど意味ありませんね…。

ESP32でBTスピーカー

　GW以降から今年の夏は色々あって、週末のみならず夏休み中も大汗かいて『作業』していたせいか、それが終わって１ヶ月以上経っているというのに、色々行動を起こすのがとても億劫で、しかもすぐ眠くなる。これ、結局は夏の疲れが残っている、と言うことなんだろうと、勝手に割りきっちゃいるのだけども、イコール、何も作る・試す気にならないという事にもつながってしまっている。

いやいや、そんなことじゃ遺憾でしょう…

その『作業』の期間、話の流れとしては遠く関係、ないかも知れないけど、娘が、タブレットでオーケストラ聴いてるので『なんぼなんでもそりゃ音悪いしょ〜」から始まって、なら、これが落ち着いたら、使ってないスピーカーがあるからそれをbtスピーカー化しようかね、と、ここまではありがちな話。

で、アマゾン調べりゃきっと何かあるでしょ!と思って見てみると、あるこたあるけど、同じデバイス使っててもお高いもの以外、ことごとくTELECは通してない。そういうのお使いの向きもあるとは思うけど、電波暗室内じゃないと使えんのじゃ?ということでことごとく却下。

なら組み込みボードで…も、ラズパイ以外は有意な差は無いので、やるとなったらUSBのbtアダプタ利用か…とか考えつつ、でも、娘に、「こいつは電源入れるときと切るときは…」とか「つながるまでちょっと時間掛かるんで、このLCD見て確認して」などと、マルチタスクが故の制約があるlinuxベースであれこれ用意しておいて教えたところで、『そういうの面倒だからいらない』となること請け合い。
色々悩んで、WROOM32ならbt4使えんじゃん、電源バチバチやっても(たぶん)大丈夫だし、しかもTELEC通ってるのあるし！ということで、WROOM-02ではI/O的に足らない使い方をしようと思いつつ、死蔵していたWROOM32Eを引っ張り出した。

…、そこから１ヶ月、復帰できず再び放置。いやいやダメダメ、ということでようやく今月着手。

ただ、WROOM32は、「WROOM-02と同じようにarduino IDEでつかえんでしょ?」程度にしか思っておらず、『死蔵」の名のとおり、購入してからもう一年くらい放置(^^;;;;　btプロファイルも詳しいわけではないので、btスピーカーってば…と調べると、どうもesp ideのサンプルコード利用事例、プラスM5stackでの事例。

やり方はありそうね、ということで、ハード集め。nanopiで、mpd serverやらせることを考えていた、同じく死蔵のpcm5102モジュール(gy-pcm5102だと思う)を持ち出したけど、こいつはライン出力しかないので、『スピーカー』と名乗るにはパワーアンプも必要。
btスピーカーの面倒なところは、電源どうするか？　もちろん、ACアダプタ使うのだけども内部に電源系統が様々生じるのは、考えないとならないことが増えるので、5Vか3.3V単一のシステムにできてほしい。5Vで動いてくれりゃスマホ用のACアダプタを使える。
しかし、5Vで動いてくれるD級アンプって、ものすごい少なく、結局だいぶ安価な、2個セットのpam8403利用のボードを調達。

以上をつないで(今回は最終的に箱に納めないとなんない、ということとWROOM32Eがでかい関係で、ブレボで試し組せず直接ハンダ付けして組み立て。pcm5102は入力側I2Sも出力側アナログも端子に出ているので、そこにワイヤを半田付けして、WROOM32 - pcm5102 - pam8403を接続。

で、WROOM32Eに、esp ideサンプルから、README.mdどおりにa2dp sinkをビルドして書き込み。そしてリセットすると…

WROOM32Eはちゃんとa2dpとしてbtホスト（rock64にbluez他インストールし、btつかえるようにしてある) から見えていて、ちゃんとコネクト。しかし音が出ないいやむしろプツプツプツプツ言ってる。

はて？何か間違ってるんか…?と思い、pcm5102のステレオジャックから、他のオーディオセットにつないでみると、チャンと鳴るじゃん！あれー？パワーアンプまわりで何か間違えてる??と言うほど配線ないし…。今度はpcm5102のステレオジャックにつないだままpam8403にスピーカーつなぐと、今度は鳴ってくれる。

おっとぉ、どうやら、pcm5102の端子は、ステレオジャックに接続していないと出力が出ない設計になっているようだ。えー、スペースファクタ面で大ダメージじゃん。
とはいえ何とかケース内に収めることができそうなので、アマゾンでポチポチして、後は来週ーっ。ということで、今回はtext only。

rock64日本語環境短縮メモ、その後…。

 ayufan 0.11.2、…

　やはり、重くて重くてやってられない…。ので、スパッと諦めてarmbianに乗り換える事にした。先にも書いたとおりで、Linux5以降は、デフォルトではHDMI-VGAアダプタをサポートできる設定になっていない。xrandrを使ってデフォルト周波数を変更する、と言う対策がarmbian.comにも掲載されているけど、インストール都度はやってられない(覚えてられない)。もちろん新たなblogネタには良いのだけど…。
試して無いので、多分、という参考記事を、念のため（備忘のため）記録。

https://forum.armbian.com/topic/18881-fix-black-screen-blinking-flickering-with-hdmi-vga-adapter/

ということで、HDMI-VGAアダプタを使わなくて済むよう、HDMIディスプレイを調達することになる、ので、とにかく安かったのを調達。15.6"で1280x800対応、ということになっているけど、ディスプレイしてみるとさらに上の解像度、1080P以外はうまく同期してくれない。まぁ、それはそれで良いので、armbian21.08.1、これが多分このボードをサポートしている最終版、をセットアップ。

 そして新たな問題…。

インストール時点では問題なさそうなのだけども、upgradeしてセキュリティパッチなど導入したあと rebootすると、bullseyeでもfocalでも、ブートしてくれない。正確に言うと、u-bootの過程、/scripts/local-blockのところで、UUIDで指定されているHDDパーティションが見えない、として、initramfsのCUIに落ちる。

USB3.0な外付けHDDを使って起動しており、少なくとも、イメージをetcherで書き込みインストール終わるまでは問題なく、そのままならrebootもokだったのだけども、upgradeしてしまうと止まる。

う〜ん、と悩みつつ、USB3 HDDをUSB2ポートにつなぐと動く(起動する)。

USB2 HDDでUSB2ポートで起動し、USB3ポートにUSB3 HDDをつなぐと全体が止まる。抜いても復旧しない。

USB3ポートにUSB2 HDDをつなぐ場合は問題ない。ってことは、USB3ポートもUSB2として使う分には問題ない。

 これって、なにかモジュールが足りてないんじゃないの?と思ったのだけども、起動後ロードされているドライバを見たとき、initramfsに抜けていた可能性があるのはuasだけ、しかしそれをinitramfs -uして再起動しても状況は変わらない。

ということは、Linux5.15.25の時点では、rock64のUSB3はチャンとはサポートされてない、と言うことなんだね、と、割りきることとして(あぁ、ayufan様…)、USB2 HDDをUSB3ポートにつないでセットアップ続行、して、ようやくarmbian21.08.1が動き出し、諸般の再設定を行って、ここに至っております。

rock64日本語環境短縮メモ

 このボードもeolになって久しく、その前に、なるべくkernel新しくしておきたいなと思っていたのだけども。
Armbianは21.いくつか、これには5.15とか16とかあるものの、これらのカーネルはCUIでは問題ないのだけどGUIでは、HDMI-VGAアダプタを使っていると古いモニタで表示できない周波数が使われる問題がある。Raspi系では対応されているみたいだけどarmbianではできてない。そういうわけで、ayufanに頼ることになるのだけども、こちらももう更新されておらず、かつpre-releaseの0.11系はbootできず、私が使える環境下では0.10.12が最終、ということのようだ。

で、いつも感謝絶えないayufanはEUの方なので、当然日本語環境にはなっておらず、セットアップ後、私が使いたいのはfcitxなのにっ！という苦難がなぜかいつも待っている。なお、gnomeじゃなくて、focal & xfce4をいつも使ってます。

とにかくインストールするもの：

  fcitxとfcitx-mozcかfcitx-anthy、mozcでもanthyでもどっちでも良いけど歴史的経緯でうちにはanthyだけな物が多い。これに、fcitx-frontend-gtk2とgtk3を追加すれば大抵使えるようになっているように思うのだけども、実は0.10.12をクリーン状態でセットアップしたのはこれが初めてで、これだけではちゃんと動いてくれずに一日悩む結果に。

そもそも、xfce4では、そのままではログイン時にfcitx自体立ち上がってくれないので、fcitx-autostartをどこかですることになるんだが、それやってもコントローラ?(入力モード切り替えとか表示とかしてくれてる奴)が立ち上がってくれない。

fcitx-diagnoseしながら追加したのはつぎのパッケージ。

libgtk-3-bin、これだけじゃなくてgtk-query-immodules-3-0と2-0をマニュアルで/usr/bin/にsymlink。
fcitx-ui-classic

ここまでインストールして使えるようになったようだ。たぶん、fcitx-ui-classicがキーなんかな？と云うところまでは確認してない。

これでとりあえずは5.6.0…。このカーネルではgpuも効いてないようだし、HDMIなモニタにするべきか、それともボードを替えるべきか、悩む今日この頃。

dvdstyler

 以前拾ってあったdvdstylerをbionicでbuild。Prebuild配ってるところがあるけど、動かないので。 あんまり細かく記録してないけど。

dvdstyler - 3.1.2　（今見たら、古かったね。）

これをbuildするにはwxWidgetsとwxsvgが必要。

wxWidgetsは最初3.0.5でチャレンジしてたけど結局dvdstylerのbuildには当時至ってない。何でだっけ？

今回もそこから始めたけど途中悩んでいるうちに、新しい物があることがわかったので、改めてgitから新しいものを拾ってきてbuild。cloneしただけだといくつかsubmoduleが足らず。次のものを追加。

3rdparty/pcre, catch, nanosvg

src/jpeg, tiff

configure、make終了するのでwxsvg(1.5.22)をconfigure、make。これも問題なく終了。いずれもmake install。

で、dvdstylerにいってconfigure、make。しかし、libwx_gtk2u_mediaがないと怒られるので、wxWidgetsに戻って、--enable-mediactrlつけて改めてconfigureしてmake。gstreamer1.0のplugins-badが必要。

これで動くものを作れた。

ただ、windowsのprebuildだと、タイトル選択メニューで画像を表示できるんだけど以上の手順で作ったものでは"Failed to load image from file ***"(***は書き込み対象のファイル)と言われてしまう。

実際にまだ書き込みは行ってないので、作られたdvdがどうなるのかわからんけど、たぶん、まだどこかにスイッチが足らないんだと思う。しかし、あんまりそんな所に触れてる記事ってないんだよね…。

 

で、使い勝手は良いのか?　うーん、よく分かりません。 

DVD容量に対して最低ビットレートを指定しているはずで、書き込みイメージファイルを追加する時には「それを割らない」と判断しているようなのに、実際に書き込みしようとすると「収まんないからビットレート下げるか書き込みデータ減らせ」と言われてしまう。よく分からない。

 

GPU

仕事の都合上で触ることはあれど、それにあんまりディープに関わることは無いかな〜と思っていたものの、やはり画像を扱う「ブツ」を取り扱っている以上、そこから逃げているわけにもいかず…。

ということで、仕事で扱っているメーカーが、画像認識用のリファレンスデザインをできれば販売したいと考えているとのことで、そのリファレンスデザイン(以下単に「アプリ」)のセットアップを行う必要が出ました。

いっちばん最初はもう2年くらい前で、その時は、メーカー自身がセットアップしたラップトップPC(正確には、ゲーミングノートPC、と言うカテゴリ）を使っていたのだけども、「アプリの次世代ができてるんで、そっちでセットアップしてデモに使ってね」、とメーカーは言う…。

ラップトップPC

　ubuntuにCUDAその他認識で使用するツール一式、何分2年以上前のセットアップなので、ubuntu自体xenialだしcudaも8なので、そこからupdate必要、ということで、まずubuntuはbionicにupgradeで問題なく終わった!と思って再起動してその先に進めていると、何かのはずみにoopsを起こす。

おや???と思っているうちに立ち上がらなくなってしまいました。

このoops、単にプロセスがクラッシュしている旨のメッセージでしかなく、再起動しているうちに、起動できるときとできないときに遭遇することに。

起動できればoops起こさない限り使えてるし、これって、なんかのはずみにsleep状態から抜け出せなくなってんでない?と思ったのが問題解決から遠のく運の尽き。

3週間ほど、もしかしてストレージ(SSD)が壊れた?壊れてない?と、M.2 SSDを着脱、2.5"HDDいれてみたりメモリ全部抜き差しするなどの試行錯誤。

そして、最後の最後に突き止めたのは、8G×2 SODIMMのうち一枚がお亡くなり（なりかけている）、ということ。

メモリって、2枚組ではいっていると、あんまり、一枚ずつさしてみてどうか?って、見ないって事無いですか?

そいつを外してようやく進捗…。

なお、このラップトップにはGTX1080が搭載されています。

CUDA

　現時点で最新のCUDAは11.5だと思いますが、このアプリが要求するのは10.2。これは逆に、他に、そのソフトウエアセットアップを検討しているプラットホームの観点ではbetterな話だと思ったので、10.2インストールに勤しむことに。

しかし、このアプリでは、微妙に古いnvidia-driverが推奨となっており、CUDA vs. nvidia-driverのセットアップに悩むことに。推奨バージョンのnvidia-driverはパッケージとして存在しておらず。もしかして、CUDAはソースからbuildするの???

デスクトップPC

　デモセットアップって、常に私が使えるわけではないので、何か聞かれたときに、同一のアプリをインストールしている類似環境が存在していないと質問に答えられなくなってしまう。

そのため、社内で余剰になっていたデスクトップPCを一台譲り受ける。

当然、そんな業務用のデスクトップにはチップセット内蔵GPUが使われていて、nVidiaのGPUなんて搭載されてない。

ということで、GPU調達をすることになるわけですが、当然「お高い」ので、可能な限りローコスト、とにかく動かせること、レベルをターゲットにして、まずGT1030で、何が起こるかお試しすることに。

GT1030

　こいつはCUDAサポートのリストには無い、ということは知っててあえて試した状況。GDDRメモリバス幅が狭いので、そもそもパフォーマンスは期待できない、とは思ってました。

で。

このボード調達前に、デスクトップにはbionicのセットアップは終わらせてあったので、そこにこのボードを追加、CUDAインストールから試すんですが、この時点で、「あること」を知らずにおり、アプリ推奨に近い版のnvidia-driverインストール後再起動すると、GUIが立ち上がらない、persistencedが動作しない、結果としてCUDAを利用できない、スケジュールも厳しい、という焦りに負けて、3日でgive up、CUDAサポートリストにあるGPUを調達することに。

GTX1650

　土曜に秋葉原に出かけ、GTX1050tiとGTX1650、どちらを選ぶか、1050tiの方が安いなー、ラップトップは1080だから同じ世代だしなー、ではあったんですが、設計古いことから消費電力とコア数で、GTX1650を選定。

「あること」をちゃんとわかってなかったのだけど、週明けにnvidia-driverの比較的新しい版をインストールした状態で、GT1030を試していた時点で残してあったCUDA10.2の組み合わせで、今から思えば不幸にも動いてしまったため、その先に進めることに。

いよいよアプリインストール

　このアプリは2つのアプリで構成されていて、一つ目のアプリが動作した上で、二つ目のアプリをセットアップすることができる。

一つ目のアプリでは、GTX1650で動いてしまった関係で、ラップトップに戻ってセットアップ…すると、動かねー。

ラップトップとデスクトップのセットアップの違いは、GPUの違いに基づくnvidia-driverの違い。つまり、そこで何か間違えたことをやってる、ということ…。

「あること」

　それって、GPUガンガン回すゲームとかAIとかやってる人にはおそらく常識、「nouveauは使わない」、です…。それでラップトップを設定し直し、二つのアプリ、両方とも、デモ可能な状態にできました、まだ調整は必要だけど。

デスクトップの方は、CUDAを使用する他の利用目的もあることと、パッケージをマニュアルで足したり消したり様々試したため、再インストールの予定です。

行き先のなくなったGT1030は…

　過剰になった部品を経費で落とすわけにはいかないこともあり、中古にだすのも気が引けて、引き取ることにしました。

で。以上、確立したインストール手法をもとに今現在、E450でCUDAサンプルをbuild中。動かせるじゃーん、ということで、しかし一方、元々CPUが非力すぎるため恩恵もあまりなく、もしかすると、AI関係のスタディにもっとも寄与してくれる存在になるかもしれません。

Jetson nano、結構安いんで一つ買っても良いかなーとは思ってたんですが、GT1030の方がGPU世代が新しいこともあり(nanoは5.3、1030は6.1)、まー、それもありかな〜、と言うところです。

…、それにしてもGPU高い。ラップトップの価格を考えると、グラボとしてGPU調達するより、ゲーミングノートを買った方が多分効率よいよね…。

BL190HW、いい加減にしてくれ…

 最近、突然宅内ネットから『外』が見えなくなる。在宅勤務中に起こるととっても困る…。

なんでなのか結構しばらく悩んでたんだけど、BL190HWを再起動すると正常になる。で、設定をざっと確認してみると、異常時IPv4 DNSサーバー欄が空欄になっている。こいつが問題。

再起動から最短数時間は問題ない一方で、こいつはログをとれないことから、外側のDHCPサーバーからアドレス更新されたから、とか、そういう確認は全くできない。何せ突然DNSサーバー欄が空白になる。

auのサービスに連絡したところで、お決まりの、『WAN側サーバーに異常ログは無い』『電源入れ直せ』『初期化しろ』、挙句には『見に行く』『交換する』というお決まりのルートになる(今回はとりあえず『初期化しろ』で踏みとどまった）。auは原因究明するつもりがあるのかどうか?　そんなことを電話で言ったところで、電話受けてるコールセンターさんが困るだけでらちが開かない。

これ、うちだけなら確かに個体の問題かもしれないけど、どうやらそうではない。『BL190HW DNS 空欄』あたりで調べると、やはり他にもお困りの方がいる。

とりあえず、あんまり引っかかってほしくない一台だけ8.8.8.8を見てもらって、その他はdnscacheを立てて、そちらを参照するようdhcpを変更しようと思う…。dnscacheなんて、だいぶ長いこと使ってないや。

GY-521

 　春頃に使ったGY-521、amazonでまとめて5個買いだったこともありまだ残っています。ちょっと思いついたコトがあって、新しいものを開封して、試験的に動かしてみました。

前回は、あんまり深く考えずにi2cをそのままパタパタさせてたんですが、今回はその目的のライブラリを使うに際しi2cまわりも一緒に存在しているので、ライブラリ付属のコードをそのまま頂いて動かして見ようとしてたんですが、うんともすんとも言わない。

元のコードが例によってmbed2用なので、、mbed6用に書き換えたりしてはいますが、基本線は変わらないわけで、調べてみるとwhoamiで引っかかってる。デバイスの応答は、0x68じゃなくて0x98。こんな中途半端なビット化け?と思って調べて見つつ、改めてしげしげモジュール眺めてみると、デバイスにはMPU6050Aと刻印されている。ふーんと思ってinvensense/TDK調べてみるとそんなデバイスは出てない様子。

参照：https://forum.arduino.cc/t/mpu-6050-a-module-problems-who-am-i-reports-0x98-not-0x68-as-it-should-fake-mpu-6050/861956

Amazonにある写真では、MPU6050になってるんだけどね…。

春に使ったときも、whoami最初は見たような記憶があるんだけど、あんまり気にせずだったと思います。今回はこれに磁気センサを追加してAHRSとして動かすことも考えてたんですけどね…。はてさて。