Manjaro ARMのRPi5 kernel

Raspberry Pi 5 Model B (RPi5)の評価はその後も続けています.テストしているのはRaspberry Pi OS (RPiOS), Manjaro ARM(64bit), Slackware ARM64 (Slackware-current)の3OSで,そのうちのRPiOSとSlackware ARM64はRPi5を入手した2024年初時点でRPi5をサポートしてました

Manjaro ARM64は一番使いたかったOSでしたが,当時は公式にRPi5をサポートしておらずどうしたものかとヤホーで検索したところRPiOSのKernelとモジュールなどを使えばよいと知りその状態で動かしてきました

その後4か月も経つので正式Kernelもあるだろうと,PacmanのGUIフロントエンドであるAdd/Remove Softwareの検索窓に “rpi5” と入れて検索したら,Kernelなどがあることが解り,早速インストールしました.

ネットで調べたところ本年3月には公式Kernelがあったようです.まあ,Manjaro ARM64がRPi5で動かせていたので今更どうでもいいですが😅

今後,ないとは思いますが,RPi4で使うことも考えて,RPi4用のKernelなども残しました.削除するのは簡単ですし.

今までのところ,RPi5上でRPiOSとManjaro ARM64は十分使える感じです.

Slackware ARM64に関しては,Slackware-currentであるため,ほとんど毎日のようにいくつものupdateが来て,サーバーがあまり強力でないこともあって,その度にupgradeにものすごく時間がかかります.その事もあっておよそ使いやすいとは言えません.

現在の “結論” 的には,Slackware ARM64の15.1 (次期公式リリース)が出るのを待って,RPi5にインストールして,次期サーバーに仕立てます.

Slackware ARM64は,SARPi5により.
本当はGoogleです.
slackpkg upgrade-allをかけたまま就寝することが多いです.
現在使用している8GB RAMのものか新規に購入するかは未定.

Manjaro AMD64 ぶっ壊す

Workstation (WS)をぶっ壊すのは日常茶飯事ですが,これまであまり壊すことのなかったManjaro AMD64 (x86_64)をぶっ壊しました.

先日Manjaro AMD64がKDE Plasma Desktop 6にupgradeされて喜んだのですが,どうもzramがぶっ壊れているのに気が付きました.

色々調べて,systemd-swapが機能していないことがわかりました.systemctl statusで見ると,sysv_ipcがインポートできないことがわかりました.

更に調べると,このsystemd-swapはout-of-dateとなっていることがわかりました😥

それで,Archlinuxのzramのドキュメントを読みながら色々やっていたのですが,どれをやってもうまく行かず,挙句にはEFIをぶっ壊して起動しなくなってしまいました.

EFIがぶっ壊れてはサブWSであるSlackware64もブートできず,にっちもさっちも行かない状況に陥りました.

まずは,Slackware64のブート用USBメモリーから起動して,Slackware64のEFIとGRUBを直して起動するようになりました.ここまでは大した手間ではありませんでした.

このあと,Manjaroのパーティションに4月のバックアップをrsyncでコピーしましまたがうまくブートしません.libvirdがどうのこうのいう,本質的には関係ないエラーなんですが,そのエラーの先に進んでくれません.念の為,Manjaroのパーティションをformatしてからrsyncしましたが,同じ結果でした.

しかたないので,libvirtdを起動しないようにしてある仮想マシンのイメージからrsyncをかけたら,ようやくブートしました.

どうも,rsyncで差分をバックアップしたものからの復元はこのManjaro AMD64に限ってはうまくいかないようです.もちろんあるサブディレクトリー以下とか,特定のファイルについては簡単に復元できるのでバックアップを取る意義はありますが,まるまる起動可能なバックアップとして今までより頻繁に仮想マシンの仮想ディスクにクローニングすることにします.

まともに動くところまでロールバックしたところで,systemd-swapを消して,もう一度,Archlinuxのzramのドキュメントを読みながらやり直します.

udevルールによる方法

