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での対処を忘れちゃうと起動できなくなってしまいますね。注意しておかいと。