DeviceTree、U-boot由来なのかLinux由来なのかって部分も気を付けないといけないか。同じはず…なんだけどな？
SASANO Takayoshi(@uaa@social.mikutter.hachune.net)の投稿
OpenBSD, 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
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を見失う現象は変わんないっすね。
相模原の圏央道、ワゴン車がのり面乗り越え転落 男性死亡 https://www.kanaloco.jp/news/social/case/article-970029.html (神奈川新聞, 2023/2/18)
内回りの26.7kmポストってこの辺… https://goo.gl/maps/gWUdYnSkXngw6bUY9 竹やぶなんてあの辺あるのかな？って思っていたけどある感じではある… https://goo.gl/maps/QX8w7ogRiSFcWCQ8A
でもそこへ落ちるとなると、相当のことをしなければ落ちない筈。落ちた先に民家や道路があったらより大きな惨事になっていたんだろうなあ…（怖
ここ一か月以上作業サボってたからもうなにやってたかなんて忘れちゃったし、Twitter(Twilog)→Mastodon(notestock)への移行もあって作業メモの検索性もアレなのでもう何が何やら。
おそらくgitにある最新版辺りをgit cloneして、それをconfigure; makeする際に必要なCFLAGS, LDFLAGSないしconfigureの引数、必要であればパッチの作成…辺りを行って、何が必要になるかの洗い出しをしないといけないとかそんな感じの何か。
alsa-utils、これでconfigureは通るけど結局BSD対応を入れてないとビルドができない（sched_setscheduler()はOpenBSD未実装なのでその辺りの対応が居る）から結局どうにもならんか…
AUTOMAKE_VERSION=1.16 AUTOCONF_VERSION=2.69 ./configure CFLAGS="-I/usr/local/include/libepoll-shim -I/usr/local/include/inotify" LDFLAGS="-L/usr/local/lib -L/usr/local/lib/inotify -lepoll-shim -linotify -Wl,-rpath,/usr/local/lib -Wl,-rpath,/usr/local/lib/inotify" --with-alsa-prefix=/usr/local/lib/alsa-lib --with-alsa-inc-prefix=/usr/local/include/alsa-lib --disable-nls
https://twitter.com/uaa/status/1614584713913720832
https://twitter.com/uaa/status/1614585053228724225
えーと、確かalsa-libのportsをやっていて、
（諸事情によりばっさり削除）
alsa-libは1.2.9待ち、その間にalsa-plugins, alsa-utilsやっちゃおうーって話だったっけ？
smhnのおかげでsocial.mikutter.hachune.netを書けるようになった（これが無かったらえっと…mikutter.social.hachuneえーと？みたいに正しい順番で書けない人）
このアカウントは、notestockで公開設定になっていません。
（などと呟くとまるで自分が放火魔みたいじゃないか…！）
このアカウントは、notestockで公開設定になっていません。
レンズ交換式カメラは贅沢品になっちゃったよなあ。
iris.to、今まではnpub暗号鍵な
https://iris.to/profile/npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890 がNIP-05認証通ったせいか https://iris.to/uaa@ik1-342-31132.vs.sakura.ne.jp にリダイレクトされるようになった（ユーザ名付きのVPSなドメイン、自分はこれで良いやと思ってる）。
Misskey/Mastodonだけでなく、Nostrでもドメイン名取得をちょっと意識しないといかんなーという感じになってる。まあnostr.jsonを置かせてくれるサーバがあればいいので必須って訳でもないけど…
このアカウントは、notestockで公開設定になっていません。
今っ更気づいたんだけど、ALSAのChanges v1.2.7.2 and v1.2.8 https://www.alsa-project.org/wiki/Changes_v1.2.7.2_v1.2.8 にBSD系の対応入ったって文言出てますね…実際に使うにはESTRPIPE周りの修正が入った次の版の方が（個人的には）お勧めなんですけど…
でも本家STM32F4でも-Osな最適化入れても動かないコード出しちゃうような人達なので、意外とハードウェアの非互換性は大したことないのかもしれない。勝手な推測だけど。
ん－、OpenGD77のソースが出てない（出さない）以上は何をどう直したかが分からないから本家/コピーの違いがどうなっているかが分からない… Experiences with Non original STM32F4 processors from China. https://community.st.com/s/question/0D53W00001CPaTpSAL/experiences-with-non-original-stm32f4-processors-from-china (ST community, 15/Nov/2021)では、チップのIDが違うらしいって話は出てるけど。
STM32 CLONES https://mecrisp-stellaris-folkdoc.sourceforge.io/clones-stm32-mcus.html ダイ写真へのリンクもあるな…結局STM32F4のクローン(?)はGigaDevice GD32F407で良いってことなのかな
irisでNIP-05認証がfalse扱いになってて、設定見直してるんだけど原因ﾜｶﾗﾝ…
