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でやってるレコーダーを移すほうが優先度は高いかもしれない。