結局うまく行ったのは,Archlinuxのドキュメントのうち,udevルールを使う方法です.手順としては,

  1. これまで使っていたZramのサービスが起動しないようにする
  2. /lib/mdoules-load.d/zram.conf に, zram の一行のみ書く
  3. /lib/modprobe.d/zram.confに, options zram num_devices=8 の一行のみ書く
  4. /etc/udev/rules.d/99-zram.rules に,
    KERNEL=="zram[0-7]", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{comp_algorithm}="lz4", ATTR{disksize}="1024M", RUN+="/sbin/mkswap $env{DEVNAME}"
    の一行のみを書く
  5. /etc/fstabに,
    /dev/zram0 none swap defaults,pri=100 0 0
    /dev/zram1 none swap defaults,pri=100 0 0
    /dev/zram2 none swap defaults,pri=100 0 0
    /dev/zram3 none swap defaults,pri=100 0 0
    /dev/zram4 none swap defaults,pri=100 0 0
    /dev/zram5 none swap defaults,pri=100 0 0
    /dev/zram6 none swap defaults,pri=100 0 0
    /dev/zram7 none swap defaults,pri=100 0 0

    を書く
  6. 祈りながらリブート

だったと思います😥

1のあとの再起動で,zramモジュールがロードされていないことを確認,3の後の再起動でzramモジュールがロードされ,4のあとの再起動で/dev/zram0〜7ができていることをそれぞれ確認,など途中要所要所で動作確認をすると着実に進められます.

以上,未来の自分あてのメモでした.

厳密には,メインWSはMac miniで,Manjaro AMD64がサブWS,Slackware64の実マシンはサブサブWS,またはサブWSのサブOSです.
かんたんに書いてありますが,rsyncののち,chrootして,efibootmgrやgrubのツールを使って起動するように呪いをかけます.

DOSEmuメモ (2) NFS

割とあっさりできました.ここを参考にしました.

デーモンの立ち上げは,Slackware64 15.0ではこんな順番でした

/etc/rc.d/rc.rpc start
/etc/rc.d/rc.nfsd start

唯一引っかかったのは,サーバーへ接続しようとしたクライアントのポート番号が大きすぎたため,最初の設定ではマウントできなかったことです.

これは,VMWareのクライアントであるSlackware64が,ホストであるMac miniのNAT経由でサーバーにつなごうとしたためだと思います.そこで,ホストの/etc/exportsに “insecure” オプションを追加しました.

nfsでマウントさせるディレクトリー    MacminiのIPv4アドレス(insecure,rw)

これで,マウントしたサーバーのディレクトリーをdosemuのD:ドライブにして,dosemuから読み出せることを確認しました(書き込みはまだやってませんが😅).

Linuxマシンの間ではUser IDを統一しているので,そのへんの問題も生じませんでした.

rc.rpcとrc.nfsdを実行可能に変更したので,次のサーバーのブート時には自動的に起動するはずです.

DOSEmuメモ (1)

これまでの経緯をざっとまとめますと,Windowsへの依存なくDOSアプリを動かすために,FreeDOS/V + 鳳(単漢変換FEP)の動く環境をいろいろ試してきました.

その結果VMWare FusionBochsではFreeDOS/V + 鳳はブートして日本語フォントがロードされ,プロンプトまで出ますがその後エラーになって使えません.

QEMU/KVMではプロンプトが出ても安定ですが,Control+Spaceで単漢変換モードになりません.

Manjaro AMD64のもとで動くQEMU/KVMで,FreeDOS/V + 鳳をインストールしたHDDイメージからブートして日本語モードとなり安定であるが,CNTL+Spaceを押しても漢字入力モードにならない.

結局昔から動いていたDOSEmu以外はNGです.DOSEmuは素晴らしいですがCPUのエミュレーションはしてくれません.また,macOS + MacPortsではbuildできないので,現在までに確認したDOSEmu + FreeDOS/V + 鳳を動かせる環境は,

です.なぜ同じVMWare FusionでFreeDOS/V + 鳳を直接動かすことはできないのに,VMWare Fusion上のSlackware64の上のDOSEmuで動くのかは不明です.

また,まだ試していませんが,

  • x86_64の実機で動くManjaroのQEMU/KVMのもとで動くSlackware64の中のDOSEmu

