悪い活動…(視線を逸らす
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
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
偽MSX1用のメモリチップを仕入れないといけないんだよな、そーいや…VDP(TMS9918A), PPI(8255), CPU(Z80), PSG(AY-3-8910互換な奴)は揃いそうだから、と油断してた。
このアカウントは、notestockで公開設定になっていません。
むー、漢方薬ですら訳わからんのにこれに加えて生薬も覚え直さないといけないとか、かなりヤバい状況かもしれん。
しばらく放っておいたNetBSD-currentな仮想マシンのアップデートをやるかあ…
Horny '98って1998年…そんな前だったのか。まあ'98と付けて2098年な訳は無いので1998年なんだろうけど。 https://en.wikipedia.org/wiki/Horny_%2798
Orange Pi Zero 2/3のように接続するRAMも、それに供給する電圧も全然違うなんてケースだと流石に躊躇しますが…今回はSG2002がRAMを内蔵しているのでその辺は多分大丈夫かも。電圧が可変できるPMICも使っていないし。
気になるのが、microSD検出用のGPIOを使ってる/使ってないという違いがあることかなあ。これはモノが届いてから調べてみることにする。
このアカウントは、notestockで公開設定になっていません。
発注しているLicheeRV Nanoは近日中に届くみたいだから、別になにもせずほけーっと待っている、でも全然問題は無い筈。
Milk-V Duo(256M)でLicheeRV Nano用のディスクイメージを動かしても良いものかどうか…同じSoC載せてる以上いきなり燃え出すことは無いと思いたいけど(その辺を確かめるために回路図見たりDevice Tree比較してる)。
@redbrick clock-frequency = <0x17d7840>と記されている(クロックソースが何だろうとこの周波数で動かす)か、clocks = <0x02 0x36>(クロックソースを調べて適当な数値に設定してくれる)かの違いですねえ。
cv1812cp_milkv_duo256m_sd.dtbとsg2002_licheervnano_sd.dtbを見比べてみたけど、なんか違うな。UARTクロックが決め打ちになっているか、クロックソースが示されているかという違いがあるし他にもなんか色々よく分からんデバイスが有効化されてる、LicheeRV Nanoの方が。
うっかりbuild_allしちゃって困惑中。build_fsblだけで良いからclean_allしてやり直し!
Milk-V duo(256M)とLicheeRV nanoの回路図の比較もなんか面倒そうなので、手っ取り早くLicheeRV nano向けのバイナリをビルドして(既にビルド済みのMilk-V Duoバイナリと)比較するのが良さそう。DeviceTreeの辺りを。
このアカウントは、notestockで公開設定になっていません。
U-bootのソースを見るに、"ANDROID!"がmagicになっているから…16Mbyteといわず1kbyteで十分。
dd if=/dev/zero of=/dev/sd1c bs=1024 seek=86016 count=1
これで実際にAndroidの起動を阻止できてる。
もしかして、セクタダンプして”ANDROID!"な文字列で始まるところから一定サイズ潰す、という手法は汎用的に使えるんだろうか。U-bootがとにかくAndroid起動すっぞおら(autobootを止めてくれるな)というケースに対する対抗策として。
PhoenixCardで書き込んだディスクイメージを吸い出して、awutilsで取り出した各セクションのイメージがどの辺りに書き込まれているかを調べて、クサそうなところをdd if=/dev/zeroで潰しにかかる、という手法ね。
うん、これで狙い通り…Androidの軌道を殺し、U-bootだけ動く状態を作り出せた。
framboise# dd if=/dev/zero of=/dev/sd1c bs=1024 seek=86016 count=16384
あ、思い出した。Androidなカーネルだと/dev/memが無いからpokepeek使えないって話だったよね
USE_LIBTOOL=gnuになってるからその推測違うじゃないですかああああああ
(OpenBSDの場合、/usr/local/bin/libtoolがGNU由来、/usr/bin/libtoolがOpenBSD由来なので注意が必要っていうのは…なんか他のツールでも痛い目を見たような気がするけどなんだっけかなー)
/usr/bin/libtoolつかってるじゃないですかああああああああああああA!!!!!!!!11111111
リンク時のlibtoolがconfigure時に指定したLDFLAGSを豪快に無視してくれる、という問題だから…CFLAGSのケアは不要、LDFLAGSだけちょいといじるとかすれば良いのか。Makefile.am辺りに何か仕込めばイケるか?
alsactlがepoll, inotifyを使って、axferがepoll使ってるから…ここだけ手当てする、というのも一案か。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
まーたNetBSDのビルドはcvs updateしたソースで失敗したのでcvs checkoutからやり直し…なんかやり方というか対策がある気がするんだよなあ。