そうだよなあ…ボードが売られていてもあんまし買う気がしないようなものに対するパッチが送られたら…「誰がメンテすんだコレ（困惑）」になりますよねえ。

NetBSDはMilk-V DuoとかLuckFoxみたいなちっちゃいボードへの対応予定ってあるんでしょうか…？（Milk-V Duo、OpenBSDだと64MBモデルは対応しない方向なのでNetBSDなら載るのかなーって）

https://syuu1228.hatenablog.com/entry/20090805/1249466294 を参考に、riscv64向けにOpenBSDのクロスビルド環境を作ろうとしたら…arm64向けの環境が動かなくなってたのでそっちから作り直し。

とりあえずOpenBSDカーネル食わせたいけど…ビルド環境どうしたもんかって問題があるか。

run sdbootになってるからsdboot（に対応するスクリプト）をEFI対応に書き直しちゃうとかそういう方向で良いのかな。

Milk-V Duo、256MBだとcv181x-asic.h、64MBだとcv180x-asic.hを直す必要がありそう。U-bootのbootに関連するコマンド、このヘッダファイル内で再定義しちゃってるから.configで何を設定しようとしていても意味が無いってやつだ。

そもそもconfig_distro_bootcmd.hをincludeしてないんじゃ？

include/config_distro_bootcmd.hに手は入ってない、となるとそれ以外の部分か。

cv181x_c906# fatload mmc 0:1 0x80080000 bootriscv64.efi
148476 bytes read in 10 ms (14.2 MiB/s)
cv181x_c906# bootefi 0x80080000
Scanning disk cv-sd@4310000.blk...
Found 2 disks
No EFI system partition
Booting /bootriscv64.efi
disks: sd0*
>> OpenBSD/riscv64 BOOTRISCV64 1.5
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd
boot>

よっしゃ。

…来た。

今買い買えるならプロボックスかなあ、後部座席は角度を変えるカスタムができると聞いているので、それで。

乗りたかった車…サターンとか？免許取った頃には無くなっちゃったけどね。バイクだとVanVan200、これもなくなっちゃったし。

今乗ってる（カミさんの持ち物ではあるけど）ベリーサも廃版だしなあ…乗りたいと思うものが無い以上、クルマなんてそんなもんだよねーって。

運転免許取ってから20年行かないくらいの時に自動二輪取ったけど、やっぱバイクの免許も持っておいた方が良いかなというのが実感。車運転していて、バイクの動きが読みやすくなったと思う。

（だからといって中型の限定解除/大型取りたいかというと…既得権益の問題もありちょっとパスかなーって）

利用/投入可能なリソースの量には限りがあって、それがまた減りつつある以上は多少の積み基板が増えようとしょうがないよね。 #何かが間違ってる気もするけど

（Allwinnerですら最近はboot0周りのコードは出さずに困るケースが多いというのにな）

うーん、idbloaderとかその辺は（ソースが）秘匿されてるのか https://github.com/u-boot/u-boot/blob/master/doc/board/rockchip/rockchip.rst

（その時点でRockChipから手を引いてAllwinnerへ行きたいわ…）

RV1108はmainline U-bootに入ってるのか。evb-rv1108_defconfigで。

人件費を減らしたいだの、雇う人数を減らしたいだの（その割にスキルのある人は選ぶ）、存在するだけでハラスメントだの、AIの出現で人を減らせるだの…あれこれぐちぐちぐちぐちうっさいのは人嫌い以外のなんと言えば良いのやら。

×「日本は外国人が嫌いだ」
○「日本人は人が嫌いだ」

そんな気がする。

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

公道上って車だけが相手じゃないんで（自転車歩行者二輪車もいます）、狭い通行帯域を巡って交通戦争やってるんですよね。

=> printenv
arch=arm
autoload=no
baudrate=115200
blkdevparts=mmcblk1:32K(env),512K@32K(idblock),256K(uboot),32M(boot),512M(oem),256M(userdata),6G(rootfs),-(media)
board=evb_rv1106
board_name=evb_rv1106

