HP Stream 11 d012TU その後

しばらくSD Card上のLinuxをメインに使ってますが、ディスク周りで少し設定をいじりました。やっぱりスワップが始まると耐え難い重さになるので。

まずは何はともあれzram。

$ apt-get install zram-config

でインストールしてますが、そのままだとメモリの半分をCPUの数で分割したzramが作られるので、/etc/init/zram-config.conf を直接編集してメモリの1/4だけ使うように変更してます。普通に使ってる分にはデフォルトの設定が良いような気がしますが、kvmで1GBとか持ってく時には標準設定はイマイチかな、と思って。結果256MBのzramが2つ。加えて内蔵ディスクから1GB工面して低優先度の2次スワップに当ててます。けど、やっぱりディスクまでいくと重いので、潔くOOM Killerのお世話になるのが良いのかもしれません。

あと、preloadとprelinkも。

$ apt-get install preload prelink

でインストール。prelinkはChromeに使ってます。あまり知られてない気がしますが、$HOME/.local/share/applications/chrome-app-list.desktop を使うとUbuntuのUnityでもChromeのLauncherが使えます。が、そのままだとメニュー開くのに時間かかっちゃう。

$ prelink /opt/google/chrome/chrome

みたいな感じでprelinkしとくと起動がかなり早くなる。他にも頻繁につかう共有ライブラリ使いまくりな大きめのアプリならprelinkしておくと結構幸せ。

カーネル周りの設定は/etc/sysctl.confにて。

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.swappiness = 20

あたりの設定を入れてます。ともかくディスク（SD Card）が遅いので、なるべくdirtyなページはこまめに吐き出すように、と。でないとメモリ足りなくてディスクキャッシュを追い出すときに固まりがち。あとswapinessは低め。zram入れてからはzramが緩衝材になってくれてるんで不要かもしれませんが、zramない状態だとディスクが常にスワップ関連のI/Oでフルフル。たぶん閾値付近で同じページが出たり入ったりな状態。

ファイルシステム周りはtmpfsを適宜導入してvm.dirty_*設定の副作用をキャンセル。
tmpfs           /var/log        tmpfs   defaults,noatime,size=16m 0      0
tmpfs           /var/tmp        tmpfs   defaults,noatime,size=16m 0      0
tmpfs           /tmp            tmpfs   defaults,noatime,size=64m 0      0
あと/なんかにもnoatimeのマウントフラグを指定しちゃってます。ファイル読むときに、あしあと付けないモードですね。ディスク不可軽減の足しに、ということで。

ベストな設定ってほどにはチューニングしてないんだけど、標準設定よりは顕著に快適になりました。

（補足）/tmpはアップデート時に大きなファイル持ってくる子が多いので、やっぱりtmpfsはやめました。あとbluetoothが動いてないことに気づいて、こいつを試してみたけどNG。最新のkernel branchでも該当チップのsubverが未対応っぽい？無理やり別ファーム読ませたりするとデバイススキャンが動くくらいにはなったけど、同時にWifiが不安定になるので無理せず諦めました。

Chrome 43 beta with Web MIDI

こちらでもアナウンスしたのですが、大切なことなので日本語でも言っておきますよ。しかも、もっと詳しく。

最新のChrome BetaでWeb MIDI APIが標準でサポートされるようになりました。このAPIはAndroid版と全てのデスクトップ版Chromeで利用可能になります。

MIDIはご存知の通り30年以上の歴史を持つ古い規格。よくSMFと混同されがちなのですが、音楽ファイルというわけではなく楽器同士の通信プロトコルです。その通信内容を時間情報とともにダンプしたファイルがSMF。演奏情報を記録する事でカラオケや着メロの楽曲データとして利用されてきた経緯もあり、その印象から（チープな音で演奏される）音楽ファイルとして誤解されがちですが、あくまでもそれは一応用、という事で。

