nostr:npub17f8mdvtcfhutjxyp6uektka439qv8aptxh64hmdr0k6ym5gh8r8s273pnl 蟹のNICが繋がってるPCI Expressポートっぽい…

…あれ？何故WHEA-Logger event 17が出てる？

UEFI SetupのAdvanced→APM Configuration→Restore AC Power LossはPower Offになってる。まあこれはそういうもんとして…

Tool→Event LogでAC Power Loss!が幾度かと4S Forced Shutdown!が残ってるのが気になるな。

全然無関係の可能性も当然あるとして。

UEFI setupで電源周りの設定とか何かあったかなあ（ちょっと見てくる）

nostr:npub1mch5fj2g8gy8sjs6ayyy6njax6hp036m5pzs85l7qzrmxqq7yktsgenwhq 電源チェッカーではPG信号は300msになっていたからおかしくないと判断してるんですけどねえ…

nostr:npub1mch5fj2g8gy8sjs6ayyy6njax6hp036m5pzs85l7qzrmxqq7yktsgenwhq 分からないのが、ATX→Baby-AT電源コネクタ（スイッチ付き）だけ繋げている状態だと電源のファンが回り続けている点。無負荷で回ってるってことは、多分電源自体の自動シャットダウンの問題ではないんだと思う。

nostr:npub1mch5fj2g8gy8sjs6ayyy6njax6hp036m5pzs85l7qzrmxqq7yktsgenwhq その可能性を今疑っているんですが…HDDとSSDとマザーを繋げた状態で、電源入らないんですよね…

ATX電源チェッカー、使う機会はそんなにないだろうけどあると便利そうだなーというのがお店で見た時の率直な感想。

これ、PS_ON#とGNDを繋ぐというのは合ってるんだけど、つんつんするというテスト方法は間違い。

繋いでる間ずっと電源が供給されるから、つんつんする程度ではファンがぴくっと動く程度の動作になるのは当然。

DOSPARAのお店での動作チェックでは問題なかったことと（感謝）、手元にあったATX→Baby-AT変換ケーブル＋電源スイッチでのチェックでも動いてたので、もしかすると接触不良とか他の原因を疑う必要があるのかも。

あーもうっ、どうなってるの一体…後でもう一回繋げ直して動作確認するしかないじゃないか…

自由研究とは言うけどさ、如何に先生ウケして高評価を取るかという、親サイドによる競争だったりもするよね…

「アローゼン」（下剤）が、ストⅡの波動拳のイントネーションで聞こえてしまう呪いを受けてしまってのぅ…ちょっと困るときがあるんじゃ…

この手を使うか…以前試したOpenCLベンチマーク(http://lucuda.web.fc2.com/bwocl/index.html)、これを延々と動くように改造しちゃえばとりあえず負荷かかるかなーって

Orange Pi Zero3向けのAnrdoidソースを落とす（二回目）

圧縮していても36GB近いんだけど、これ展開するのはちょっと勇気要るな…

sys_config.fexに手を入れて、それっぽいU-bootを仕立てて動かすしか手はなさそうだな…って、修正済のはどこかにあったりする？

ATX電源が動かない件、何も結線しない状態で電源のPS_ON#とGNDをその辺にあったリード線でつんつくすると電源ファンが一瞬だけぴくっと動くので（普通なら回りっぱなしになるよね？）、やっぱり動かないという扱いで良い気がしてきた。

…というか、他のマザーで試そうかなと考える前に、なぜこの手法を思い出せなかったんだよ自分、というのがこのtootの主旨。

Android's image name: arm64

[05.263]Starting kernel ...

[05.265][mmc]: MMC Device 2 not found

[05.269][mmc]: mmc 2 not find, so not exit

[ 0.004462][ T1] BOOTEVENT: 4.458207: ON

カーネル、起動しちゃったねえ…

d65f03c0 retということは、little-endianなので c0 03 5f d6と書けばいいのかな

（.wordで記述したものを命令として解釈せず、.wordのまま出てきてしまう）

aa@framboise:~$ aarch64-none-elf-objdump -d test.o

test.o: file format elf64-littleaarch64

Disassembly of section .text:

0000000000000000 :

0: 144f0000 .word 0x144f0000

4: 144f0000 b 13c0004

8: d503201f .word 0xd503201f

c: d503201f nop

10: d65f03c0 .word 0xd65f03c0

14: d65f03c0 ret

18: d503201f nop

1c: d65f03c0 ret

uaa@framboise:~$

…なぜなのか

int test(void)

{

asm __volatile__(".word 0x144f0000");

asm __volatile__("b 0x13c0000");

asm __volatile__(".word 0xd503201f");

asm __volatile__("nop");

asm __volatile__(".word 0xd65f03c0");

asm __volatile__("ret");

}

これをaarch64-none-elf-gcc test.c -c -o test.oして得られたものをaarch64-none-elf-objdump -d test.oすると（続く）