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エントリの解釈が増えるのも面倒なので、リセットだけで回避できればいいのだが…

https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.1/patches.megous/arm64-dts-allwinner-orange-pi-3-Enable-ethernet.patch

うむー、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>;
+ };
+};
が仕込まれてる。

https://forum.armbian.com/topic/12532-opi-3-stuck-login-line-and-hdmi-not-work/?do=findComment&comment=91742

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、名前は聞いてたけどライブラリもそんなことやってるとは（やべーやつだ）…

HID直打ちキーボード、エレキー用のパドルだともうちょい操作性良くなるのかなあ。 https://mfjenterprises.com/products/mfj-564

勤労感謝の日って、お仕事があることに感謝する日なんでしょ？みんなお仕事お疲れさーんの日じゃなく。 #毒吐き

このアカウントは、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を見失う現象は変わんないっすね。