面白そうなマザーがオークションで出ていたので、衝動買いしてi3-4130も買って組み直してしまったｗ
https://www.mitacmct.com/IndustrialMotherboard_PH10LU_PH10LU
（DDR3、4GB×4枚持っていたけど2枚処分してしまったことを非常に悔いている）
SASANO Takayoshi(@uaa@social.mikutter.hachune.net)の投稿 OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
面白そうなマザーがオークションで出ていたので、衝動買いしてi3-4130も買って組み直してしまったｗ
https://www.mitacmct.com/IndustrialMotherboard_PH10LU_PH10LU
（DDR3、4GB×4枚持っていたけど2枚処分してしまったことを非常に悔いている）
CENTURY LCD-8000U2なるものか。こういうちょっとした目的で、USBでちょいとつなげると映るモニタは欲しいかも（ちょっと衝動買いしたものがあるので飛びつけない）。
https://www.century.co.jp/products/lcd-8000u2.html
鯖の管理も大事だけど、それよりも生活と体調の方がもっと大事なんで無理しないようお願いします…とそっと呟いときます。
おー、今日はメンテの日だった。早々に寝るか…
こんばんは。
s25tの鯖管です。
本日21:00から予定しておりましたメンテナンスについて、管理者の都合により開始時刻を22:00に変更いたします。
よろしくお願いします。
お一人様３台まで！、の表示を見て「お、おぅ…3台以上まとめ買いするのが居るのか」という感想を抱くなど。
（確かに居てもおかしくない気はする）
Owltechが出してたミツミのキーボード、メンブレンだけどあれは良かったですよ。（そしてこれも廃盤…）
元麻布春男の週刊PCホットライン 壊れたAXキーボードの後継を探す～新旧の英語キーボードをテスト (2001/12/19)
https://pc.watch.impress.co.jp/docs/article/20011219/hot179.htm
あの時代でも後継品探しに難儀していたのなら、今となってはもはや諦めた方が良いのだろうなあ。（あるいは自作か？）
個人的に至高のキーボードと言ったらやはりSONY Quarter L付属のAXキーボード。あれは最っ高だった。流石にもう手に入らないけど…どこかでそれに比肩する物に触れられたらいいな。
あー、こういうちっこいキーボード大好き。
自分もBTC 5100C（およびSIIGのOEM版）を好んで使っていたんだけど…手に入らなくなっちゃったので。
http://sakimemo.web.fc2.com/keyboard/btc_5100c.html
（カーソルキーの配置が変態ですが、慣れれば打てますｗ）
このアカウントは、notestockで公開設定になっていません。
良いキーボードの条件…
・そこそこ打てる（神なフィーリングは求めちゃいない）
・安い
・入手しやすい
・英語配列
かなあ。今使ってるDELL KB216、仕事場でこいつの日本語版が結構良かったので英語版を探してみたら偶然某ジャンク屋で\300くらいで出ていたので何個かまとめ買いした。
流石に前職のように2年で一枚潰すような使い方はしないので、叩き潰すよりも放置してることによるストックの劣化を心配した方が良いのかも。
どーもここから先は自作キーボードの沼地があんぐりと口を開けて待っておりますな、ということは分かった。
特集 - 自作キーボードの作り方（QMK Firmware編）https://www.ceressoft.co.jp/special_keyboard_qmk.html
QMK firmware…？
USB HID protocolをおしゃべりする何か、であればだいぶハードルは低そうな気はするけど。Arduino Leonardoみたいなやつとか（これ以上はさっき呟いてるのでばっさり省略）。
そもそもキーボードの自作って、PC向けの101だの106だのと言ったものだとしたら…それだけのスイッチを繋がないといけなくなるけどキーマトリクスどーすんのとかそこから始めないといけないよな。
（I/Oエキスパンダ山盛りにしてそれぞれのキーの状態を拾うみたいな作りのキーボードというのもロマンはあるけど現実的なのかそれ）
CH9329ってなにこれ…片方のマシンではUSB HIDとして認識されて、もう片方のマシンではUARTとして見えるって…
https://akizukidenshi.com/catalog/g/g117539/
https://www.marutsu.co.jp/contents/shop/marutsu/datasheet/minnanolab_MR-CH9329EMU.pdf
Arduino Leonardo辺りでキーボードの真似事ってどの程度現実的なんだろ。
まあUSBのデバイスになって割と扱いやすいって意味ではRPi Picoはアリだと思うけど…Pico Wまでは要らないような。
Raspberry Pi、Picoが随分パワフルなのでNanoとか出ないのかなーとか謎な妄想を（Arduinoとかそっちの領域になるのかね）。
DeviceTree、U-boot由来なのかLinux由来なのかって部分も気を付けないといけないか。同じはず…なんだけどな？
Orange Pi 3を発端にPHYの電源周りのDevice Tree Bindingsをいじろうとする動きはあった…と。 https://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/741625.html
で、emacの配下にあったphy-supplyをrgmii_phyの配下に移すことになったけど…
https://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/741469.html
phy-io-supplyはあまり乗り気ではないけど結局必要だったので入れた。
https://lists.infradead.org/pipermail/linux-arm-kernel/2022-May/741465.html
って経緯で良いのかな。
電源制御のDevice Treeエントリの解釈が増えるのも面倒なので、リセットだけで回避できればいいのだが…
うむー、reg_gmac_2v5、PD6での制御っていうこれは…Orange Pi One Plusだと既にreg_gmac_3v3で定義済。emac{}の中でphy-supplyの他phy-io-supplyを設定してるというのが今までとの違いか。
（今まではreg_gmac_3v3のエントリにreg_aldo2から供給を受けてるという作りになっていたけど、これだとreg_aldo2→reg_gmac_3v3の順に電源が入ってしまうのでよろしくない）
さてと、余計なことで時間食っちゃったので本来のdwxe(4)関係の作業に戻らないと。流石にrebootで再起動後はネットワークが使えない、はひどい。
uaa@emeraude:~$ echo aaa | nc -u 192.168.0.144 1234
framboise# tcpdump -x -i re0 \( src 192.168.0.141 \) and \(udp \)
tcpdump: listening on re0, link-type EN10MB
18:42:24.205551 192.168.0.141.46419 > 192.168.0.144.1234: udp 4 (DF)
4500 0020 e706 4000 4011 d158 c0a8 008d
c0a8 0090 b553 04d2 000c 00d7 6161 610a
0000 0000 0000 0000 0000 0000 0000
えっと、これが答えっぽいですね？
（runt packet除けのpaddingが付いてるだけでは？と考えてるD-STAR関連のプログラム、あれは無線関連とはいえインターネット上にUDPでパケットの送受を行うプログラムなので無線特有の事情については考えなくて良いと思ってます）
非準拠のパケットとやらが0x2e…46byteあるけども、一つ引っかかるのがrunt packet除けのpaddingなんだよね。
Ethernet上では64byte未満のパケットは棄却されるので、適当にパディングして64byteにする必要があるんだけど…Ethernetフレームって送信MAC address(6byte), 受信MAC address(6byte), Ethernet type(2byte)に加えてFCS(4byte)、18byteのデータが追加される。
46+18=64なんだけど、この推測あってますかね？「バッファオーバーフローと呼ばれる典型的なハッキングの手法の一つ」ではなく。
非準拠の例
07:46:45.723745 IP xxx.xxx.xxx.xxx.50100 > xx.x.x.xxx.60005: UDP, length 10
0x0000: 4500 0026 888f 0000 3e11 3032 xxxx xxxx E..&....>.02....
0x0010: xxxx xxxx c3b4 ea65 0012 825a 4453 5452 .......e...ZDSTR
0x0020: 0097 7212 0000 0000 0000 0000 0000 ..r...........
IPv4, IPヘッダ長20byte, サービスタイプ00, protocol UDP(0x11), パケット長38byte, checksum 0x3032, 送信元/送信先(ry, IPヘッダのオプションは無し。
UDP src port 50100, dst port 60005, データ長18byte, checksum 0x825a
確かにIPヘッダのパケット長を越えちゃいる…
生存確認の要求側のパケットの例
07:46:45.668636 IP xx.x.x.xxx.60005 > xxx.xxx.xxx.xxx.50100: UDP, length 10
0x0000: 4500 0026 0fee 4000 4011 66d3 xxxx xxxx E..&..@.@.f.....
0x0010: xxxx xxxx ea65 c3b4 0012 c429 4453 5452 .....e.....)DSTR
0x0020: 0000 7312 0000 ..s...
IPv4, IPヘッダ長20byte, サービスタイプ00, パケット長38byte, protocol UDP(0x11), checksum 0x66d3, 送信元/送信先は秘匿されている, IPヘッダのオプションは無し。
UDP src port 60005, dst port 50100, データ長18byte, checksum 0xc429
…で、いいのかな。
UDPオプションを踏まえた上で、レピータ管理団体及び JARL・D-STAR委員会等が提供しているプログラム以外を接続されているユーザー の皆様へ (2024/02/21) https://blog.goo.ne.jp/jarl_lab2/e/5f2e8b49ad8c06e49bdbbdcc6c533d7b に示されるIPパケットを読み解いてみようか。
「D-STAR 委員会によるユーザーを無視した行動についての申し入れ」に関する 経過のまとめ (2024/2/10) http://xrf673.xreflector-jp.org/info/xchange.pdf
これで知ったのだけど、UDPオプションなるものがあるのか。
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23
これについては UDPにオプション領域を追加する仕様 (2023/07/01) https://asnokaze.hatenablog.com/entry/2023/07/01/030516 を見るのが良さそう。
sysutils/arm-trusted-firmwareのSUNXI_SETUP_REGULATORS=0対応版はcommitしたけど、もしかするとDTS/ドライバの修正で不要になるのかも（とはいえ、U-bootレベルでネットワークを使いたいとなるとこの修正は必要…無駄ではないと思ってる）。
でも20ms要件って結構厳しい気がするんだけど。リアルタイムに無線上のデータを処理するならともかく、インターネット越しにパケットを投げて処理させるのって…
ローカル側ではおそらく200～500ms分くらいのバッファを持っておいて、その時間分だけずらしてネット上に送信するとかそういう作りにするんだろうなあという気はする。受信に関しても多少のバッファリングはするのかなあ（MMDVMHost辺りのコードを見れば良いんだろうけど）。
揚げ足取りしますけど、準拠することを求めるのであれば
「推奨:
音声ヘッダのパケットロスが発生することを考慮して、音声データ 21 回毎に(再同期信号が挿入されている音声 データの
直前に)無線ヘッダを挿入すること。但し、音声データの送信間隔は 20 ミリ秒を維持すること。また、受け取り側で既に無線
ヘッダを受け取っている場合は、以後の無線ヘッダは破棄すること。」
推奨ではなく要求（条件）とでも記すべきでしょうな。推奨は別に満たさなくてもまあそれなりに動く、というニュアンスのはず。
…ゲームのように最低人権ラインを示す「推奨」も確かにありますけどね。でも技術文書における推奨はそこまで強い意味ではない…と自分のプログラマー時代では記憶してるんだけど。この辺の感覚、ここ10～20年でなんか変わったんですかね？
（XではD-STARなんざ関わりたくないと呟いてますけど）ちょっと気になることがあってアマチュア無線のデジタル化技術の標準方式(6.0a)の仕様書見てます。 https://www.jarl.com/d-star/STD6_0a.pdf
今更知ったんですけど、第5章ネットワークの構成条件/5.1有線通信パケット/(1)ゾーンレピータ局のGWから管理サーバへの通信(UDPパケットを使用)って、機器IPアドレス/GW IPアドレス共に4byteのフィールドしかない…IPv4専用なんですね。IPv6への拡張を行うなら、おそらくVerのフィールドを0以外の値にするんでしょうけど、そういう予定があるのかどうか。
NoraExternalConnectorへの現状の補足説明です（一部加筆・修正しました）（1月22日追記） (2023/12/25) https://dstar.seesaa.net/article/501870618.html
「2．応答パケットが20ミリ秒以内に戻ってこない」の記述は仕様書6.0aの48ページ目が根拠ですか。←これを調べてた。
電源投入タイミングがめちゃくちゃでも、リセットだけで回避できるっていうんならそれで回避したいところではあるかなあ。あまり大きく手を入れるというのもどうかなーというの、あるし。
kernel/archive/sunxi-6.7/patches.megous/arm64-dts-allwinner-orange-pi-3-Enable-ethernet.patch
こいつが答えみたい。結局、3.3V系/2.5V系の電源投入タイミングに加え、PD14 resetを入れないとマトモに動かない。
https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.1/patches.megous/arm64-dts-allwinner-orange-pi-3-Enable-ethernet.patch
これを実現するにはDTSに手を加える必要があるし、mdioのreset-gpiosにも対応できるようカーネル（ドライバ側）の対応も必要になる。
お手軽お気軽hackでは済みそうにないぞ、コレ。
Armbianのpatch/u-boot/u-boot-sunxi/board_orangepi3-lts/0001-add-orange-pi-3-lts-support.patch
DTSのレベルで
+&mdio {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+
+ reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+ reset-assert-us = <15000>;
+ reset-deassert-us = <40000>;
+ };
+};
が仕込まれてる。
The reason for gphy not working is this:
INFO: PMIC: aldo2 voltage: 3.300V
ATF is enabling aldo2 which is half of the phy supply, whithout enabling the other half.
When Linux enables the other half later on, it's too late and phy is in a broken state.
ALDO2以外にonとすべきものはなんだろうか…
EPHY-AVDD33,EPHY-DVDD33,VDDREG)←GMAC-3V←VCC3V3-MAC←ALDO2
ALDO2がonのままだと何か困る事情があるんだろうか。
GPIO PD6のレベルと、PD14だよなあ…確認事項。
COSMICってどうなんだろう（ってPop!_OS触ればわかるのか）
Pop!_OS搭載のデスクトップ環境「COSMIC」、まもなく開発版をリリースへ (2024/02/19) https://gihyo.jp/article/2024/02/daily-linux-240219
TDE、名前は聞いてたけどライブラリもそんなことやってるとは（やべーやつだ）…
"TDEはQt3をフォークし、TQt3というライブラリを使用している"
プロジェクト成果物で知られるLinuxディストリビューション 10選 - Chienomi https://chienomi.org/articles/linux/202112-linux-distro-projects.html
HID直打ちキーボード、エレキー用のパドルだともうちょい操作性良くなるのかなあ。 https://mfjenterprises.com/products/mfj-564
冗談でこの手の #HID 電文直打ち #キーボード の話はしていたんですが、本当にやるやつがいたとは
"真正2%キーボードできたｗ
HIDデバイスのUsageIDをバイナリで直打ちするので、0と1しかない。
それでも108キーのフルキー全て打てる。
もちろんメディアキーも打てるので音量アップダウンとか計算機起動とかもできるｗ
よくあるctrl+C, Vとかじゃなく普通の日本語キーボードでは最小なのではｗ"
https://twitter.com/handaru20pF/status/1760642014289510561
勤労感謝の日って、お仕事があることに感謝する日なんでしょ？みんなお仕事お疲れさーんの日じゃなく。 #毒吐き
このアカウントは、notestockで公開設定になっていません。
int axp_check_id(void)
{
int ret;
{
int i;
for (i = 0; i < 0x100; i++) {
if (!(i % 16)) printf("%02x:", i);
printf("%02x ", (unsigned char)axp_read(i));
if (!((i + 1) % 16)) printf("\n");
}
cold bootでAXP805認識直後のレジスタの内容はREG=0/1ともに変わらず（これは当然）。warm boot後はこうなってるね。
REG=1
10:ff 77 1e 07 1e 12 01 1a 1a 1a 00 40 08 fd 00 0f
REG=0
10:7f 13 1e 07 1e 12 01 1a 1a 1a 00 40 08 fd 00 0f
cold boot時は
10:3f 13 1e 07 1e 0f 01 1a 00 00 00 40 08 fd 00 0f
PHYへの電源供給が行われているのかどうか、あとは以前見かけたPHYのアドレスがおかしくなってるか…どっちかな気はするんだけど。
1+Armbianな改造はウォームブートで再起動後にPHYを見失う、crust入れてても。
1(無改造)+crustはコールドブートな時点からPHYを見失ってる。
crust、再起動はしてくれるけどhalt -pで電源が切れなくなる。
----
とりあえず、crustは電源切れなくなるので要らない。
Armbianな改造、もしくはSUNXI_SETUP_REGULATORS=0は必須。
その上で再起動後にPHYを見失う問題に対処が要る。
ということは確かそう。
Armbianな改造と、SUNXI_SETUP_REGULATORS=0のどっちが良いかは別途評価が必要か。個人的にはArmbianな改造の方が良さそうに思える（SUNXI_SETUP_REGULATORS=0だとレギュレータの制御を完全にATFがサボるため、そこまで省略して良いのか…？という疑問がある）。
crustを入れてもSUNXI_SETUP_REGULATORS=0ではダメってことは、1（無改造）ないし1＋Armbianな改造のどっちかなら可能性ありということになんのかねえ。
ArmbianのOrange Pi OnePlus向けの.conf（今は.cscになってる）、CRUSTCONFIG="orangepi_3_lts_defconfig"なので結局patch/crust/add-defconfig-for-orangepi-3-lts.patchの中身…
--- /dev/null
+++ b/configs/orangepi_3_lts_defconfig
@@ -0,0 +1,4 @@
+CONFIG_PLATFORM_H6=y
+CONFIG_CIR=y
+CONFIG_I2C_PINS_PL0_PL1=y
+CONFIG_MFD_AXP20X=y
をそのまま使うってことらしい。
Arc A770、GPUぶん回してる時の方がGPUファンがきちんと制御されて大人しくなるってどーいうことなん…？
Orange Pi OnePlusのcrust-firmwareのコンフィグないじゃんよ、ということで片っ端から https://github.com/crust-firmware/crust/tree/master/configs を見てるんですが…特に大した内容の記述は無いので自分で起こすのも手なのかも（それが正しく動く保証はないが）。
ArmbianのOrange Pi3-LTS向けの設定もこんな感じだし。
https://github.com/armbian/build/blob/main/patch/crust/add-defconfig-for-orangepi-3-lts.patch
うーん、phandleのチェックだけ抜く、というのを#ifdef使った形で作っちゃみたが …結局ウォームブートによる再起動後にPHYを見失う現象は変わんないっすね。
plat/allwinner/common/sunxi_bl31_setup.cでfdtを探しちゃいるけど、得られたアドレスはこの中に囲い込んじゃってるね。検索用のsunxi_find_dtb()についても。
そもそもlibfdtが触れる、fdtへのポインタってやつをどっかから引っ張って来ないといけないんだけど…引っ張って来れるのか、という問題があるような。
OpenBSDの場合、以前
node = OF_finddevice("/");
if (!node)
return;
if (OF_is_compatible(node, "xunlong,orangepi-one-plus")) {
みたいなコードを自分用に書いていたので、こんな感じの機種判別コードをlibfdt使って実装すれば良いんだろうとは思う。どうやるか全然分からんけど。
SETUP_REGULATORSの有無を切り替えるようなMakefileのパッチは投げてはいるけど、撤回してボード名に応じて動きを変えるようなATFにするパッチをこさえた方が良いんだろうか。こういうのは気分的にすごく嫌なんだけど、それでも無いとまともにボードが動かないし…
（まずは作ってみる必要があるかな、実現可能性を探る意味でも）
ていうか、Orange Pi OnePlusとOrange Pi 3って地雷ってことなんじゃ…（今更気づくか）
axp/common.cはここから下がごっそり無効化されるので、SUNXI_SETUP_REGULATORS=0は牛刀持って鶏を…という気がしなくもない。
https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/allwinner/axp/common.c#L52
というか本気でレギュレータの制御を「何もしない」にしてるのがなんとも…（OS側で全部掌握せーよ、ということなんだろうけどOS側が面倒見切れてないという部分もあるのでU-boot他のアシストはあると嬉しいんだよねという甘いことをほざいてみよう）。
コンパイル時のオプションで制御できるからportsで何とかできるのであって、必要な時のみパッチをon/offといった大技(?)までは流石に難しいんじゃないかなあ。
SCPで何かやってると思ったが…どうも違うみたいだ。
ArmbianがATFにパッチを当てて問題を回避してる。
https://github.com/armbian/build/blob/main/patch/atf/atf-sunxi64/board_orangepioneplus/sunxi-Don-t-enable-referenced-regulators.patch
そしてこれはOrangePi OnePlusとOnrange Pi 3でのみ有効になってる。
これなら確かにATFのバージョン縛りは要らないし、SUNXI_SETUP_REGULATORS=0を指定する必要も無い（このパッチによる修正とSUNXI（略）=0での対応は、厳密には同じではないというのも厄介）。
ん－、レギュレータ操作なしのATFを組み込んで、コールドブートした場合のみethernet PHYがちゃんと動く、ってのが厄介だな（rebootでウォームブートするとPHYが見えなくなる）。
多分、SCPにレギュレータ操作を握らせるか何かするとちゃんと動くようになるとかそういう話なんだろうか。Armbianの動作がマトモなので。
SCP抜き、レギュレータの操作はデフォルト（あり）だとこうなるわなあ。
dwxe0 at simplebus0: address 02:07:11:b5:5a:5a
dwxe0: no PHY found!
とはいえ、SCP抜きのせいか時折
NOTICE: BL31: v2.10.2(release):lts-2.10.2
NOTICE: BL31: Built : 05:29:45, Feb 22 2024
NOTICE: BL31: Detected Allwinner H6 SoC (1728)
NOTICE: BL31: Found U-Boot DTB at 0xa0963d8, model: OrangePi One Plus
ERROR: MHU: Unexpected protocol (MHU status: 0x0)
となって起動できないことがある。
今のご時世、big-endianなマシンでかつマトモなOSの走るマシン、状態の良いものがどれだけ残ってるのか…という疑問はある。
ポリタンクなMacの一台くらいは確保したい気分ではあるけど、場所取るしな…（それならpowerpcなMac miniか？）
QEMUでビッグエンディアンな環境をエミュレートとか、ARMのbigendian環境に挑戦とか、方法はありそうな気がする。面倒そうだけど。
このアカウントは、notestockで公開設定になっていません。
Orange Pi One Plus向けのArmbian、何度再起動してもEthernet phyを見失わずに動いてますね…ATFが新しいからなのか、PSCI(crust)対応しているからなのか…
株価が上がろうが、自分の財布に入る金が増えない限り景気が良くなったとは決して言えないのでは？
rootのパスワードを設定せず、ユーザも作らずに再起動したらログインできなくなった…やり直しｗ
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
INFO: BL31: cortex_a53: CPU workaround for 1530924 was applied
SCP/INF: Crust v0.6.10000
INFO: PSCI: Suspend is available via SCPI
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
U-Boot SPL 2024.01-armbian (Feb 10 2024 - 01:35:26 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.9(debug):armbian
NOTICE: BL31: Built : 01:34:56, Feb 10 2024
NOTICE: BL31: Detected Allwinner H6 SoC (1728)
NOTICE: BL31: Found U-Boot DTB at 0xa096b48, model: OrangePi One Plus
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
落としてバイナリダンプしてみtけどATFのバージョン分からないな…microSDに書いて動かせばいいか。
Armbian/Orange Pi One PlusのサポートはCommunity maintained/Unofficial扱いか。 https://www.armbian.com/orange-pi-one-plus/
Orange Pi One Plusはcrust未対応なんじゃなくconfigが無いだけか。かといってconfig書くのめんどいな（書かないと対話式の質問に答えることになるので余計にめんどいんだけど）。
もしかして：Orange Pi OnePlusってcrust firmware未対応 https://github.com/crust-firmware/crust/tree/master/configs
とりあえず、portsのATFを使って野良ビルドしたu-boot-2024.01でOrangePi OnePlusが起動することは確認。まずはATFのSUNXI_SETUP_REGULATORS=1/0でネットワーク周りの動作がどう変わるかを見ることにしよう…というところまでは、進められたか。
今日が休みならもっと進められるんだが…ほんっと、こうやって実行中のタスクコンテキストをイベントに刺されて実行を切られるのって不愉快極まりないんだよね。コンテキストスイッチが重い部類の人間なので、なるったけこういう切り替えは減らしたいというか０にしないとただでさえ低いパフォーマンスが０になるどころかマイナスになる。
昔のarmbian、ATF縛りやってたはずなんだけどmasterブランチ→mainブランチに変わってからはATFしばり止めちゃったんですかね。 https://github.com/armbian/build/tree/master/config/boards
てーかOrange Pi One Plus動かすのってそうとう久しぶりかも。専用の電源ケーブルをどこやったっけー？と散々探し回るくらい（見つからなかったらストックを開けようかと思ったけどそれはしないで済んだ）。
やっと-currentなportsにあるcrust, ATFからOrange Pi One Plus(H6)向けのu-bootを作って、起動用イメージをこさえるところまできた。ここからがテストの本番なので準備に時間かかりまくりってやつなんですが。
（しばらくsj3はおやすみ）
OpenBSD-Allwinner H6/H616絡みの話が少し動いてるので、そっち側の作業中。ARM Trusted Firmwareのバージョンアップの話があったので、Allwinner H6での問題回避の話(SUNXI_SETUP_REGULATORS=0)を入れてもらうようお願いしているところ。
既にこのオプションあり/なしのビルドを作れるようにしてはいるけど、portsの形で綺麗にまとめるのって結構大変…
あ、crust-firmwareのビルド終わってる（or1k-elfなtoolchainもできてる）
crust-firmwareをビルドするためにor1k-elf-gccが要るんだけど…snapshots/packages/amd64にor1k関連のパッケージは無いのでdevel/or1k-elfをビルドすることに。
どうせすぐ終わらないし、今日は寝るのが良さそうだな。
明日お仕事が休みならこの辺の作業をガーっと片づけられるんだけど、当面所属店舗の定休日に仕事が入ってしまっているので（4月以降もこの状態になることが確定っぽい）何も片付かない。
確実にQoLは低下してる。
emulators/dosbox-x: しれっとcommitしてきた
japanese/onew: llvm-16への移行に伴う修正は不要とのことで、patchは破棄
audio/{alsa-lib,alsa-utils,alsa-plugins}: レビュー待ち
sysutils/arm-trusted-firmware: SUNXI_SETUP_REGULATORS=0化したものを作る前に現状のソースを取り寄せ中
japanese/canna: cannastatが動かない問題の修正…絶賛放置中
とりあえず/usr/portsの下の掃除で今日は終わりそう。crust/ATF/u-bootの三つをビルドできること、というのが求められている。
稀に使うんですよね、ish。流石にMAJとか7plus(7+)は使わないんですけど…
…って、7+のパッケージを持ってるのがSlackwareとNetBSDだけっていうのも凄いな。AURの7+は多分別物。
そーいや、converters/ishってpkg_add ishでインストールできないんだよね。/usr/ports/converters/ishでmakeしないと入らない。その割に、/usr/ports/converters/MakefileにはSUBDIR += ishで認知はされてる。
あー、PERMIT_PACKAGE= no license, PERMIT_DISTFILES= no licenseになってるからpkg_addでパッケージを追加できないのか。
ってことは、alsaに関してもそういう扱いをしておくのが落とし所になるんじゃないかなあ。本当に必要な人に限り、makeすれば使える形。
2か月以上放ったまま（実際には2019年から作業してるので放置され続けてもうすぐ3年になるか）なxlxd-ipv6についてもそろそろ決着付けたいんだよね。棄却なら棄却できちんとそう言えば良いし、マージするならするで良いんだけど…PR投げたままgdgdで放置ってのはどうも落ち着かない。
XLXのスーパーセットだよん、で登場したURFではIPv6対応が入っているので、もうそっちへ移行しちゃいなYO!であればそれはそれで良いのかも。
（まあ、自分のPRについては棄却して、URF由来のIPv6コードを取り込むってシナリオになるような気がするけど。）
https://github.com/LX3JL/xlxd/pull/240#issuecomment-1954218934
alsa-lib-1.2.8(2023/Jan)辺りの頃からやってる以上、そう簡単に退くつもりはないですねー
過去にその問題は解決してるんだけど、流石にそれを知らない人に噛みつかれるのは面倒ですね…という訳で、過去のMLのメッセージを示して「注意深く読んどいて」とお願いすることにしましょう。
とはいえ、sndioな世界に対してALSAを移植するのはやっぱり宗教論争の火種を持ち込むようなものになるんですかねえ…（かなり冷や冷やしてます）。
自分としては、アマチュア無線向けのソフトウェアが皆ALSA使ってる（そりゃLinux上で動かすことしか考えていないから当然そーなる）のでsndio化する際の繋ぎなり補助具なりとして使えりゃ十分って立場なんですけど。
ま、易きに流れる…ALSAあるならそれ使えばいーじゃん、というのを懸念する気持ちも理解してるつもりですよ一応？
それとも怒られるの覚悟でしれっとcommitしちゃうか…？
過去の作業を一斉放出してるだけなので、全然新規の案件は無かったりします。鮮度の低い功績があってもね…
ああ、emulators/dosbox-xもそういえばokもらえてるのかどうか怪しいので少し前にどうなってますー？って聞いてる気がするけど明確な返事をもらった記憶が無いような…それとももらってる…？
これってcommitしちゃって大丈夫なんだよね？（ちょっと自信が無いので二か月以上放ってたりする） https://marc.info/?l=openbsd-ports&m=170241126312864&w=2
devel/msgpack-c: 今commitしてきた（これに伴いeditors/neovim, editors/neovim-qt, sysutils/tmateのcommitも済んでる）
japanese/onew: llvm-16への移行に伴う修正を投げてはいるけど音信無いのでping?して確認中
audio/{alsa-lib,alsa-utils,alsa-plugins}: 昨日ports@に投げてレビュー待ち
sysutils/arm-trusted-firmware: v2.8.5＋sun50i_h616対応に加えてSUNXI_SETUP_REGULATORS=0化したものも生成する…これどうしようかな？
japanese/canna: cannastatが動かない問題の修正…以前パッチ投げたけどお返事なし。
…とりあえず、こんな状況か。一旦/usr/portsの下もきれいに掃除したいんだよね。
確かに日本語ってそもそも等幅文字で記述することが多いから、ワードラップ＋justifyとか、プロポーショナル文字使う組み方って読みにくいような。
日経リスキリング、ねえ…日経＋（流行りのワード）が量産されるなら日経ハラスメントも時間の問題なのかなあ。日経を読めと押し付ける嫌がらせとして解釈してもよし、日経が送るハラスメント紹介マガジンと解釈しても良し。
（やはり日本語にも単語単位での改行の実装を行わないと「ハラスメント」と言われてしまう時代が来るのではないか…句点を入れるだけで「マルハラ」とか謎の攻撃を受けてしまうし、と意味不明なエアリプを）
（そこは句読点入れてほしかった…とエアリプしてみる）
sndioについては、audio subsystemがカーネルにあろうとユーザースペースにあろうと「高負荷だったらアプリがアンダーラン起こすんだからaudio subsystemがユーザースペースにあっても問題ないでしょ」という理由でこうなってるらしい。
sndio – OpenBSD audio & MIDI framework for music and desktop applications (2010/Mar/13) http://www.openbsd.org/papers/asiabsdcon2010_sndio_slides.pdf ※page15
そして音切れを避けるためにはブロックしないようなコードを書くこと、十分なCPU資源を用意することと記されている。
…って理解で、良いのかな？
OpenBSD側に立ってしまうので、LinuxだろうとOpenBSD以外の*BSDな兄弟達も「sndio使おうぜ、な？」となってしまう点についてはどうかご容赦頂きたい。
NetBSDはカーネル内にミキサーというかオーディオフレームワークを持たせてる感じに見える。OpenBSDとは思想が違うのか（sndiodに投げてそこからカーネル越しにデバイスドライバへ、という経路になってる）。
OpenBSD発の音声フレームワーク - sndio (2018/8/25)
https://fuguita.org/?EBUG%E5%8B%89%E5%BC%B7%E4%BC%9A/20180825_sndio
@uaa これは読んだ
OSC2019広島 (2019/09/15) 発表スライド http://www.pastel-flower.jp/~isaki/NetBSD/osc19hi/
（そしてPulseAudioがsndioにあれこれデータを投げて鳴らすので、ちょっとCPU負荷も増えちゃいます）
OpenBSD-portsのALSAについては、「あくまでもsndio化するための補助」という位置付けにしているのでalsa-pluginはPulseAudioしか入れてません。
alsa-lib→alsa-plugins→実際のデバイスって経路になるので、alsa-plugins次第で色々なデバイスに対応可能だったりします（どうも今はalsa-lib→PulseAudio経由が主流っぽいですね）。
Linux限定だったはずのALSA、今ではなぜかFreeBSDやDragonFlyBSD、NetBSDにもportがあったりする…そしてOpenBSDにもその魔の手が（おい
このアカウントは、notestockで公開設定になっていません。
OpenBSDはsndio上にPulseAudioとかJACKとかPortAudioとか色々載ってる感じなのである意味楽なんですよね。とはいえ複数デバイス存在する場合にPortAudio越しのsndioとかおっ始めると本当に地獄です（なのでdirewolf…software TNCについてはsndio化した）。
もしかして：NetBSDの音回りって（触れてはいけない）
NetBSD + pkgsrc における oss, alsa, pulseaudio についてのメモ (2017/01/02)
https://tsutsui.hatenablog.com/entry/ar1166538
そーいや他のBSDの兄弟達の音回りってどうなってるんだろう？OSSなのかそれともsndioなのか、別のフレームワークなのか…
さてと、alsa-plugins-1.2.7.1（これは元の更新が無いのでこのまま）、alsa-lib-1.2.11, alsa-utils-1.2.11になったので再度ports@に投げて評価を待つとしよう。
なにしろアマチュア無線向けのフリーウェアってLinux(ALSA)前提なのでalsa-libが無いとどうしようもないケースが多くって。sndio化しちゃえばいいじゃん、そうしたいのは確かなんだけどとりあえずALSAでの動作をOpenBSD上でも確認できた方が便利なのは確かだし…って理由で移植してる（sndioを推す側としては、ALSAを載っけてその上で安住されても困るっていう思惑があるようだしそれは理解できるんだが）。
Intel Arcのドライバ、今回はファームウェアのアップデートも入ってるのか（なので更新が終わるまでが長い）。
MP3の置いてあるディレクトリ名からバレてしまうのだけど、曲はSunchyme(Dario G)です。多分一度は聞いたことがあるはず。 https://www.youtube.com/watch?v=yFKhgF_vkgs
適当にaplayで鳴らせそうな.wavがあったので、ちょっと鳴らしてるけど…問題ないと思う。
alsa-lib-1.2.10→1.2.11のportsはできた。この調子で他も進めよう。
PCI✕5だけじゃなくCOMポート✕10ってのがすごいな（でも下手にこの手のマザーに手を出してしまうと、壊れたり世代交代する際に目茶苦茶苦労するんだよな…代替品が無くて）。
このアカウントは、notestockで公開設定になっていません。
あー…（USB3.0はそのままスルーして、USB2.0部分だけ3ポートのハブを介すってことか…）
@lo48576 ですです、なので差し込みのタイミングによってはUSB3.0ホスト/USB3.0デバイスの組み合わせでもUSB1/2な速度になることがあるという… https://qa.elecom.co.jp/faq_detail.html?category=&id=8372
こんな時間からNetBSD-current(10.0-RC4)のビルドをおっぱじめてしまったので寝るまでに終わるなんていうのは絶望的だわな…
OHCIとUHCIがUSB1.1(Low/Full-speed)、EHCIがUSB2.0(High-speed)、xHCIがUSB3.x(Super-speed)だけどUSB1.1(Low/Full-speed)/2.0(High-speed)にも対応できるって話だったよーな。
USB ってやつはバージョンと速度のみならずコントローラまでややこしい
H616対応は終わったようなのでもう/usr/srcのｵﾚｵﾚ差分は全て破棄して良いでしょう（というかしました）。
あとは/usr/portsのｵﾚｵﾚ差分をどう始末したもんか…
捨てました。流石にもうOHCI/EHCI/UHCI大量にホストコントローラぶら下げる時代でもないですし。
diff -u -p -r1.36 usbdevs.c
--- usr.sbin/usbdevs/usbdevs.c 28 Dec 2022 21:30:19 -0000 1.36
+++ usr.sbin/usbdevs/usbdevs.c 18 Feb 2024 12:27:50 -0000
@@ -271,7 +271,7 @@ main(int argc, char **argv)
int i;
int ncont = 0;
- for (i = 0; i < 10; i++) {
+ for (i = 0; i < 24; i++) {
char path[PATH_MAX];
snprintf(path, sizeof(path), "%s%d", USBDEV, i);
…要るか？捨てるか…？
あーalsa v1.2.11出ちゃいましたかー（ということをvoid linuxのアップデートで知る）。直さないと…
nginxのフォークってengine-xにならないのかなあ。nginxよりも読みやすい！なんて。
このアカウントは、notestockで公開設定になっていません。
野生化したサーバとか野良ドメインとか…
このアカウントは、notestockで公開設定になっていません。
（Oracle(Sun)のコンパイラ、とかもあったんでしたっけ…）
JavaScript界隈でも三項演算子禁止令とかあるのか。
【2つの理由】三項演算子は仕事で使うべきではない (2022/3/28)
https://skyblue-dev.com/ternary-operator/
「１．三項演算子を一切禁止する。（推奨）
２．入れ子がない場合に限り、三項演算子を許可する。
３．条件部が単一条件の場合に限り、三項演算子を許可する。
４．条件部が単一の真偽値変数に限り、三項演算子を許可する。」
自分は2.。流石に三項演算子の入れ子は意味分からなくなるのでこれは避けてる。
まあ確かにコーディング規約があるならそれに従う、のは当然だよねえ。
あー、sj3のUTF-8化はどうしたもんかなー。なんとなくこんな感じの物を追加すれば良いのかなーという感じはしているんだけど、bskeyの追加みたいに害無さそうなコードを入れているはずなのに動作が妙になるというのを見てしまうとビビってしまって。
リソースの確保と解放は必ずペアにする（エラー発生時に処理を抜ける際もちゃんと解放する）、switch～caseはdefaultを忘れない、というのは気を付けるようにしてる…つもり。まあ気を付けても忘れるのがヒトなので、モダンな言語はその辺を楽させてくれなくても警告は欲しい。
自分ではコード書くときに今のところRustは選ばないけど、既に書かれている物を触るとか便利そうなライブラリがあればそれで書けるようにしておくとか…準備はしたいなあ。
（不慣れだけどC++を使うのはSTL便利だし…という理由による）
switch～case、今はdefaultとそれ以外の場合分け（だったらif文で済むよね？）というケースでも、将来ここになんか追加機能を突っ込むかもしれないなーという時は割と使うかも。
自分もCS出ではないんですが…なんでこんな人間が組み込みやってたんだろう（遠い目
あー言われてみればOpenCLもCっぽいけどCから微妙に違う何かなところがあるから、再利用したいというのはあるかも。
このアカウントは、notestockで公開設定になっていません。
gcc以外で使ったコンパイラっていうと、GreenHillsですかねえ。流石にCPUについては秘密とさせてくださいなんですけど（もう10年以上経過しているので触れちゃっても良いのかもしれませんが、守秘義務ってことで）。
え、C言語って普通にswitch~casseありますよね。K&R本初版にも書いてある（って今ページをめくったｗ）。
組み込みでもgcc使うケースって多い気がしますが、どうなんでしょう（ルネサスとかMicrochipのマイコン辺りだと非gccというケースはありそうですが）？
ああでもアセンブラ狩りって聞いたことないですね。流石にお仕事取れるレベルではないですけど…趣味でちょいとマイコンをいじる程度ならまだ何とか付いていけるかもしれない。やっぱあの手のうるさいのを黙らせるならアセンブラ（待て
でも言語仕様がこれだけ進化しても、そのうち「老害Cerは死ね」とか言われちゃうのかな。日経何とかで「コボラーは死ね」とか散々偉そうに言っている誰かさんみたいに（ああいう手合いってコボラーが滅んだら今度はCとか古めの言語使いの首を狩りに来るんでしょう？魔女狩りとやってること変わらないじゃん）。
【C言語】C23規格のプログラミング【GCC 13.1/Clang 16.0を利用】【使い方】 (2023.6.13) https://hiroyukichishiro.com/c23-standard-in-c-language/
clang-16は未対応だけどgcc-13.1だとauto（型推論）が使えるとか、C言語どこ行っちゃうのって感じですね（C++だとC++11からautoが使えていたのでそれを取り込んだのかなー）。
C11の仕様－脆弱性対応に関連する機能強化点 (2014/3/14) https://www.buildinsider.net/language/clang/02
printf_s()、OpenBSDでは実装してないみたいだけどそもそもOpenBSDのprintf()は%nを受け付けない（警告文の表示に加えてcore吐いて落ちる）。manにもこうあるし。
The %n conversion specifier has serious security implications, so it was changed to no longer store the number of bytes written so far into the variable indicated by the pointer argument. Instead a syslog(3) message will be generated, after which the program is aborted with SIGABRT.
まあ、時代が戻ることは無いはずなので…clangもgccの拡張文法がそれなりに通るし、可読性が悪くならなければちっとは使ってみても良いのかもしれない（C11, C17とかで規格化されているなら遠慮する必要も無いし）。
C11以降のモダンな文法、そういえばちゃんと知らないから…何かの折に知っておきたいな。
発端はswitch～caseのcase 0x00 ... 0x7f:というのを使ったこと。これを使わないとなると、defaultで受けてif文で範囲見て処理を分ける…けど、defaultの先にも処理の記述があるとめんどいよねという時にこの拡張文法は結構ありがたいなって。
gccの拡張文法、1995年時点だとあまり使うなっていう話があったけど（確かに自分がプログラマーやってた時代は割と禁忌な扱いだった）、イマドキのCとしてはどこまで許容されるんだろう。
gcc(Gnu C Compiler)の拡張文法(1995/10/21) http://cms.phys.s.u-tokyo.ac.jp/~naoki/CIPINTRO/gccextend.html
流石に三項演算子の二項目目の省略は…
n = (n < max) ? n : max;
n = (n < max) ? : max;
こういうコードなら別に省略しなくても良いのでは？という気がしなくもなく。省略したい気持ちも分からなくはないけど。
うーん、H3の打ち上げ、H2Bの最初の頃みたいな「新しい時代へ(F1)」「希望に満ちた明日へ(F2)」「全ての人類のために(F3)」（F4以降は無し）といった文言入ってないんですね…ちょっと復活するかなーって期待しちゃったんですけど。
（結構好きだったんですよ、アレ）
※中国語に関するスキル、自分は一切持ってません
なんか中国語版が出てきそう（見てみたい）
偽中国語異世界小説 - 偽中国語異世界小説（みなもとあるた） - カクヨム
https://kakuyomu.jp/works/16817330653680110893/episodes/16817330653680126229
これおすすめです
あ、U+FFFDってUnicodeにおいてはそれ使うって話だけど…EUC-JPでそれに対応する文字って無いんじゃ。
UTF-16LE/BEって要するにバイトストリームで流した場合に下位8bitか上位8bitのどっちを先に流すんよという話だと思ってた。
解釈不能な 「�」の文字ってU+FFFDなんですね…
3.8 Surrogates (D75):
> Isolated surrogate code units have no interpretation on their own. Certain other isolated code units in other encoding forms also have no interpretation on their own. For example, the isolated byte 8016 has no interpretation in UTF-8; it can be used only as part of a multibyte sequence. (See Table 3-7.)
とあるので、解釈不能なゴミが入ってる扱いにする (たとえば U+FFFD「�」にするとか) のでよさそう？
とはいえ、UTF-8 decoder capability and stress testであっても、下位サロゲート→上位サロゲートの順に記述した場合のテストは無い。
というか、UTF-8においてはサロゲートペアの概念は無い（使わない）のでサロゲートペアを示すエンコードが行われたとしてもマトモに表示できなくて当然…で良いんだよね？
これだ！
UTF-8 decoder capability and stress test https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
これではなくて https://www.w3.org/2001/06/utf-8-test/UTF-8-demo.html
うー、とにかくおかしなUTF-8というのを集めたテスト用のファイルをどっかで見てるんだよ…
では、サロゲートペアは何文字の「不正な文字がおるで」を吐くことになるんだろう…まとめて1文字か、あるいは各サロゲートに対し1文字なのか。（嫌だこんなこと考えたくない…！）
あー、サロゲートペアあるか…
どうせ出力はUTF-8、内部ではEUC-JPに変換！なのでサロゲートペアは「知らんがな」という扱いにするしかないかも。
正しくないUCSをエンコードしたUTF-8の扱い、そのバイトストリームをまんま放り出すか、1文字分の「なんか不正な文字がおるで」的な文字を1文字返すかは悩みどころ。あんまり賢くは無いけど、個人的には後者にしちゃいたい。
避けたいんだけど、文字コードに応じn byte分バッファリングしてwchar16_tの形に変換～なんてコードを拡張するとなると結局自前でUTF-8デコードを避けられないという気がする。
※一部修正しました
UTF-8、まあまあ落とし穴は少ない方なんだけど、 redundant encoding だけはセキュリティホールになりかねない罠なので、できるだけ自前実装は避けたいところではある
躊躇わずにまずはコードいじってみて、ダメなら投げるしかないか…
構造上自前でUTF-8をいじらないといけないように見える（iconvを通す余地がなくはないけど）、という案件な気もするんだよなあ。
EUC-JPからUTF-8へ変換する場合、補助漢字を使っていたとしてもせいぜいU+FFFFの範囲には収まり…ませんね。 https://ja.wikipedia.org/wiki/UTF-8
spamな通知、ただのブロックではなく通報付きブロックの方が良いのかなあ。とはいえ通報された相手の仕事が増えるだけなんだけど…
うーん、設定である程度回避できるとはいえユーザ体験（って言葉は好きじゃないけど）を悪化させる問題は解決したいしとはいえ優先順位は低くもないけど高くもないしほんとにどーすんのこれ。
むしろとりあえずUTF-8環境でおかしくならないような対応を先にやらないと困るっていうのが現実なんだけど。
ちょいうろ覚えなんだけど…（いちいちgitで件のcommitまでもどるのめんどいし）、bskey設定を有効にすると「あいうえお」は一連の文字列になるのに対して子音が混じるか何かすると区切られてしまうという症状が起こるような。なのでrevertしてる。
delkeyって-1のままなはずだし、0x7fは頑張っても（charとして解釈して符号拡張しても）0x7fのままなので影響は無いと思ってるんだけどなんかあるのかなあ。なんかあるからおかしな動きをするはずなんだけど。
ラーメンショップやくるまやラーメンは全国区みたいだし…対抗できるのは増田屋くらいなんだろうか（それラーメンじゃなく蕎麦ですけど…）
ラジオCMでおおぎやラーメンなるお店の存在を知ったけど、これも神奈川近辺には存在しない… https://www.oogiya.com/tenpo/index.html
神奈川の地でもスガキヤの名前は聞いたことあったけど…とおもっていたのだが、関東から撤退していたのか。 https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AC%E3%82%AD%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%BA#%E6%92%A4%E9%80%80%E5%9C%B0%E5%8C%BA
このアカウントは、notestockで公開設定になっていません。
