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までしか供給できないこともあり、小規模なボードじゃないと、挙動不審にすぐに陥りますんで。