19-May-2024、Contour Terminalでのステータス行表示がなんか妙な気がしたので（Vine Linux 2.5の）kterm上でsj3を動かした時のスクリーンショットと比較してみます。
おそらく、ステータス行の表示は反転されるべきなのですが、Contourにおいては反転表示になっていない部分がある…？ように見えます。
sj3に手を入れるにしても、仮想端末を経由するものについてはSJ_write()/SJ_read()で、termcapを絡めて端末を直接操作するものはSJ_print()を使っているようだということは分かったものの…これらを連携させる（SJ_write()側でCtrl-Lを検出したらステータス行を再表示させる）ことができていません。ちゃんと連携できるのであればこの問題は既に解決している、という気もしますけど。58.3kg(21:50)
ESCAPE R3(2015)、リア側のシフターの動きが非常に渋く押し込むと段々右手の親指が痛くなってくるので、ST-EF500-8R2A（だと思う）に交換してもらいました。フロント側はまだ動くので、このまま。
前輪はガラス片を踏んで豪快にパンクさせてしまい、その後チューブを直してはみたものの空気圧を上げると空気が抜けてしまうので、予備用に持ち歩いていたチューブをそのまま使い続けることにしました。修理の腕が落ちた覚えは無いのですが…老化への一直線をたどっているのは確かですので、自分が気付かないうちに腕が落ちているのかもしれません。ゴムパッチかゴムセメントが劣化していたという可能性もありそうですけど。
予備のチューブに代わるものも一応調達して、これで一安心…？
♪
うっかり偽MSX1の基板セットを買ってしまい、老後にのんびりと組もうかねと思っていたらZ80(Z84C00)がEOLになってしまいました。慌てて若松通商に発注したLH0080A, μPD8255AC-5, TMS9918ANLは到着したものの、YM2149もしくはAY-3-8910の入手は厄介そうだなと。
AliExpressを覗けば確かにYM2149にせよAY-3-8910にせよ、そういう型番の何かは入手できそうです。しかし、本物かどうかは分からないというモヤモヤを抱えることになります。ここはWikipediaの「The Winbond WF19054, JFC 95101 and the File KC89C72 have the same pinout as the AY-3-8910 and are also 100% software compatible. They're still in production and used on many slot machines.」の記述に従い、一番安価だったJFC 95101を発注することにしました。悪くなさそう、という話もX(Twitter)上にありましたし。
あとはTTLのロジックICだのメモリだのその他細々としたもの色々を揃えて組み立てることになりそうですが…生きているうちに完成できるかどうかは完全に謎です。57.8kg(21:55)
sj3(tty client)、画面下のステータス行をきちんと表示させるにはtermcap(infocmp -C)にhsとesのエントリが必要です。これらが存在しない場合は、起動時や端末エミュレータのウィンドウサイズ変更時にはステータス行が表示されるもののCtrl-L/clearコマンドによる画面消去ではそれが消えてしまうという問題が発生します。mlterm上のスクリーンショット(31-Mar-2024)では問題無く動くように見えますが。
ktermくらいしかhs/esに対応している端末エミュレータはないのかなと思っていたものの、Contour Terminal Emulatorが対応しているようです。とはいえ、このスクリーンショットでは分かりににくいですね。
Contour、sj3の起動時にステータス行への操作許可を求められたり、GitHubのrepoを見るにビルドがなかなか大変そうなので、これと組み合わせて使ってくださいと言うのはちょっと難しそうな気がします。バイナリパッケージを持っているdistroもあまり多くないようですし（今回はVoid Linuxのパッケージで試しています）。
sj3(tty client)はhs/es未対応の端末エミュレータでは使ってくれるなということなのでしょうが（canuumもそんな傾向があります）、今使っているmltermや多くのxterm互換ターミナルエミュレータはステータス行処理(hs/es)には対応していないため、こういったターミナルエミュレータでも快適に使えるようsj3に手を入れる方が現実的な気がします。
とはいえ、どこに手を入れれば良いかは皆目見当がつかないんですけど…57.8kg(22:45)OpenBSD/riscv64がMilk-V Duo(256MB)で起動したとはいえ、src/sys/arch/riscv64/conf/GENERICをいじってsdhc(4)を認識できてもその先には進まない…動くかどうかを知りたければgpio/reset/clock周りをきちんと実装せよということなのですが、結構大変なんですよね。
一旦置いといて、他のことしようかな。57.2kg(22:15)
29-Apr-2024の続き。duo-buildroot-sdkにあるmilkv-duo256m-v1.1.0-2024-0410.img(.zip)を起動してログを取ってみました。折角なので、CONFIG_EFI_LOADER=yにしてビルドしたfip.binを使って、OpenBSD/riscv64を動かした際のログも取ってみました。俺たちの戦いはこれからだ！って感じですね…やるにしても、やらないにしても。
とりあえず、何かで使うかもしれないのでcv1812cp_milkv_duo256m_sd.dtbとそれをテキストにしたものを置いときます（おまけ：cv1800b_milkv_duo_sd.dtbとそのテキスト化）。57.0kg(22:55)
最初に書いておきます。Debian系とRedHat系で全然違うので、検索してたどり着いたページに何が書かれているかをしっかり確認してください。とりあえず、RedHat系の方がお手軽なのでそっちの流儀で説明しますが…mkisofs用の作業用ディレクトリをwork/とすると、その下のディレクトリ構造とファイルの配置をこうします。
work
|-- LiveOS
| `-- squashfs.img
|-- boot
| |-- initrd.img
| `-- vmlinuz
`-- isolinux
|-- isolinux.bin
|-- isolinux.cfg
`-- ldlinux.c32
|
LiveOS/squashfs.imgのディレクトリ名/ファイル名は固定されていること、ldlinux.c32をisolinux/に配置する必要がある点に注意が必要です。また、isolinux.cfgのCDLABELで指定される名称はmkisofs -Vで指定する名称と一致している必要があります（CDLABELの名称については参考にしたブータブルLinuxISOを手作りするでも触れられています）。
でも一番重要なのはvmlinuzとinitrd.imgで、RedHatの流儀で作る以上はRedHat系distroの物を使う必要がある、ということです。これを書いている時点だとCentOS-stream 9にあるものを使うのが早いです（squashfs.img以外はすべてここで揃います）。
ISOイメージの作成は mkisofs -o output.iso -R -J -V linux -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table work で。
NostrでumbrelOSのISOイメージは無いのか、という話があったので挑んでいたのですがなかなかの難問でした。提供されているのがUSBメモリ向けのディスクイメージ、しかもGPT形式のパーティションかつEFI boot専用の物しかないのです。HDDエミュレーションのEl Torito(ISO9660)を作っても起動しようがないので、インストール用データの格納された区画をsquashfsで固めてLiveCDにするしかないかなって。
umbrelOSはDebian系distroではあるんですが、CentOS-streamのvmlinuz+initrdでもインストーラを起動させてVirtualBoxの仮想マシンにインストールするところまではできています。
とはいえ、インストールした後にどうやって使うかがまったく分からないので困っています。あと、VirtualBoxはEFI boot可能なので問題にはなりませんが、EFI bootできないマシンでインストール後にどうやって起動できるようにするかという問題も解決していません。57.7kg(10:55)
07-May-2024補足：vmlinuzとinitrd.imgを拝借したCentOS 9-streamはkernel-5.14.0-437.el9、umbrelOS(Debian-12)はkernel-6.1.0-20を使用しています。カーネルのバージョンが異なるために/usr/lib/modulesにあるカーネルモジュールを使えない以上、initrd.imgに入っているモジュールだけで動いているのでしょうが…インストール用メディアに格納されたファイルをインストール先のディスクに展開する程度ならなんとなく動いていても、それを超えるような用途だと問題が発生しそうな気がします。
それ以前に、EFI boot対応のPCエミュレータならumbrelOSのインストール用USBメモリイメージを（圧縮を解いてから）仮想HDDとして接続してしまえば良いだけなので、ISO化する必要は無いはずです。随分と馬鹿なことをやったもんだ、と今更ながら思っています。
19-May-2024補足：要らない気もするのですが、ISOイメージを作るためのスクリプトを書いてみました。説明の補足として置いときます。
Milk-V Duo(64M)とそんなに変わらない時期に買っていたのですが、これを動かすのはなかなか難しいですね。とりあえずSDKに入っているU-bootだけをmicroSDに入れて動かすのも、一苦労です。
何となく分かった点をまとめると、
とりあえず、build.shで得られた物を書き込んで作ったmicroSDで起動して、こんな感じ。RockPi S(RK3306)向けのディスクイメージの作成ではenv.imgを使っていないのですが、mainlineではなくRockChipが味付けしたU-bootを使っているが故にこうなっているのかもしれません。
OpenBSDをこれで動かすことは…その前にmainline U-bootをRV1103に対応させる方が先という気がしますねえ（できるのか？）。57.5kg(16:50)
05-May-2024補足：./build.sh lunchで設定するボード別の設定はproject/cfg/BoardConfig_IPC/BoardConfig-*.mkに収められており、./build.sh envで作成する区画情報（ということにしておきます）はこのファイルにあるexport RK_PARTITION_CMD_IN_ENVの内容が反映されるようです。
./build.sh ubootでU-bootを作成する際はボードの設定に関わらず、sysdrv/source/uboot/u-boot/configs/rv1106_defconfigを参照しています。これにCONFIG_EFI_LOADER=yを追加してみましたが、他にも色々設定しないとEFI loaderが有効にならないように見えるんですよね…簡単に煮炊きして食えるような代物ではなさそうです。