CubieBoard2サーバが起動しなくなった問題（解決）
HDDがダメなのかなーということで安いSSDを手配してCubieBoardに接続……したけどfdiskでコケよる。ただfsckのこともあったしたぶんNetBSD/evbarmのどっかがおかしんだろーなーと母艦側でfdisk→disklabel→newfsまでお膳立てしたところ無事にインストール完了。
俺「ふむ、pkgsrcのビルドを始めたけど問題なさそうだしこの様子なら大丈夫かな」
→剥き出しで繋いでいたSSDを机の端に移動させる
SSD『CRC Error』『CRC Error』『CRC Error』『CRC Error』『CRC Error』『CRC Error』
俺「あっこれケーブルが駄目なやつだ」
SATAケーブルの根本を折るようにして筐体に無理矢理押し込んでいたという心当たりもあるので薄手のSATAケーブルに交換。これで本当に大丈夫なはず。原因がケーブルということになるとHDDは問題ないということになるんだけど、消費電力とかもあるからこのままSSDでいく予定。
ちなみにCubieBoardは基盤上のピンコネクタから+5Vを供給するため、専用のSATAケーブルが付属している。ただしこれSATAと一体化しているタイプなので、SATAだけ別のケーブルに交換するということができない。というわけで
鋸で真っ二つの刑。力技もいいところだけど電気的には問題なし。
なおSSDは結局WDのWDS240G1G0A(240GiB)にしたんだけど、 http://www.hardware-boom.com/solid-state-drive-western-digital-green-pc-ssd-240gb/ にある分解写真を見たら（スッカスカなのはまぁいいとして）基板におもいっきり『SanDisk』って書いてある。やっぱ中の人一緒じゃねーかコレ。
GR-PEACH + U-Bootでtftpboot
会社帰りにパーツ屋へ閉店時刻ぎりぎりに滑り込んでLANコネクタを買ってきた。んでボードにハンダ付けして早速動作確認。TFTPの使い方をよく知らないのでGoogle先生に聞きながら適当に実施。
=> setenv autoload no => dhcp sh_eth Waiting for PHY auto negotiation to complete.. done sh_eth: 100Base/Full BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.0.7 (577 ms)
お、取れた。ということはU-Bootで通信はできているということなので一安心。
次に接続先のIPとファイル名を指定。
=> setenv serverip 192.168.0.5 => setenv bootfile netbsd.bin
tftpbootコマンドで先ほど指定したIPアドレスからファイルをダウンロードして0x20000000に展開。
=> tftpboot
sh_eth:0 is connected to sh_eth. Reconnecting to sh_eth
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Full
Using sh_eth device
TFTP from server 192.168.0.5; our IP address is 192.168.0.7
Filename 'netbsd.bin'.
Load address: 0x20000000
Loading: #################################################################
#################################################################
#################################################################
###################################
2.8 MiB/s
done
Bytes transferred = 3376148 (338414 hex)ダウンロードは1〜2秒で終わるので後々トライ&エラーする羽目になってもストレスが溜まることは無さそう。
で実行。
=> go 0x20000000 ## Starting application at 0x20000000 ... hey, favstar! ban stop me premiamu! -- @toshi_a
よし動いた。
というわけでなんとか目処は着いたので移植に専念できそう。よかったよかった。
GR-PEACHでxputc
GR-PEACHにNetBSD載せらんねーかなという実験の手始めとしてブートローダのところを見ていると、どうもシリアルコンソールにデバッグ出力としてxputcというサブルーチンで行っているものがある。実態はおそらくsrc/sys/arch/arm/cortex/a9_mpsubr.SっぽいけどどうもRZ/A1Hでそのまま使えるかというとなんか微妙な気がする…ということでRZ/A1H向けのxputcを実装してみた。xputc以外はビルドを通すために用意しただけので空関数だったりと超適当。
なおRZ/A1Hのシリアル出力は最大16文字分のバッファがあるので、正しくシリアル出力ができているかを確認したい場合は16文字以上の文字列を出す必要がある。それと文字化けや欠けが発生してもわかるよう、それなりの意味のある文字列が望ましい。…ということで10秒くらい考えた結果こうなった。
.section .start,"ax",%progbits .global _C_LABEL(grpeach_start) _C_LABEL(grpeach_start): PRINT("hey, favstar! ban stop me premiamu! -- @toshi_a") loop: b loop
と、こんなておくれプログラムでとりあえずxputcでシリアル出力ができることは確認できた。
ただこれでできたnetbsd.binをGR-PEACHに読ませようとしたときに気がついたんだけど、今のところ3MBはあるnetbsd.binをGR-PEACHのメモリに配置する方法がない。というのも、
- シリアル（xmodem等） → なぜか600KiBほど転送した段階で固まる
- USB → microUSB端子に刺さるものを持っていない
- Ethernet → u-bootで対応しているようだけどコネクタを付けていない、ついでにHUBのポートも足りない
- microSD → まさかのu-boot未対応
という状況。ちなみにxputcの確認はどうせコードは手前の領域だろうということで、xmodem転送中にフリーズしたらリセットして何食わぬ顔で実行、という手段で良かったんだけども。ぐぬぬ。
CubieBoard2サーバが起動しなくなった問題（解決しなかった）
はい
Welcome to minicom 2.7 OPTIONS: I18n Compiled on Feb 9 2017, 05:05:04. Port /dev/ttyU0 Press CTRL-A Z for help on special keys ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0 wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24), retrying ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0 wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24), retrying ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0 wd0a: device timeout reading fsbn 1517440 of 1517440-1517503 (wd0 bn 1525632; cn 1513 tn 8 sn 24)
ということでまたサーバにアクセスできなくなったのでシリアル繋いだ結果がこれである。うーんやっぱりHDDがイカンっぽいがどうしたものか。
ところでSSDの値段見てたらWestern DigitalとSanDiskがそれぞれ製品出してたけどそれ中身一緒だったりしないん?
CubieBoard2サーバが起動しなくなった問題（解決済み）
ファイル置き場やproxyに使っているCubieBoard2（NetBSD/evbarm 7.1）が先週当たりから応答しない。とりあえずシリアルケーブルで母艦と繋いでみる。
wd0 at atabus0 drive 0
wd0: <Hitachi HTS545050B9A300>
wd0: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors
boot device: wd0
root on wd0a dumps on wd0b
/: replaying log to memory
root file system type: ffs
Sun Jun 4 01:45:20 JST 2017
Starting root file system check:
panic: kernel diagnostic assertion "oldsize != VSIZENOTSET || pgend > oldsize" failed: file "/home/star/work/netbsd/src/sys/uvm/uvm_vnode.c", line 355
Stopped in pid 21.1 (fsck) at netbsd:cpu_Debugger+0x4: bx r14
db{1}>おぉうなんでか知らんけどfsckでkernel panicしとる。最初はディスクが死んだかと思ったけどシングルユーザモードでなら起動できたのでSMARTを見た感じでは大丈夫…そうな気がする（これの読み方をよく知らない）。
# atactl /dev/wd0 smart status SMART supported, SMART enabled id value thresh crit collect reliability description raw 1 100 62 yes online positive Raw read error rate 0 2 100 40 yes offline positive Throughput performance 0 3 243 33 yes online positive Spin-up time 30064771072 4 100 0 no online positive Start/stop count 636 5 100 5 yes online positive Reallocated sector count 0 7 100 67 yes online positive Seek error rate 0 8 100 40 yes offline positive Seek time performance 0 9 30 0 no online positive Power-on hours count 30862 10 100 60 yes online positive Spin retry count 0 12 100 0 no online positive Device power cycle count 615 191 100 0 no online positive G-sense error rate 0 192 100 0 no online positive Power-off retract count 77 193 37 0 no online positive Load cycle count 638702 194 171 0 no online positive Temperature 32 Lifetime min/max 10/56 196 100 0 no online positive Reallocated event count 0 197 100 0 no online positive Current pending sector 0 198 100 0 no offline positive Offline uncorrectable 0 199 200 0 no online positive Ultra DMA CRC error count 145240 223 100 0 no online positive Load/unload retry count 0
であればfsckをかけてチェックをかけて…ってそこでkernel panicしてるのか。とりあえず試しにディスクを引っこ抜いて母艦に繋げてそちらで動かしてみる。
$ sudo fsck_ffs -fy /dev/wd3a ** /dev/rwd3a ** File system is already clean ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=11210928 CLEAR? yes UNKNOWN FILE TYPE I=11210929 CLEAR? yes UNKNOWN FILE TYPE I=11210930 CLEAR? yes : :
おぉ動いた。そしてエラーまみれだ orz
そしてfsckをかけ終わったディスクをCubieBoard2に戻したら無事に起動するようになったのでとりあえずそのまま動かすことに。NetBSD 8が出たころに改めてディスク診断をかけてクリーンインストールかなー。
サイクルスタイル2017とか
cycle-styleとかいうのを数日前に偶然知ったんでせっかくなので行ってきた。場所が横浜で遠かったけど折り畳み自転車も多く試乗もできるのでミニベロ好きとしては大満足です。（そしてショップで色々買い込む）
赤レンガ倉庫の奥に海が見えたので行ってみたら海上保安庁のあきつしまさんが停泊してた。後で調べたらしきしま型の2隻（1番しきしま、2番あきつしま）は巡視船として世界最大級の大きさなんだそうで。領海はクッソ広いわ隣りの国は益々キナ臭いわで大変そうだけどがんばってください。
こっちは旧横浜船渠株式会社第一号船渠（重要文化財）で展示されている日本丸（重要文化財見込）。帆船をなんてそうそう見ないけどこれはカッコいい。
旧横浜船渠株式会社第二号船渠（こっちも重要文化財）。第一号船渠と違って水が入っていないのでドックがどういうものなのかよくわかる。