env.imgの意味って何なんだよ💢

16k@512(env)ってあるけどさあ、32k@0(env)の間違いじゃね？という感じですね。ていうかenv.img作らないとダメなのか…Rock Pi S(RK3308)の時はidb, atf, u-bootが必要でenvなんてものは無かったんだけどな。

LuckFox Pico PlusかつeMMC向けのイメージを作るならbuild.shで4. BoardConfig_IPC/BoardConfig-EMMC-Ubuntu-RV1103_Luckfox_Pico_Plus-IPC.mkを選ぶしかないんだけど…他のを選んだ方が良いんだろうか。とりあえずこれで行くけど。

U-Boot SPL board init
U-Boot SPL 2017.09 (May 04 2024 - 10:49:37)
unrecognized JEDEC id bytes: 00, 00, 00
unknown raw ID 0 0 0
Trying to boot from MMC2
ENVF: !bad CRC @ 0x0
ENVF: !bad CRC @ 0x0
spl: partition error
Trying to boot from MMC1
Card did not respond to voltage select!
mmc_init: -95, time 15

ん－、env.img書かないとダメなのかも

だめか。

…ってことは、詰んだかな。
確かbuild.sh lunchではSPI FlashとeMMCは出ていたけど…SD向けのイメージの作り方、あったか？まあ試してみるけどさ。

#!/bin/sh

dd if=/dev/zero of=/dev/rsd1c bs=1M count=64
dd if=idblock.img of=/dev/sd1c bs=1024 seek=32
dd if=uboot.img of=/dev/sd1c bs=1024 seek=544

これでbackup imageのidblock, ubootを書き込んだらこんな感じ。eMMC向けのイメージを無理矢理持ってきてるので動かないのは当然っちゃ当然か。

sd_parts=mmcblk0:16K@512(env),512K@32K(idblock),4M(uboot)
ってのは、512byte目から16kbyte分をenv, 32kbyte目から512kbyte分をidblock、その直後の4Mbyte分をu-bootって意味なのかな。

backup
mtdparts=spi-nand0:256K(env),256K@256K(idblock),512K(uboot),4M(boot),32M(rootfs),48M(oem),32M(userdata)
sys_bootargs= ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs rk_dma_heap_cma=24M
sd_parts=mmcblk0:16K@512(env),512K@32K(idblock),4M(uboot)
Ubuntu
blkdevparts=mmcblk1:32K(env),512K@32K(idblock),256K(uboot),32M(boot),512M(oem),256M(userdata),6G(rootfs),-(media)
sys_bootargs= root=/dev/mmcblk1p7 rootfstype=ext4 rk_dma_heap_cma=24M
sd_parts=mmcblk0:16K@512(env),512K@32K(idblock),4M(uboot)

https://wiki.luckfox.com/Luckfox-Pico/Datasheets のDriverAssistant-RKの中に入ってた。

んー、dd if=/dev/zero of=/dev/mtd0とかでとりあえず潰してみたけど…再起動しなくなったのでﾖｼ!であったとしても、microSDからは全く起動しないって問題が出てきたわけで。
んでもって、Windowsからは「不明なデバイス」として認識されてる（なんか必要なドライバがあるけど入れてない）のでSoCToolKitからRV1103が見えない。ドライバどこにあるんだろう。

滅ぼすしか無いのか（SPI NANDの中身を）

起動用のmicroSDを作る際はenv.imgが無いと作れないって言われちゃったので渋々従ったけど…どこにidblockがあるかSoCはどうやって判定してるんだろう。

あー、microSDから起動する場合はSPI NAND Flashの中身は消せって書いてあるわ… https://wiki.luckfox.com/Luckfox-Pico/Luckfox-Pico-Flash-burn-image

うーん、LuckFox pico用の起動用SDってどう作るんだ…？

