CUBOXの話。残り。

前回まででいちおうOSの新規インストール（debian）過程は終了。
今回は余談というか、簡単に一人反省会ｗ

前回まででインストールしたdebian、いちおう問題なく使えたわけですが、何点かクリアできなかったところも。

一つは該当箇所でも書いたが、インストール行程でのディスプレイ表示の可否。

そこでも書いたけど、コンソールではなく、通常のディスプレイ表示でのインストール作業ができたケースがあったが、それを今に至るまで再現できてない。

いまこれを書きながらつらつら考えてるんだが、initrdのイメージをsqueeze用ではなくwheezy用使ってたからとか？うーんそれも違うような・・・。

インストール自体はコンソールでも問題はないんだけれど、やはり文字化けが頻出するとストレスではあるので、可能であれば通常のディスプレイ表示を可能にしたかった。

今後チャンスがあれば、切り分けは続けてみたいと思う。


次にカーネルのu-boot変換。

前回までで記載した行程では、標準添付のmicroSDからuImageをコピーして使った。
これでもちろん良いのだが、自身でカーネルイメージをダウンロードして変換したものでは起動できなかった。

いまはこれでよいが、このカーネルイメージが使えないバージョンになったときに、やはり自身で起動できるカーネルイメージを作れるようにはしておきたい。

そうするとソースからイメージをmakeすることになるかと思うんだが、そこでなんらかの手を加える必要があるということよね？

カーネルそのものはともかく、そこになにを加えなければならないのか？

というかそもそもそれが原因なのか？

そのあたりの切り分けもできればやっておきたい。
これは公式wikiで記載されている別ディストリビューションのインストールにトライしてみれば、見えてくるところもあるかもしれない。


で、別ディストリビューション・・・という流れでいくが―

じつはここが一番の鬼門だった、というか公式のwikiは鵜呑みにしてはいけないとあれほど(ry


いえね、debianうまくインストールできたことに気をよくして、公式wikiみてandoroidインストールしてみたんですよ、インストーラ一式zipになってて、DLしてただ実行すればいいみたいに書いてあったので。

なので落としたzipを展開してUSBメモリに入れて、cubox起動、どきどきわくわく。


・・・・・


起動しません（滝汗）


ちゅーか


SPIフラッシュからu-bootが消えやがったじゃねえか!?

え？　え？　え？

なんか正面のLEDランプも消えかけのように変わるし！？

電源入れてもなにも表示でてこない！？

あ、キーボード押したらなんか出てきたわ

え。bootstrap？

え？　え？

・・・・・

ということで、ここが一番びびったし、復旧までに苦労した。
ちゅーか、インストーラ起動しただけで、システムの根幹に近いファイル消されるなんて思わんわな、普通。

加えて復旧方法わかりづらいし。
公式のフォーラムでも同じ状態になった人がいたらしくて、罵っとる罵っとるｗ


ちなみにこのケースで参照すべきページは以下。

http://www.solid-run.com/mw/index.php/U-Boot_commands

最初このページがわからなくて。
なんせu-boot自体を復旧させるのにu-boot commandsなんちゅうページみるとは思いませんわな。
（思い込み恐るべしですな）

u-bootの復旧の方法を簡単にまとめると―

・u-bootの復元元ファイルを用意する。（2種類）
・tera termを使って（XMODEM転送）、シリアル経由でファイルをcuboxへ転送する。
・起動したu-boot環境で転送したイメージをSPIフラッシュへ書き込む。

これだけのことなんだが、公式wikiでは同じページ内に記載があるにもかかわらず、記載箇所が散ってて、わかりづらいわかりづらい。
（まあ最初から最後まできちっと読め！という話だが、あせってると必要項目しか見ないよね）

以下その状態を再現して、ファイルの転送過程だけだが動画にしてみたので、興味のある方はどうぞ。

動画の最後にもあるように自分は、SPIフラッシュへの書き込みコマンドがわからずに苦労した。

要は上記の公式wikiのページ内にその記載があったんだが、元々の内容から参照するであろうFlashing Via a Serial connectionという項目には微塵もその記載がない。

要は同ページ前のほう（Reflashing U-Bootの各項目）に書いてあるでしょ、ということらしいが

見ないわな、普通？

結局どうすればよいかというと、まずシリアル接続でイメージを転送・起動し、USBメモリからもう一つのイメージを読込・書き込むという2段階での復元、ということらしい。

上記の動画の内容のように、まず復元用ファイルを転送し、u-bootでの起動を回復したあとで、もう一つのファイルを入れたUSBメモリをUSB端子0へ差し込んだ上で

・set filesize 0; set bootaddr 0x200000; set env_offset 0xc0000; set env_size 0x10000

・usb start

・fatload usb 0:1 ${bootaddr} u-boot-cubox_hynix_cubox_spi.bin

・if itest 0x${filesize} -gt 0x50000; then sf protect off; echo ‘Erasing…’; sf erase 0x0 ${env_offset};echo ‘Writing…’; sf write ${bootaddr} 0 0x${filesize};sf protect on;fi

と、こんだけ打たんといかんかったわけですよ。

というかこのやり方はもともと、システムが正常に起動している際のUSBメモリ使ったフラッシュ上のU-boot更新作業のやりかたっぽい。

今回再現動画作るのにはその方法でやって復旧したが、シリアルから読んだイメージだけで書き込み動作できるかやってみたができなかったので、この二段階での復旧をせざるを得ない模様。

あ、あとこのandoroidインストールがらみで注意しておきたいのは、公式wikiの以下の箇所。

http://www.solid-run.com/mw/index.php/Android_2.2_(Froyo)_on_CuBox

setenv arcNumber 3013
saveenv
reset

上記のダウンロードしたandoroid用インストーラを実行したあとに入力するような流れで書いてあるが―

このarcNumber変えるとLinuxは起動しなくなるぞ？

これはどうも本体のアーキテクチャを識別するためのコード番号らしいんだが、これに変えてしまうとandoroid用、ということになり、通常のLinuxディストリビューションでは起動途中で跳ねられるっぽい。

自分が確認した限りでは、デフォルトの（通常の）arcNumberは3905の模様。

書き換えてしまった場合は、上記と同じ書式で書き換えなおしてやる必要がある。


とまあ、いま現在思いつくところの反省点・注意点はこんなところか。

今後もいろいろと試してみたいと思うし、試せる要素自体もたくさんありそうだが、とりあえずのところ、今回はこれでおしまい。

苦労はしたが、机上の理屈だけのお勉強では見えないところがたくさん見えたので面白かった。

また別OSのインストールとかうまくいけば、レポートしてみたいと思います。