でFreedos/V + 鳳が動く可能性はあります.しかし,Manjaro AMD64でDOSEmuが動きますから,これはあまり意味がないです.

いずれにしてもCPUのエミュレーション機能がないDOSEmuということで,Raspberry Pi 4/5 Model Bでの作動はあきらめざるを得ません.

仮想マシンを動かしてその中でエミュレーターを動かすというのは,今ひとつスマートさに欠けますが,動かないのでは話しにならないのでしょうがないです.

Linux上のDOSEmuで行くとなると話は単純で,アマチュア無線のログのオリジナルを保存しているRaspberry PiのサーバーのディレクトリーをDOSEmuのホストのLinuxのファイルシステムのどこかに何らかの形でマウントすればいい,ということになります.

とりあえずはNFSでやってみますが,もう何年もいじってないのでどうなるかはわかりません.動くところまでたどり着くのは紆余曲折あって構いませんが,動き出したら安定して動くことが重要です.

特にmacOS下では.

電波時計校正に疑似JJY

わが家は鉄骨ラーメン構造で,屋根にも外壁にも鋼板が使われているので,屋内の電波環境はよくありません.いまではAMやFMをラジオの内蔵アンテナやロッドアンテナで聞くようなことはないのですが,昔もよく聞こえなかったと記憶しています.

電波時計の校正に使われる40kHzおよび60kHzのJJYも場所によって受信できたりできなかったりです.

特にシャックのメインの時計は定位置では全く校正ができず,放って置くとどんどん時間が進みます.一度無線クラブのオンエアミーティングで呼び出したとき,1分くらいフライングしてしまい,メンバーに少し早いんじゃないといわれたことがあります.実害といえばそのくらいなんですが,合っていない電波時計ってその存在意義が問われます.

電波時計.JJYと同期していると液晶の右上の角に同期のマークが表示される.

それで,週に一度くらい窓辺に置いて同期しますが,1か月くらい忘れることもしばしばですし,夏場の窓辺は高温になるのであまり時計に良くないです.

最近SNSのお仲間がM5ATOM Liteと専用基板を組み合わせた疑似JJY発信機を紹介してくださったので,早速真似しました.どちらもスイッチサイエンスから買えます.

ハードウェアは特に組み立てるというレベルの話ではなく,ピンヘッダーを合わせて差し込むだけです.

ソフトは結構手こずりました.Arduinoはかなり昔に少しいじりましたが,すっかりご無沙汰です.最初macOS用のArduino IDEをダウンロードして,ドライバーが要るとか要らないとか言うのでM5StackのサイトからCP210x用のドライバーをダウンロードしましたがどうもこれは違うようです.

次に一番得意なSlackware64に移り,どうもCP-210xでなく,FTDIのドライバーと当たりをつけ,とりあえずUSBポートにM5ATOM Liteを差し込むとKernel moduleがロードされUSBポートとして見えました.

ここまではそれほど時間はかかりませんでしたが,ここから先が長くて,シリアルポートは認識されましたが,なかなかボードが認識できません.というか,ボードのリストにM5Stackのシリーズが表示されません.あっちのPC,こっちのOSと移りいろいろためしました.

これは結局,ボードマネージャーにesp32を追加する必要がありました.ようやくそれがわかって最終的にmacOSでSketchを書き込み,動作させることができました

昨夜仕掛けて朝の段階で,電波を受信して同期しているマークが表示されています.

無事,JJYと同期しているマークが表示されている.

余談ですが,あっちのPCこっちのOSと移っている間に久しぶりにWindows 10 (32bit)も起動してみました.そしたら,Google Driveがもはや32bitはサポートしていないよと言って,自らをuninstallしてしまいました.また肝心なArduino IDEも32bit版はありませんでした.もう32bit OSは使えないですね.

Linux Kernel driverでは,ftdi_sio.ko.
“M5なんとか” ではないんです😅
Mac miniにはFTDIのUSBシリアルコンバータを2つつないで使っているので,敢えてドライバーの追加は不要ということが試行錯誤の過程で解りました.