勝手に$HOME/.bash_profileこさえるの止めてくれませんかね…💢

[ 0.079708] Creating 7 MTD partitions on "spi-nand0":
[ 0.079731] 0x000000000000-0x000000040000 : "env"
[ 0.081776] 0x000000040000-0x000000080000 : "idblock"
[ 0.083719] 0x000000080000-0x000000100000 : "uboot"
[ 0.085580] 0x000000100000-0x000000500000 : "boot"
[ 0.087684] 0x000000500000-0x000002500000 : "rootfs"
[ 0.089754] 0x000002500000-0x000005500000 : "oem"
[ 0.091903] 0x000005500000-0x000007500000 : "userdata"

これを模した形にすれば良いのかな

ん－、Mastodon→Bluesky側は比較的すぐに反映されるっぽいけど、その逆は時間がやたらとかかるのかなあ…？？

でも反映されるには時間かかってる感じっぽいなー

おおおー、この書き込みがBluesky側にも行ってるー https://bsky.app/profile/uaa.social.mikutter.hachune.net.ap.brid.gy

out
├── bin
│   ├── board_xxx ------------------- bin run on board
│   └── pc -------------------------- bin run on PC
├── image_xxx ----------------------- Image output dirctory
│   ├── download.bin ---------------- Will Only be downloaded to the DDR of the d
│   ├── env.img --------------------- include partiton table and boot parameter  ├── idblock.img ----------------- loader image
│   ├── uboot.img ------------------- uboot image

なので、多分download.binは無視できる。ICEか何かで流し込む時に使うんだろうし。

他のRockChipな石もそういうノリなのかな…Rock Pi向けのディスクイメージとか見てみると良いんだろうか

blkdevpartsをLinuxカーネルに直に渡してるのか。じゃあ、OpenBSD使うならenv.img要らなくね？