なんでそんな古いものをまた……と思ったそこのあなた。Webも25年近い歴史を持つ古い技術です。垣根を超えてつながることで発展してきた、という意味ではどちらも似た志を持っており、絶妙な割り切りが的を得て発展・成功した仲間です。ここでこの2つが分野を超えて繋がることで新しい応用が広がるかと思うと、なんかワクワクしませんか？

Web MIDI APIはJava ScriptからMIDIの入出力を可能にするAPIです。具体的には電子ピアノやシンセサイザーなどのキーボード類、電子ドラム、あるいはDJ機器からの入力を受け取ることが出来るようになります。一方で、各種電子楽器に対して演奏情報や設定情報などを送信することが可能になります。これにより

• 電子楽器の音色管理ソフトウェアをWeb上で構築
• サイトを通じて自動演奏ピアノに曲を提供
• Web Audioなどで作られたソフトウェア音源をキーボードから演奏
• 演奏情報をWebからリアルタイム配信
• Web GLなどを使って作成したVJソフトを演奏情報に同期させる

などがWeb標準技術を用いて実現可能となります。すでに多くの開発者がソフトウェア音源を作ったり、DAWソフトを作ったりしていますが、これからも多くの応用が生み出されていくと期待しています。

今現在ではWeb Audioの実装で先行していたChromeのみがWeb MIDI APIをサポートするブラウザとなっています。が、仕様はW3Cで標準化されており、同じくWeb Audioの実装を持ったFirefoxも開発を進めているところです。IEは今まさにWeb Audioの対応を進めているところであり、今後に期待と言ったところです。

HP Stream 11 d012TU

3万円以下で買えるカジュアルなラップトップ。HPのラップトップはChromebook 11も気に入って使い続けてるんだけど、こういうカジュアル路線が個人的な趣味にドンピシャ。って事で、最近タブレット以外に実機を持ってなかったWindowsの動作確認用に1台入手したのでした。

でまぁWindowsとか言いながらも、おもむろにUbuntuのインストールを始めるわけですが。内蔵ストレージ32GB、メモリの4GBとなるとWindows上に仮想環境作ってもあまり現実的ではない。という事でSD Cardにインストールしてdual boot環境を作ることにしました。実は購入前にこの辺のページを見ていてLinuxフレンドリーなハード構成であることは確認済みなのでありました。

で、いざ作業を始めてみるとUEFIがSD Cardには対応していない様子。USBからUbuntuをインストールしてみたものの、GPTでパーティション切ってSD Card内のEFI Systemパーティションにインストールを指定しても、インストーラの判断かWindows Boot Managerがいる内蔵ストレージのEFIにインストールされちゃう。この時点で一応BIOSからUEFIのBoot設定でUbuntuが選べるようになるのだけど、Grubの起動はするもののLinuxの起動で停止。Grubのコマンドに降りて確認してみると、この時点でSD Cardのストレージは見えていなかった。USBからはインストーラが動いたくらいなので当然Bootは可能。という事でUEFI Shell環境をUSBから起動してみると、やはりUEFIレベルでSD Cardが見えていなかった。

という事で、SD CardからのBootは諦めて別案2つ。

1. USB 3.0にストレージ挿してインストール：USB 3.0なら高速なストレージが使えるので、USBに逃げるのは悪い手ではない。けど、モバイルで出っ張ったデバイスにrootファイルシステムを置くのは少々不安。ちょっとぶつけただけでpanicしそう、というか昔LOOX Uを埼京線の通勤で使ってた時によく遭遇した。
2. /bootだけ内蔵ストレージ：/bootなら512MBもあれば十分なサイズなので内蔵ストレージを圧迫する事もない。KernelとinitrdさえUEFIから見えればkernelは起動するし、initrd内に必要なドライバが揃っていればLinux全体のbootにも支障ないはず。

