lcc-win64（lccがまだ生きていたというのがおどろきなんだけど）でgetopt()を使う場合、<unistd.h>ではだめで<getopt.h>をincludeしないと駄目なんですね。

GNU拡張のgetopt_なんとか()を使う場合は<getopt.h>が要るということなので、別に<getopt.h>を使っても差し支えはないみたいなんだけど普通にgetopt()を使う場合は<unistd.h>で足りるようなことがmanに書いてあるからできれば余計なヘッダファイルはincludeしたくないお…

最近の高機能な端末エミュレータ、ssh -Y等で飛ばすことはあまり考えてなさげな気がする。

ん－、void linuxにweztermのパッケージはあるんだけど、
21:42:24.006 ERROR wezterm_gui > running message loop: process_queued_xcb: X11 connection is broken: xcb protocol error: X(Request(RequestError { response_type: 0, error_code: 1, sequence: 235, bad_value: 4194800, minor_opcode: 1, major_opcode: 155, pad: 1 }), Some("dri2::Connect")); terminating
21:42:24.006 ERROR wezterm_toast_notification::dbus > while showing notification: I/O error: No such file or directory (os error 2)
で起動しない…

https://www.youtube.com/watch?v=EkooRqgV0wA こんな時間でもレースやってるのか…（スーパー耐久、24時間レースだから当然か）

There are Several ports:

yaft for framebuffer console
Linux console
FreeBSD console
NetBSD/OpenBSD wscons (experimental)

な ん で す と

yaftはvt102（vt100を少し改良したもの？）互換なのでステータス行表示は無さそう。 https://github.com/uobikiemukot/yaft

kmsconは期待できるのかなあ。vt220からvt510までの完全な実装を謳っているのであれば。 https://wiki.archlinux.jp/index.php/KMSCON

このアカウントは、notestockで公開設定になっていません。

contourを動かせるようにする、というのが途方もない労力がかかるけど現実的な解にならないか…？（それともktermを引っ張り出すのか）

uaa@framboise:~$ infocmp -C fbterm|egrep -e hs -e hs
uaa@framboise:~$ infocmp -C jfbterm|egrep -e hs -e hs
:am:eo:es:hs:mi:ms:xn:xo:\
uaa@framboise:~$

はい終了…

jfbterm、osdn.net上にあるから日本のosdnのゴタゴタの影響は受けてはいないようではある。 https://osdn.net/projects/jfbterm/

とはいえ、コードのリリースは20年前から止まってるし、日本じゃないけどosdn上だからなあ…fbtermがUTF-8に対応してステータス行表示に対応してるならそれで良くね？って気がしなくもない。

jfbtermが終了時にフリーズ (2022/05/14)
https://forums.raspberrypi.com/viewtopic.php?t=334474

jfbtermに何か問題があるってことまでは分かった。

「jfbtermは終了するとコンソールが動作しなくなるバグがあるようですが、fbtermにはありません。」

コンソールで日本語入力 (2020/04/02) https://blog.goo.ne.jp/lm324/e/57d71e72919ca63167eb109466fec5fb

そういうもんなん？そしてなぜ起こる…？

kon|kon2|Kanji ON Linux console:\
:am:cc:eo:es:hs:mi:ms:ut:xn:xo:\
(snip)
:vi=\E[?25l:tc=ansi+enq:

# release: 0.4.7 2005/05
#
jfbterm|japanese framebuffer terminal:\
:ac=++,,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~:\
:me=\E[0m:tc=kon:

…もしかしてjfbtermってkon同様にステータス行表示ができる？

Terminal curses Terminalの基礎とRuby、そしてcursesについて - Part1 https://logmi.jp/tech/articles/321318 (2019/04/18)

やっぱ「詳解UNIXプログラミング」をきちんと読め、ということらしい（手元にあるなら、尚更）。

https://www.cnblogs.com/aozhejin/p/17253982.html
ここにあるterminal emulator～userland(zsh, htop, vim)の相関図を理解できてないとsj3のコードは理解できぬわという話なのかなあ。

SJ_write()はslave側から来たものをPTY masterに出力する。
SJ_print()はsj3の動作自体に関わるメッセージをterminal emulatorに出力する。

termcapによるカーソル位置やらステータス行表示の絡みもあるのでPTY masterへの出力と、そうでないものに分けられている…という理解で良いんだろう。

とはいえ、PTY masterへの書き込みとprintf()との違いとは何なんだろうかと悩んでしまう。もう少し調べないといけないようなんだけど。

荒らしというか今は粘着・監視…？

でもMango Pi MQ-Quad、折角Allwinner H618（H616のキャッシュ増強版）積んでてもRAMが16bit幅だと…Orange Pi Zero2に負けちゃうんじゃないかなあ。こっちは32bit幅だし。

arch/arm/mach-sunxi/dram_sun50i_h616.c、mctl_core_init()←mctl_ctrl_init()←mctl_phy_init()←mctl_phy_{write_leveling,read_calibration,read_training,write_training}()…キャリブレーションだのトレーニングだのに失敗するような何かが起こってる、ように見えるんだけどなぜ失敗するかというのは正直追いたくない領域だな。胃痛がするレベル。

Mango Pi MQ-Quad、Elpida EDJ8416E6MB(512Mword×16bit)が1個ついてるだけ。このDDR3はRow address A0～A14, Column address A0～9。

その一方で、Orange Pi Zero2はSEC K4B4G1646E-BYMA×2。このDDR3は256Mword×16bitで動かすから、やっぱりRow address A0～A14, Column address A0～9。

Allwinner H616→H618に修正してます

おそらくあっちの流儀だと、boot0はboot0で、ATF抜きでもU-bootを動かすとかそういうことをしてる感じに見えるんだが…

Mango Pi MQ-Quad (Allwinner H618)、currentなU-bootだとなんか動く。とはいえ、リセットの繰り返しだけど…

U-Boot SPL 2023.07-rc2-00170-g62df7a3944 (May 25 2023 - 20:06:49 +0900)
DRAM:This DRAM setup is currently not supported.

resetting ...

U-Boot SPL 2023.07-rc2-00170-g62df7a3944 (May 25 2023 - 20:06:49 +0900)
DRAM:This DRAM setup is currently not supported.

resetting ...

なんかさらっととんでもないvariantを作られてませんかね
sunxi: arm64: boot0.h: runtime check for RVBAR address
https://github.com/u-boot/u-boot/commit/0a137ac5015933bf38ea2700abe70602ef63bbdd