MBRもGPTも無い世界もあるんですよ(blkdevpartsの紹介） (2020/12/06) https://qiita.com/hon_no_mushi/items/009fceebbba2e7d5cd3d

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

GLOBAL_PARTITIONS: 0x8000@0x0(env),0x80000@0x8000(idblock),0x40000@0x88000(uboot),0x2000000@0xC8000(boot),0x20000000@0x20C8000(oem),0x10000000@0x220C8000(userdata),0x180000000@0x320C8000(rootfs),-@0x1B20C8000(media)

ん？

LuckFox Pico、こんな感じにU-bootを起動するに必要なファイルを./build.sh ubootで得ているんだけど…これをmicroSDのどこにどー書くのかって問題で止まってる。

uaa@emeraude:~/luckfox-pico/sysdrv/out/image_uclibc_rv1106$ ls
download.bin idblock.img uboot.img
uaa@emeraude:~/luckfox-pico/sysdrv/out/image_uclibc_rv1106$

多分ddでbs=1024 seek=なんとか、でやるんだろうけどその「なんとか」をどう調べたもんかね。

Linuxカーネル起動する訳じゃないからFITイメージも*.its（イメージ記述ファイル）も（多分）mkimageも関係ない、で良いのかな。

[U-Boot] FIT image の作成 (2021/02/11) https://arch.jpn.org/archives/704

うん、Nostr上でざわざわしてる。

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

すみません

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

とりあえず、自分の能力だとこの辺が限界。分かる範囲でレポートまとめてissueで投げよう…

もしかして、この「このようにしないでください」を踏んでるか？ https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage

chrome.runtime.sendMessage()しちゃいるけど、その飛び先がonMessage.addListener()じゃなくwindow.addEventListener()側になってる。で、message.data.paramsが無いのでそこでreturnして抜けるから無限ループにならずに済んでると。

そうだとしてもpass on to backgroundしてるはずだが…？

ん？getRelaysがwindow.addEventListener側から来てる？

nos2xだとhandleContentScriptMessageで全部一緒くたにやっていたけど、horseの場合シリアル越しのとそうでないのとで分けたつもりになっていた…が、分け方を間違えたか何かした、とかいうことだろうかね？

もしかして：getRelaysをhandleContentScriptMessageで処理しないといけないのにhandleMessage側で処理させようとしている

なるほど、iris.to, nostterはgetPublickeyを最初に持ってくるけど、Snort, NostrFluはgetRelaysから始めてる。

シリアルポートへのアクセス許可、これと公開鍵の参照許可が同時に求められた場合はシリアルポートのアクセス許可で代えている…？

permissionの許可と、その有効時間の設定がおかしいとかその辺を疑えばいい？

chrome/nos2xだと、irisでもちゃんとpermissionを聞いてくるな。

snortも、event (nullうんぬん）…irisは黙って公開鍵情報持ってくんだけどこれどうなってるんだ。

nostrfluでnos2x-fox使った場合、event (not recognized: kind: null) is requesting...ってなるな。

common.js、permission周りとか大体一緒なんだよなあ…

getPublicKey, signEvent, nip04.encrypt, nip04.decrypt…実際になんかするときに、ということは分かったが。

serial.js、initDeviceを呼ぶのはcallMethodOnDeviceでwriter=falseの時限定か。

あと、アレだ。webserialをopenするタイミングの「クセ」が問題な気がする。これ直すのはちょい面倒そうだけど。

あー、addListened()からhandlePromptMessage()呼ぶ際の引数がreqだけになってる。こいつだ。

senderがundefinedになってる。

ボタン押すとイベントは来る。仕込んだconsole.logは動いてる。ってことはその先。

true undefined undefined {prompt: true, id: '24964911165907', host: 'nostter.vercel.app', level: 5, condition: 'expirable'} {id: 'mhdenjcigpjpimdoakfmnchpcocglfgl', url: 'chrome-extension://mhdenjcigpjpimdoakfmnchpcocglfg…ercel.app&level=5&id=24964911165907&params=%7B%7D', origin: 'chrome-extension://mhdenjcigpjpimdoakfmnchpcocglfgl', frameId: 0, documentId: '174B9766D00744EAD749AB07DDCEFB64', …}

chrome.runtime.onMessage.addListenerに何が届いているか、まずはここか。コンソールにどうログを表示させたものか…

cancelだのauthorizeだのつついてもpromptのウィンドウが消えない。chrome/browser.runtime.sendMessage()の先はどうなってるんだろうか。forever/expirable/single/noのメッセージを受けられないのか、受けても無視なのか…

polyfill化してもダメか。

esbuildみつかんねー→yarn add esbuild

WebSerialはnavigatorに所属（ブラウザそのものに対するモノ？）、chrome, browserは拡張機能の話だから関係ないか…？

でもWebSerialを使う場合は果たしてpolyfill(browser)越しにやれんのか？という疑問が出るな。多分そこを避けるためのchrome化だと思うんだけど。

うーん、面倒だけど試しにPolyill使ってchrome→browserに書き換えて動くかどうかを試す、をしないとダメな気がする。血吐くことになりそうだけど。

JavaScript→アセンブラみたいなもん
Reactとか→ライブラリみたいなもん
yarnとか→コンパイラとかMakeみたいなもん

なんとか.jsxとか→Cみたいなもん
なんとか.jsxをyarn buildでコンパイルして、得られたなんとか-build.jsをバンドルして配布するとかそういうことしてる。

という、とっても雑な理解をした。Cとかで書くのと違って、import Reactせずにimport ReactDOMしても実行時までエラーを教えてくれないってのは確かにキツいな…

やっぱpolyfill抜いたことによる悪影響が出てる、としか考えられないんだけどこれ…JavaScriptだのTypeScriptだのについてはよー分からんのだけど、基本構造一緒なのにpolyfill抜いてる（Chrome専用にしてるからだろうが）という部分が違うんならそれが原因なんじゃないのって思いたくなる。

128GBとは…凄い時代になってる…！