で、案2を採用して作業。Windows 8.1側からdiskmgmt.mscを使ってCドライブのサイズを縮小。512MB分の空き領域を作った。続けて128GBのSD Cardを突っ込んで外付けDVDドライブから14.04.2のインストーラ起動。パーティション設定になったら、さきほど開放した内蔵ストレージ（/dev/mmcblk0）から真ん中にぽっかり空いた先ほどのスペースを使ってext4を/boot用に確保（/dev/mmcblk0p5）。あとは/dev/sdaとして見えてるSD Cardに4GBのswapを作って、残りは全部/用にext4で確保。boot loaderのインストール先は指定方法として/dev/mmcblk0（MMC MBG4GC）を指定すべきなのか、/dev/mmcblk0p1（Windows Boot Manager）を指定すべきなのか迷ったけど、どうせ指定を無視してWindows Boot Managerの横にインストールされることを事前の試行で知っていたのでSD Cardである/dev/sdaを指定。
再起動後は電源入った直後にESC連打でメニュー。F9からUEFIのメニューにいけばUbuntuがGrub経由で起動できる。F10でBIOSからUbuntuをデフォルトにしておけば、Grub経由でWindowsもchainloadできるので便利。

その他、デバイス周りの注意点。

• 内蔵無線LANは初期の14.04ではサポートされていない模様（from まさおのブログ）。14.04.2では問題なく使えてたけど、数時間に1度くらいの頻度で接続が切れて、無線アクセスポイントの認証に失敗するようになる。上記ブログで紹介してるGithubのリポジトリから最新版（2015/4/19現在）をとってきてインストールしたところ安定して動作している模様。
• 初期状態＆インストーラではタッチパッドに問題があった。カーソル移動くらいなら大丈夫なんだけど、一度クリックするとそれ以降クリックが効かなくなる。マウスの設定でタッチを一度無効にしないと外付けマウスも効かなくなるので注意。インストール中は外付けマウス使いました。この情報によればKernel 3.19で修正されているらしいが、こっちの情報によると3.16。手元ではインストール後の3.16.0-34-genericへのカーネルアップデートで治ったので、バックポートされたのかも。
• インストール後にバッドノウハウページ発見。なかなか良い情報源。輝度調整ボタンとか音量調整、飛行機ボタンなんかは、14.04.2では標準で使えてます。
• Caps Lockはこっちの方法で。swapcapsにするとShiftとの同時押しで誤動作するので潔くnocapsにしました。
• BIOSからVT有効にできるのでKVMとかVirtualBoxとか入れて遊ぶのも一興。とりあえずHaiku OSのx86安定版とtrunkのx86とx86_64を入れてる。

という事で、なかなか良いマシンなのではないでしょうか、と。

c9save

僕はCloud9のヘビーユーザーだったりするわけなんですが、半年ほど前に某プロジェクトのリポジトリを某所のhgから某所のgitに移行した際、未commitなテスト用データを手違いで削除してしまいました。で、なんとなくディレクトリを眺めていると

workplace/.c9revisions

ってディレクトリがあって、ここにworkplace以下に置かれているファイルに関して.c9saveという拡張子のついた編集履歴ファイルがあったりします。内容としては、1編集履歴がjson形式で改行なしの1行に詰め込まれてて、それが編集履歴の数だけ行で並んでいるだけ。

各編集履歴は
ts: 更新時刻（JSならnew Date(ts)すれば戻せるUNIX時間）
length: 編集後のファイルサイズ
patch: 編集情報のArray（だけど、必ずサイズは1。バグでうっかり余分にネスト？）

編集情報はさらにパッチ情報のArrayになってて、パッチ情報は
start1: 編集開始位置
start2: 編集終了位置だと思うけど、基本的にstart1と同値
length1: 編集によって削除される文字数
length2: 編集によって追加される文字数
diffs: 差分情報のArray

差分情報はサイズ2のArray（いわゆるpair）になってて、最初の要素が差分モード、2つ目の要素が差分データ。差分モードは-1が削除で1が追加。0がイマイチわからないのだけど、たぶんスキップか置換。length1とlength2がモード0のサイズを両方に加味しないと辻褄が合わなくなるので、たぶん置換？

まぁ、そんなわけで、ざっくりコードを書くとそこそこデータの復元はできるんだけど。どうにも途中で落ちてるトランザクションとかあるような気がする。存在しないデータを削除しようとする編集データとかが出てきて、フォーマットの解釈が間違ってるとしてもこうはならないだろ、みたいな。まぁ、復元したかったデータはおおよそ復元できたので良いけど。

ちなみにこの辺の履歴システムは最近になって実装が変わったみたいで、最近のファイルは.c9revisions使ってません。ちょろっと試した限り、うっかりファイルを消しても同じファイル名で作り直すと、昔のデータも含めて履歴（File > Show File Revision History）から辿れるみたい。ただ履歴データはわかりやすいところには置いてなくて、どっかのdbにバイナリで突っ込まれてるような雰囲気。

と言うことで、どうでも良いメモでした。誰かのお役に立てばラッキー、くらいな。

2015年1月の読書

1月はbooklog的には30冊とかなってるけど、大掃除の際に未登録だった本を何冊かまとめて突っ込んでるので、読んでるペースは実質同じくらいのはず。今年もモチベーション維持のために当面は面白かった物をピックアップしていこうかと。

教養

まずは先月の続きでファスト＆スロー。著者のノーベル賞に繋がったプロスペクト理論についても登場する下巻。下巻は特に意思決定におけるバイアスの除去について重要な知見を与えてくれます。経営者、実業家、会社の幹部の人たちは当然知っておくべき知識だと思いますが、あまり浸透していないのかな。

逆に広告代理店や弁護士、代議士なんかは、この辺りの知識を巧みに使って商売してるのだから、世の中ちょっと怖いな、と思いました。バイアスを避けるためではなく、意図的にバイアスの罠にハメるような応用しかされていない。ちょっと表現を変えるだけで、一般人の判断を麻痺させる事ができるわけだから、ちょっとした殺戮器官ですよね。

それこそ義務教育で主要科目として教えておかないと、まともな民主主義は機能しないな、と思いました。

二つ目は標準模型の宇宙。これも良書だった。理系大学生レベルなら安心して読める程度に書かれてます。図解知識本よりちょっと本格的に素粒子物理について理解するには良い本。ゲージ理論の概要理解に向けて各章で必要な知識を身につけ、最後に現状での実験物理の限界について書かれて終わる感じ。次の世代の加速器がエネルギー10桁上げないと意味あるデータが取れない、とか言われると、ちょっと今後の劇的な進展は望めないのかなぁ。本の中で2010年までには発見できるはずと言われてたヒッグス粒子も正式な発見は2013年にずれ込んだし。素粒子物理の研究がサチってくるとなるとSFな未来を夢見る者としては寂しいですね。

次は政治経済って事で池上さんの知らないと恥をかく世界の大問題。シリーズになってて、これは1冊目。政権交代直後に書かれた本なので、その辺に対する期待に関しては残念でした、という感じですが。

アメリカ中心の経済の終焉、という前提で今後の世界の動きを読んでいく。宗教の違い、資源の流れ、教育のあり方などに焦点を当てています。

気軽に読めて、わりと面白かったので、続きもボチボチ読んでいこうかと。

で、教養系の最後はプラトンのソクラテスの弁明とクリトン。ソクラテスの弁明だけ読むと、ソクラテスって本当に実在したのかなぁ？という印象がありました。ツァラトゥストラのイメージに近い……まぁ、奇人ですね。

内容としては、無神論により若者をたぶらかしているという理由で死刑の裁判にかけられた時の弁明演説の記録、という体裁ですが。実際はプラトンによる創作要素も多分にあるのでしょう。

デルポイの信託で世界一の賢者と言われ、反例を示すために賢者、エンジニア、アーティストを戸別訪問。賢者に対しては、「自分の知らないことがある」事を知っている自分の方が賢いとし、エンジニアに対してはなるほど専門知識では負けるが、それによって全てにおいて賢いと勘違いしている点で愚かだと批判、アーティストは自分の作品について、まわりの批評家の方がよほど作品を理解しているため、信託を伝えるための巫女同然で本人自身には価値がないと見下す。結果、国中の知識人に嫌われ、告発されてこの裁判。見事なとんでもっぷりです。基本、死刑には狼狽えず、裁判でも媚びず、と毅然とした態度で望むわけですが、判決後の「お前らは呪われる」的発言はちょっとした綻びですね。

クリトンはその後の話。死刑執行前夜に脱走を進めるクリトンと、それを断固として受け入れないソクラテス。国家と法についてあれこれ議論して、死刑を受け入れる、と。しかし、当時ソクラテスは70歳と聴くと、そこまでの迫力は感じないかな。そういう意味でも史実なのかもしれないけど。

どちらかというと対話篇としての芸術的な価値というか。力強く迫力のある文体が魅力でした。

娯楽

最初の一冊はこんなにも優しい、世界の終わりかた。たぶんbooklogで作業してたら目について図書館キューに入った本。娯楽小説としては久しぶりのお気に入り。実に見事なタイトルで。現代に生きる人の心を文字通り洗い流すような、素晴らしい話でした。本の主題は冒頭ですぐに出てきますが「限りある生命を強く意識した時、人間は優しくなれる。誰もが平等に死んでいくのに、どうしてみんな虚栄心に蝕まれながら、他人を傷つけて生きていくんだろう」そんな素朴な思いを最後まで貫いて書かれた話。つまらない文章でまとめてしまえば綺麗事のように見えてしまうかもしれませんが、そんな事実をたんたんと、それでいて心に迫るように訴えてくる。悲しい話なのに、読んでいてとても暖かくて優しい気持ちになり、何度も涙を流してしまいました。

（海外出張中に読んだので寂しくなってしまった……）

話の雰囲気としてはファンタシーというかお伽話のような不思議な空気に包まれているのですが、ときおり心理学や進化論にも思いを寄せてしまう、そんな描写が妙に心を現実に引き止めて、単なる物語以上の物として心に焼き付きました。

技術的な面では、構成にも凄く感心してしまって。とくに1章から2章に移る展開は見事だな、と思わず読んでいて震えてしまいました。葉鍵好きにはお勧め。

次の1冊は飛ぶ男……むしろがっかりの1冊なわけですが、敢えて取り上げたいな、と。まだ安部公房が存命していた頃、インタビューなどで執筆中として語られる事も多かった、いわゆる「スプーン曲げの少年」と呼ばれていた作品の遺稿。カンガルーノートより前から書かれてたにも関わらず、結局完成しなかったんですよね。残念。もっともカンガルーノートの完成度の高さを考えれば、あちらが世に出た事の方が結果としては良かったのかも。ともあれ、未完の遺作が出版されている事を知りドキドキしながら手に取りました。

冒頭から文字通り飛ばしてるな！って期待以上の出だしだったんですが、途中から文体も視点も乱れ出して、中盤ではメモ書きの寄せ集めレベルの体裁。これから話が始まるか……ってところで前半終了。

後半は同じアイデアを元にした別テイクにも見えるけど、どうにも文章が稚拙だし、何よりも話の構成が素人くさすぎるので、後から弄られた部分かなぁ。まぁ、ちょっとこれはないな、と。

出版を楽しみに待っていた作品ではあるけど、この状態だったら公開しないほうが良かったのでは、と思ってしまった。あるいは未完なら未完らしく走り書きを集めた資料集くらいの方が価値はあったと思う。まぁ、ファンとしては冒頭だけ読んでも物凄いインスピレーションは受けたわけですが。それでも寸止めどころか、ドタキャンくらいのガッカリ度なので、一言言わずにはいられない……といった所です。

娯楽最後の1冊は天冥の標。日本製のシリーズ物のSF。アンドロイドは電気羊の〜の話を書いた後に同僚から勧められてキューに入りました。ノリとしては日本falcomのRPG（特に英雄伝説系）が好きなら気に入るかも、って感じですね。なので僕も気に入ってます。無理に遠い未来を書かず、宇宙に移民してはいるけれど、諸般の事情で科学技術が停滞して宇宙大航海時代のロストテクノロジーに頼ってる……みたいな設定はアリかな、と思いました。主人公が医者というのも日常と非日常をスムースに繋げて話を展開するのに一役買っていると思いました。同僚から感想聞かれて真面目に答えたら「萌え」回答を期待されてたみたいで……ちょっとキャラの読みがずれたか。個人的には研修のセールスのお姉さんがめちゃくちゃ好みでした。関係無いですが。

芸術

Computer Historyは良くある類のレトロなコンピュータの写真集。安藤さんが紹介してたのを見て、表紙が気に入ったので勢いでジャケ買い的な。

交響曲入門は交響曲の形式についての説明を期待してたんだけど、どちらかと言えば成り立ちについての簡単な歴史的背景。あとは時系列にそって作曲家とエポックメイキングだった交響曲について、個別に評論。楽典はある程度納めてる人向けの本ですね。

とは言え、わりと知らなかった事も多くて。例えば、もともと交響曲はクラシックの本流じゃなかった、というのは意識した事なかった。声楽→協奏曲というのが境界を中心とした本流の流れで。舞曲→オペラ→シンフォニア→交響曲という傍流がベートーヴェンの深刻な取り組みで器楽の集大成という地位を確立。でも、ほとんど同時に完成形になってしまったので、その後も時間で見るとそれほど長い間クラシックの中心にいたわけでもない。

協奏曲の方は、ピアノ協奏曲みたいな単一ソロのイメージが強いけど、声楽からの流れで言う協奏曲は交互にソロを取るリトルネロ形式。Jazzとかわりと協奏曲に近いよなぁ。

ブラームスとブルックナーがほぼ同時期の人ってのも音しか聴いてないと想像もできない事実ですね。期待とは違ったけど面白く読めました。

Apple IIのハイレゾグラフィック

Woz様の回路、電車でぼけーっと考えてたら理解できたので忘れないうちにメモ。

よくある説明がこれ。柴田さんのApple II本（ブログエントリの末尾参照）より引用。VRAMから1バイトデータを取り出した時、最上位ビットが色セット切り替え、残りの7ビットで7ピクセル分の色を表現。ビットが0なら黒だけど、1だった時にはピクセルの位置によって決まった2色のうちの1色が表示される。連続して表示すると混ざって白く見えます、的な。

実はこの説明は厳密じゃなくて色は0/1のデータで表現しているわけじゃなくて、隣り合うピクセルの0→1、1→0というビットの立ち上がりと立ち下がりに反応して発色される。0か1かというのは本質的ではない。連続するビットに関しても、紫緑の場合と緑紫の場合だと色の滲み方が変わるはず。

で、原理の説明。まず色副搬送波の周波数が3.58MHz、それに対してドット・クロックが2倍の7.16MHzになっているのがミソ。適当な場所で1ピクセルだけビットが立ってる場合を考えるとドット・クロック2倍という事で色副搬送波と半周期だけ同期するパタン①と、同じく半周期だけど位相が180度ずれて同期する（値が反転している）パタン②の2種類が起きうる。ドット・クロックは2倍だけど、フリップした時に出てくる周波数成分はきっかり3.58MHz。これがそのまま色副搬送波の位相のずれとしてデコーダに検出される。

2ピクセル連続でビットが立った場合はどうかというと③と④で微妙に違う現象が起きる。③の場合は最初のビットの立ち上がりで色副搬送波と位相が一致、立ち下がりで反転。という事で連続するピクセルの左端が0度に相当する色に滲み、右端は180度に相当する色で滲む。で中間部分については色が打ち消し合ってるわけではなく、単に3.58MHzの周波数成分がほぼ0になってるため、彩度が0と判定されて白が発色される（位相差が色相、振幅が彩度に相当）。④の場合は逆で左端に180度、右端に0度の滲みがでるはず。

で、さらにApple IIでは最上位ビットを使って2つの色パレットを切り替えられる。これは14.32MHzの入ったFFを通して90度遅らせた信号を作り、遅延なしの2つの信号と合わせてセレクタに入力、最上位ビットでどちらか一方を選ぶことで実現できる。遅延付きが選ばれた場合は90度と270度、遅延無しが選ばれた場合は0度と180度の色相が取り出せるという仕組み。実際にはここで説明した位相差に加えて45度程度のずれがあり、それによって橙（45度）、紫（135度）、青（225度）、緑（315度）の4色が発色されるようです。周辺回路の遅延差がそのまま見えちゃってる感じなのかな？

という事で、本来は4割くらいの出力でカラーバースト出した上で、なだらかな輝度変化に3.58MHzに変調した色情報を載せるというのが正しいわけですが、手抜き回路では全力でカラーバースト出してやって、白黒デジタルなパタパタ出力のタイミングをちょっと前後に振ってあげるだけで独特のデジタルカラーが再現できるっぽい。これって実はマイコンでApple IIのビデオ回路を再現するのも夢じゃないって事ですね。14.32MHz-14bitのSPIが使えれば簡単に実現できる。VRAM1画面4KBって事を考えるとLPC1114あたりが適任。ビデオ専任のサブブロセッサとして任せてVRAM読み書きはメインプロセッサからI2C経由で。もしかしたらMegaZ-80Kで文字表示してたのよりタイミング的に楽かも。

Getting ARM OABI environment after such a long time :-/

Background

Unfortunately, I need to use very very old ARM OABI Linux environment to salvage data from XFS used by broken NAS. XFS is designed to be compatible between platforms, but for some reasons, it was incompatible only with ARM OABI environment. As you may know, OABI used a curious middle endian and struct layout. It's a very old story around Linux kernel 2.6.1x, or so. But, it affects my HDL-GT1.0 actually. Linux box can not show any file entries even if the disk can be mounted, and xfs_repair has no power to solve the problem.
FYI, the first KURO BOX that was sold in Japan also used ARM OABI, but later versions used ARM EABI, AFAIK.

Basic Strategy

Install debian 4.0 (etch) onto QEMU. Etch was already out of maintenance, but this is the best choice since HDL-GT1.0 looks using the Linux that was based on it. Also there is enough information to install it onto QEMU, e.g. this site (*1). Debian 5.0 (lenny) provided two versions, OABI and EABI for ARM, but the next 6.0 (squeeze) had only EABI. Anyway these all were out of maintenance. There were no benefit to choose others.

How to Install

I used Ubuntu 14.04.1 with QEMU that is installed by "apt-get install qemu". Basically, I just followed the way described at (*1). But some tricks were needed since the information was already out of date, and meanwhile, etch was removed from the official place.

Boot files

Two mandatory files distributed at (*1) were also removed. I found them from web.archive.org. I can download them, but it seems that the server sometimes return 404 against them. Anyway, if you were lucky enough, you will be able to get them.

• vmlinuz-2.6.18-6-versatile
• initrd.img-2.6.18-6-versatile

 Also, etch's initrd.gz was fetched from archive.debian.org/. The first initrd.img-2.6.18-6-versatile was used after installation, and the second initrd.gz was used on installation.

Use a manually chosen mirror site

Since etch was removed from the original place, I should specify an archive site manually. Mirror site name was archive.debian.org, and the path was default, /debian/. Here are some screen shots.

If you chosen one of default mirror sites, the installer will ask you to pick up a version of debian distributions from recent two or three choices that must use EABI.

Other Notices

In the page (*1),  that picture for the question "Continue without installing a kernel?" looks like the answer should be "<No>". But "<Yes>" is the right answer here.
Also, there is a critical issue to me. The provided kernel did not enable xfs support. So, even I install xfsprogs package and so on, xfs can not be mounted. According to the article, I can build kernel by myself. So, I'll try it next.
FYI, xfs_repair seems not working fine, but anyway it does not crash. Here, QEMU is launched with additional flags "-hdb HDL-GT-md13.img" here.

# apt-get install xfsdump  # it will install dependent xfs related packages including xfsprogs
# xfs_repair /dev/sdb  # it works somehow?

Kernel build

Let's build a kernel to support XFS. The system contains minimum set of packages. So, we need following packages to build the kernel at least. There are two choices, 2.6.18 and 2.6.24, but choose 2.6.18 that the original installation bases on.

# apt-get install make gcc linux-source-2.6.18 kernel-package build-essential libncurses5-dev initrd-tools

Then, prepare source files.

# cd /usr/src
# tar jxf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18

Kernel 2.6.18 has a config template file for versatile. Here, we use it as a baseline, then enable XFS support in addition.

# make versatile_defconfig
# make menuconfig

In the menu, enable a following items. I'm not sure if this is the exactly necessary and sufficient condition. But at least, it is sufficient:)

• Bus support ---> PCI support [built-in]
• Device drivers ---> SCSI device support ---> SCSI device support [module]
• Device drivers ---> SCSI device support ---> SCSI disk support [module]
• Device drivers ---> SCSI device support ---> SCSI tape support [module]
• Device drivers ---> SCSI device support ---> SCSI generic support [module]
• Device drivers ---> SCSI device support ---> SCSI low-level drivers ---> SYM53C8XX Version 2 SCSI support [module]
• File systems ---> Ext3 journalling file system support [module]
• File systems ---> XFS filesystem support [module]
• File systems ---> XFS Quota support [built-in]
• File systems ---> XFS Security Level support [built-in]
• File systems ---> XFS POSIX ACL support [built-in]
• File systems ---> XFS Realtime subvolume support [built-in]
• File systems ---> Filesystems in Userspace support [module]
• File systems ---> Pseudo filesystems ---> Virtual memory file system support (former shm fs) [built-in]
• File systems ---> Pseudo filesystems ---> Tmpfs POSIX Access Control Lists [built-in]
• File systems ---> Pseudo filesystems ---> Userspace-driven configuration filesystem (EXPERIMENTAL) [module]
• File systems ---> Native language support --> Japanese charsets (Shift-JIS, EUC-JP) [module]
• File systems ---> Native language support ---> NLS UTF-8 [module]

then save and exit the menuconfig. Let's build the kernel.

# make dep
# make modules && make zImage && make modules_install && make install
# mkinitrd -o /boot/initrd-2.6.18.img 2.6.18

Now dependent modules should be installed into the internal file system, and kernel and initrd images that can be specified on launching QEMU are created. The kernel image should be placed at arch/arm/boot/zImage, and initrd image is /boot/initrd-2.6.18.img as you specified at the last command. I copied them to the host machine via scp. After shutting down the emulated ARM system, launch the system again with these new images, as

# qemu-system-arm -M versatilepb -kernel zImage -initrd initrd-2.6.18.img -hda hda.img -hdb want-to-read-fs-in-xfs.img -append "root=/dev/sda1"

The resolution of the boot console is finer than the original, and linux logo is not used. But anyway, it boots. Once you login the system, it will support XFS correctly, and it is exactly the XFS that is not compatible with current XFS. In my case, I launched QEMU with "-hdb HDL-GT-md13.img", then it can mount the image correctly.

# mount /dev/sdb /mnt
# ls -l /mnt
drwxr-xr-x 6 root  root  88 May 16  2012 share
drwxr-xr-x 6 root  root  88 May 16  2012 spool

Yep!