登場と共に瞬間的に話題をかっさらっていった zxLinux 。 おかげで GA 3D Engine のインパクトもすっかり消されてしまった感じ。 やられました。
ところがなぜか、それ以来話題にものぼらずほとんど動きもありません。
どこの Zaurus サイトでもあんまり 説明されていない zxLinux についてのあれやこれを、 いつものように解説してみます。
MI Zaurus 用の Linux である zxLinux は 2000年3月20日に突然発表されました。
ユーザーの誰一人予想もしなかった突然のできごとであり、 また各種メディアが zxLinux をニュースとして多数取り上げたことも 深く印象に残っています。
この Linux を開発したのは、そもそも ZaurusOS のカーネル XTAL を作った 会社 アックス(AXE) であり、 システムを知り尽くした故の実に巧妙な仕組みで動作します。 開発には SHARP 自体も協力をしていて、 公式のニュースリリースでも取り上げています。
何かと話題性もあり、何かと良いイメージが強い Linux なので、 メーカーとしてのイメージ戦略的にも、 そしてユーザーサイドでの盛り上がりが、 良い結果を生むことを期待しているのでしょう。
zxLinux は 3月の公開時にすでに、動く形として一式全部が公開されました。 カーネルがブートするだけでなく、 バイナリキットは簡易シェル上でデモが動き、 カーネルからライブラリまで含めたソースリストやデバッグツールまで 一斉公開です。 専用 webページの www.zxLinux.com やメーリングリストも用意されていました。
パソコンやインターネットを使っていて、 Microsoft の Windows95/98 や Windows2000 を知らない人はまずいないでしょう。 同じように、流行に敏感な人なら Linux という 単語も何度も耳に(目に)したことがあるはずです。
そもそも Windows は何かというと、 パソコンを動かすためのソフトウエア(??)です。
パソコンで使えるアプリケーションには、 メーラー、ブラウザ、ワープロなどなど種類も数もいっぱいあります。
ソフトの操作方法は、 マウスを動かしたり、キーボードで文字を入力したり、 ファイルの読み書きをしたり、アイコンを表示したり、 メニューを出したり・・・。 アプリケーションの種類を問わず、 基本的な操作は意外に結構同じことが多いのです。 そんなの当たり前だと思うかもしれません。
当たり前のことを当たり前としてできること、 これが実は難しい。 同じ Windows が載っているなら、 ソフトだけでなくて パソコンやメーカーが違っていても操作や使い方は同じです。
逆に共通になっていないとユーザーが困ります。 アプリケーションやパソコンによって基本的な使い方やマウスの動きが違っていたら 戸惑ってしまいます。
ユーザーだけでなく作る方も大変です。 パソコンとかアプリケーション毎に、 毎回基本部分をいちいち作ってたら、膨大な手間になってしまいます。
そういう共通なこと、基礎部分なことを幅広く面倒見てくれるソフトウエアのことを OS (オーエス) といいます。
Windows マシンと Macintosh は、微妙に操作が違います。 動くアプリケーションも異なっています。 この両者はパソコンが違うというよりも、 載っている OS そのものが違います。
OS は一種の文化であって、それぞれ操作や使い方、 見え方や用語、動くアプリケーションなど全部違います。 見えるところだけでなく、暗黙の了解や見えないところまで、 それぞれ独自のルールを持っています。
Linux というのは、そんな OS の一種です。 Linux には、Windows とも Macintosh とも違う、独自のルールと文化があります。
Linux がどうしてここまで話題になるのか、いくつかの理由が考えられます。 まず、Linux の利点として次の項目をあげてみます。
Linux は OS のソフトウエアそのものがフリーソフトウエアで、 ソースの公開を通じてインターネット上で開発が進められています。
インターネットはもともと 研究機関や大学に張り巡らされたネットワークでした。 また研究用に使われている OS は UNIX 系のものがほとんどでした。 インターネット自身、 インターネットを支えている大部分のソフトエアも、 そもそも Linux のように、誰でも自由に使えるオープンな考え方で作られてきたものです。
また、操作方法、動作するアプリケーション、考え方や使い方は、 非常に古くから使われている OS、UNIX の文化をそのまま受け継いでいます。 UNIX 用の豊富なアプリケーションが Linux で動くので、 古くから UNIX を使っている人、 ネットワーク用の強力なアプリケーションを使いたい人には魅力的です。
かつては高価な UNIX WorkStation でしか動かなかったソフトウエアが、 今ではパソコンで動いて個人で所有できるのですから。 (Linux 以外にも BSD系など PC で動く UNIX 系の OS は数多く存在します。)
このような Linux の魅力や利点を背景にした、 これらのオープンソース文化とユーザー間での盛り上がりを、 企業側も黙ってみているわけではありません。 あらゆる思惑を胸に秘めながら、インターネットと同じように 新たなビジネスのチャンスとして利用しようとしています。
ほとんど独占状態に近かった パソコン用 OS、Windows に対抗でき得る最有力候補として、 企業が一生懸命あとおしをしているわけです。
同じゲームをやるなら、 パソコン使うより専用機の方が操作も手順も簡単です。 遊びたいソフトの CD-ROM を入れるだけ。 コントローラーのボタンの数もキーボードほど多くありません。
操作を難しくしてわかりにくくする最大の原因は、汎用性と自由度です。 専用機として完成度を高めた方が、 ユーザーにとってもずっとわかりやすいし、コストを下げることができます。
Zaurus は SHARP が独自に開発した専用ハードウエアで、 この上で動く OS も Zaurus 独自のものになっています。 操作方法も動作するアプリケーションも パソコンとは完全に違います。 もともと Zaurus は、完成された専用機としての性質を持っています。 この上で既存のアプリケーションを動かす必要も、 OS レベルでの互換性を保つ必要もないからです。
それでも長年のユーザーのニーズに応えるために、 そして時代の流れと共に、Zaurus も高性能化し、 多機能化の道をたどります。 専用機としてはほとんど飽和に近い機能の詰め込みを経験した後、 MI Zaurus は、表面的にはインターネットに特化した専用機としての面を 強めることになりました。 同時に、内部的には一種の汎用機として 各種アプリケーションの動作に耐え得るような構造になりました。 いくつかの機能を後付可能に、また開発環境を公開して、 ユーザーもプログラムを作れるようにしています。 一見矛盾している二つの方向性を持つようになっています。
専用機として完成されたイメージは、 初心者やライトユーザーにアピールできます。 その反面、ちょっとでも動作が不安定だったり、問題があったりすると、 その責任は直接メーカーに跳ね返ってきます。
汎用機としてパソコンのような接し方をした場合、 問題が起こっても、原因がアプリケーションソフトウエアにあることは だいたい想像つきます。 そしてソフトウエアには、 必ずバグが付き物であることをユーザーはすでに学習しています。 ソフトウエアの交換は手間がかかるけど必要なものだけ取捨選択でき、 カスタマイズ可能です。 操作は難しいので敷居は高く、若干ユーザーを選びます。
Zaurus は、メーカー側の姿勢としては専用機です。 初心者向けに売る必要があるので、あまりパソコンのような 複雑さを表に出したくはありません。 一般のユーザーも専用機として接しています。
ところが、 時代の流れも中級以上のユーザーのニーズも、より一層の高性能化と、 多種なアプリケーションを動かすための汎用化(パソコン化)に向かっています。 メーカーとしても方針をある程度変更せざるを得なかったのでしょう。
その狭間で Zaurus の方向性は大きく揺れ動いています。 このあやふやで不安定な状態が、 メーカーとユーザーとのずれを生じさせていることになります。
時代の流れにも見事にマッチして、 話題性も十分、 ユーザーの要求にも応えることができる(はず!)。 メーカーとして zxLinux はまさに切り札であったと考えられます。 SHARP の協力も納得できます。
高度化、自由化、そして汎用化。 いわゆるパソコン化の要望に対してはきわめて高いレベルで応えることができます。 (ちょっと高すぎる)
Linux が動くことによって、 Zaurus は完全に汎用のコンピュータ路線を歩むことが可能になるわけです。
別の OS を動かすということは、 システム全体の管理責任者が変わってしまうということです。 同時にどちらか一方しか動くことができず、 さらに相互に同じアプリケーションは動きません。 文化そのものが違うのです。
パソコンですら、Windows の再インストールや OS の切り替えは再起動を伴い 非常にやっかいな作業です。
Zaurus 以外の他の PDA でも、Linux や BSD 等の移植は行われています。 ただしその多くは、本来の機能やもともとの OS との共存はできないのが普通です。 それどころか、パソコンのように HDD が無く、 RAM がストレージを兼ねているために複数の OS が同居もできない場合があります。 うっかり OS を入れ替えてしてしまうとメモリがすべて消えてしまい、 バックアップがないと元に戻すこともできません。
zxLinux の場合は、なんと ZaurusOS と完全に同居することができ、 本体の PDA 機能がそのまんま使える状態で Linux が動いてしまいます。 zxLinux 自体も内部だけで閉じておらず、 ZaurusOS の漢字変換やソフトウエアキーボード、 手書き認識などを活用しています。
XTAL は、ZaurusOS の中核として スレッドやプロセス管理、プロセス間の同期や通信、メモリ管理等を行っています。 そもそもこのマイクロカーネル XTAL を作ったところ自らが zxLinux の開発を行ったわけですから、 内部動作もしくみもすべて知り尽くした上での実装です。
zxLinux はハードウエア管理をすべて ZaurusOS に任せ、 入出力処理を自分では行いません。 zxLinux 自体が XTAL のプロセスとして動作し、 プロセスメモリの管理は XTAL が行います。 zxLinux アプリケーションも XTAL プロセスに展開されますが、 そのスケジュール管理は XTAL ではなく、Linux 側が行います。 XTAL で動く RT-Linux といったイメージでしょうか。
ちょっと難しくなったので簡単にまとめると・・・ zxLinux は ZaurusOS と効率よく共存してるので、 そのまんま本体機能も使えるし、少ないメモリとバイナリで動きます。
Zaurus で Linux を簡単に動かせるように、バイナリキットが用意されています。 配布用アーカイブのサイズはわずか 751Kbyte。 tgz (tar + gzip) を展開して 2.5M になります。
これは ZAC ファイルではなく、ZAC 展開後のファイル群に相当するので、 コンパクトフラッシュに直接転送する手段が必要になります。
| ZLNX.APL / ZLNX.BIN / ZLNX*.JPN | 合計 10Kbyteくらい | MOREソフトアプリケーションとして必要なファイル群。 常駐して ZaurusOS との通信も行う。 |
| ZLNXIMG.DAT | 2048Kbyte | Linuxファイルシステムのイメージ(ext2) |
| ZLNXKNL.BIN | 523Kbyte | Linuxカーネル |
動作する機種は今のところ MI-EX1 と MI-C1 です。 この 2機種は、MI Zaurus としてハードウエアの構成が 3世代目に相当し、 システム構成的に内蔵 RAM 容量が大幅に増えているからです。
動かない理由は RAM 容量だけなので、 今度新しく発売になった MI-P10 も、動作確認はとれていませんが 同じように動作するものと考えられます。 もし動かないとすれば、モノクロ化に伴う変更部分が必要になるくらいでしょうか。 (余談ですが、ブラウザでフレームのレイアウト表示が できるできないの境目も RAM 容量です)
| 機種名 | zxLinux | RAM容量 |
| MI-10 | × | 1M |
| MI-504/506/610/110/106 | × | 2M |
| MI-310/P1/P2/J1(igeti) | × | 2M |
| MT-200/300/BrowserBoard | × | 2M |
| MI-EX1 ICRUISE | ○ | 8M |
| MI-C1 | ○ | 8M |
| MI-P10 igeti | おそらく○ | 8M |
zxLinux の動作には、さらにフラッシュメモリカードが必要です。 MI-EX1 は Type2 の PCカード スロットなので選択の余地がありますが、 MI-C1 と MI-P10 は CF (コンパクトフラッシュカード) しか使えませんので、 以後コンパクトフラッシュを使うものとして説明します。
インストールにはパソコンが必要で、 ノートパソコンの PCカードスロットなど、 コンパクトフラッシュメモリを直接書き換えることができる環境があれば OK です。 無くても1つ1つのファイルをケーブルや光でカードに転送すれば実行できます。 アプリケーション開発の場合はさらに、パソコンの Linux 環境(intelのみ)が必要です。
インストールを実行する前に必ず、本体メモリやコンパクトフラッシュの バックアップを取って置いてください。 ノートパソコンなど、 PCカードスロットがあって、 コンパクトフラッシュを直接読み書きできる環境があれば比較的楽になります。
本体機能の「バックアップ/リストア」を使って 本体メモリのバックアップをカードに行います。 そのコンパクトフラッシュカードをパソコンに挿入して、 中身を全部ハードディスクにコピー保存します。
インストールと実行はまず zxLinux の使用条件 に納得した上で行います。 バイナリキットを展開してできたファイルを全部、コンパクトフラッシュの __zaurus フォルダに転送します。
すでに展開済みの状態なので、 Zaurus 本体にカードを挿入したら、 あとは MORE ソフト管理画面や MORE ソフトインデックスから ZxLinux アイコンをタッチして起動するだけ!!
こんなに簡単に install ＆起動できる Linux が他にあるでしょうか!?
終了するには [戻る] ボタンを押します。 その後、 他のアプリケーション画面に切り替えたとき画面がおかしい場合は、 いったん電源を [切] してから入れ直してください。 たいていこれだけで直ります。(リセットまで必要なことはまれ)
カーネルは起動後 /sbin/init を立ち上げ、 即座にコマンドシェルとして /sbin/zxsh が呼び出されます。 一応、ls、cat、pwd のコマンドも入ってますが、 すべて zxLinux 独自の簡易のものです。 PC と同じソースから移植されたものでは残念ながらありません。 その他に /games/4 という簡単なゲームが入ってます。
バイナリキットの中身を見てわかるように、入っているのは Linux ファイルシステムのディスクイメージとカーネルのみです。 ディスクイメージも 2Mサイズで、アプリケーションは上記の通りです。
当然 GUI はなく、コンソールにコマンドシェルだけなので、 知ってる人は感動の画面ですが、 わからない人は間違いなく一度立ち上げておしまい・・でしょう。
OS を動かすことそのものに魅力を感じる人もいます。 一見動作しそうにもないマシンで Linux を動かすことの達成感と技術的アピールは、 実用できるかどうかはどうでもよくて、 その結果だけを認めて欲しいものです。 (かつて PI ZAURUS で動かした ZauSH ＋クロスCコンパイラも似たようなもの)
だけどエンドユーザーの目としては、使い物になるのかどうか、 何が便利なのかだけがすべてです。 2000年 7月 16日現在、zxLinux はアプリケーションが全く存在しない OS だけのからっぽの状態です。
エンドユーザーから見て、利用価値は「他の人に自慢できる」以外 残念ながら何もありません。
それもそのはず、 今の zxLinux は開発者へ向けたリリースに過ぎないからです。
開発環境として、ソフトウエアを動かすプラットフォームとして、 選択肢が増えるのは良いことです。
簡単に動かせるバイナリキットはあるものの、 アプリケーションや動作環境は、 これから徐々に自分で整備していなければならないようです。
これからの zxLinux の発展と、開発系ユーザーのがんばりと、 多数のアプリケーションの登場に期待しましょう。
・・・・と、普通のニュースサイトやレビュー記事では、 ここまでで zxLinux の紹介はおしまいになってるのではないかと思います。 ところが実は zxLinux は ここからが本番 なのです。
zxLinux は、あまりに旬でかつ すごい! ネタ なのです。
だけど、使ってみました起動してみましたという話はあるけれど、 そっから先「アプリケーションを作りました」、 「zxLinux 用ソフトを公開しました」 という話はとんと耳にすることがありません。
ユーザーは誰も使ってないのでしょうか。 バイナリキットを起動してわかるように、 現状ではアプリケーションがないので 起動しても何もすることがありません。 アプリの登場待ち状態で、みんな待っています。 お互い待っています。待ちくたびれました。
これは Linux (UNIX系) に興味を持って使ってる人と、 MI Zaurus を活用したり開発しているユーザー層 がもともとずれていたからではないかと思います。 Zaurus 系ユーザーは UNIX が難しくてわからない、 Linux なら使ってみようと思う人も、 Zaurus の常識や使い方がわからない・・などなど。
また、MI Zaurus でユーザーが望むのは、 どちらかといえば普段使っていて「不便な点を直したい」コトです。 だから作る人も需要に応じて、 便利な本体機能を補うようなツール類がどうしても多くなってしまうのでしょう。
GA 3D Engine も、ほとんどアプリが ありませんので同じ状況かもしれません。
Linux は、UNIX も、そしてOSのいろいろなアレコレは、 やはり非常に敷居が高い代物です。 これから新たに始めようと思っても、 パソコンへの Linux install から始めなければなりません。 OS の install は Windows にしろ PC-UNIX にしろ、 時間がかかる上に 最初からすんなりいくものではなく、 ある程度の失敗を繰り返し、それなりの経験を積む必要があります。
普段 Windows で作業している人も多いと思いますが、その場合 もう一つマシンを用意するか複数の OS を同居させなければなりません。 ハードディスクを用意しなければなりません。
zxLinux を本格的に使って開発しようとしても、 すでに Linux 環境を使ってる人以外はいくつもの 手順が必要になってしまいます。 これらの作業を行うには、それなりのまとまった時間が必要です。
筆者の場合も、今では今ではすっかり Windows ユーザーで、 手元に Windows マシンしかありません。 これだけのおいしい Zaurus ネタで、しかも扱いやすい UNIX 系の内容なのに、 今まで zxLinux に手を出せなかったのはここに原因があります。 まず、Linux マシンの確保、そこから作業を始めることになりました。
敷居が高いといっても、技術系の方なら PC-UNIX を何度かインストールした 経験がある方も・・多いのではないかと思います。 またはすでに Linux 環境ができあがっているかもしれません。 だけどなぜ zxLinux でアプリケーションが作られないのか、 その原因は実際に試してみて、予想外の敷居の高さにあることがわかりました。
☆開発者向け唯一の情報源である「zxLinux開発ドキュメント V.0.3.2」 は間違いが多く不親切であること。
ドキュメント通りに進めても、ぜんっぜん動きません。 興味を持って開発してみようと思っても、 ここで挫折した方が多いのではないでしょうか。
今回実際に、zxLinux のアプリケーション プログラムをコンパイルして実行できるまで、 順を追って説明していきます。 Zaurus 本体で実行させるどころか、 コンパイルを通すまでにかなり苦労しています。 この解説が、 これから作ってみようという方の参考になればと思います。
まず開発用のマシンとして、PC 上の Linux 環境(intel版のみ)を確保します。 Pentium 133MHz、 RAM 32Mbyte、 HDD 1.6G という、 今では完全に非力のノート PC を Linux マシンにしてセットアップを行いました。
zxLinux お勧め(?) の TurboLinux (TurboLinux日本語版4.2) がちょうど手元にあったので、それをそのまま使います。 実はこのマシン、当初から PC-UNIX を入れようと思って、 HDD パーティションを半分(800M + 800M)に切ってありました。 最初の半分には Windows95 が入ってます。
HDD容量も少ない無いので X-WINDOW は入れません。 不要なパッケージは大幅削減し、必要に応じて追加することにします。 デフォルトではネットワークをうまく認識しなかったので、 一度カーネルを作り直して入れ替えます。 遅いマシンなので、カーネルのコンパイルに平気で数時間かかります。
手動でネットワークを立ち上げて、LANカードも認識しました。 デスクトップパソコン(Windows98) と、このノートPC(Linux) の2台しかないのでたいしたネットワーク設定じゃありません。 適当にローカル IP を割り振ります。
ネットワーク設定さえ終われば、 あとはノート PC を直接触る必要がありません。 置き場所を確保して、液晶モニタは表示をOFFにします。 Windows98 から Telnet (TeraTermPro) で繋いですべての作業を行います。
samba のパッケージを選択してあるので、samba の設定を行います。 /etc/smb.conf の設定を書き換えて、WORKGROUP と IP 設定、 HOMEディレクトリの設定を行います。 相手が Windows98 なので encrypt passwords も有効にします。 /usr/sbin/nmbd と /usr/sbin/smbd を手動でたちあげ、 smbpasswd でユーザーを追加します。
これで Windows98 から Linux マシンが普通に共有フォルダとして 見えるようになりました。 以後のファイルコピーは Windows98 から explorer だけで行うことができます。 ネットワークドライブを割り当てれば、 Windows98 上の DOS窓(dash) を使って、Linux マシン上のテキストファイルを Windows 用の vi (vim3) で直接編集することもできます。 (この使い方なんか変？)
zxLinux のアプリケーション開発に必要なファイル (2000/07/16 現在) は以下の通りです。
これを PC の Linux 上の /usr/local に展開します。 パーミッション設定が面倒だったので、 root (特権ユーザー)で行いました。 以後「#」を root でのプロンプト、「%」をユーザーモードでのプロンプトとします。 プロンプト以後の文字列は入力したコマンドを意味します。
# cd /usr/local # tar -zxvf zxdev-000318.tgz |
これで /usr/local/zxlinux というフォルダが作られます。
以後 アプリケーション開発は、個人ユーザー ( oga と仮定する) の ホームディレクトリで行うことにします。
「zxLinux開発ドキュメント V.0.3.2」 には PATH 設定を行うよう書いてありますが、とりあえず無視します。 (ちなみに zxLinuxドキュメントに書いてある path 設定は csh/tcsh 用なので bsh/ash/bash/zsh/ksh の場合はそのままでは使えません。 筆者は bsh 系を使っています。)
% cd % pwd /home/oga % mkdir src src/run % cd src/run % pwd /home/oga/src/run |
バイナリキットでは 2M 分のファイルシステムイメージ(Linux用ディスク領域) が付属しています。ちょっと少ない感じがするので、 「zxLinux開発ドキュメント V.0.3.2」を参考に 4M 分作ってみることにします。
# pwd /home/oga/src/run # dd if=/dev/zero of=ZLNXIMG.DAT bs=1k count=4096 # /sbin/mke2fs ZLNXIMG.DAT |
zxLinux開発ドキュメントでは /mnt にいきなり mount してましたが、TurboLinux の /mnt/cdrom や /mnt/floppy を隠してしまうので一個フォルダを作ることにします。
# mkdir /mnt/zimage # mount -t ext2 -o loop ZLNXIMG.DAT /mnt/zimage |
zxLinux開発ドキュメントに従い、必要なフォルダを作成します。
# mkdir /mnt/zimage/bin # mkdir /mnt/zimage/sbin # mkdir /mnt/zimage/etc # mkdir /mnt/zimage/dev |
デバイスを作ります。 zxLinux開発ドキュメント V.0.3.2 には「mknod 2 0 /dev/console」と書いてありますが、 どう見てもこれは間違いなので、以下のようにします。 (注: それでもまだ間違いがあります。あとで説明します)
# /bin/mknod /mnt/zimage/dev/console c 2 0 |
起動に必要なファイルをコピーしなければならないので、 バイナリキットの元のイメージを用意します。 これは /usr/local/zxlinux の下に展開することにします。
# cd /usr/local/zxlinux # tar -zxvf zxlinux-000318.tgz |
これで /usr/local/zxlinux/zxlinux-000318 というフォルダができました。 中身はバイナリキットのファイル群です。 元のイメージをマウントすることにします。
# mkdir /mnt/zimage_org # mount -t ext2 -o loop /usr/local/zxlinux/zxlinux-000318/ZLNXIMG.DAT /mnt/zimage_org |
ここで df を取ると、こんな感じになります。(サイズは若干異なります)
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda6 700482 636461 27836 96% /
/dev/hda1 796064 447600 348464 56% /dos
/usr/local/zxlinux/zxlinux-000318/ZLNXIMG.DAT
1979 681 1196 36% /mnt/zimage_org
/home/oga/src/run/ZLNXIMG.DAT
3963 13 3746 0% /mnt/zimage
|
必要なファイルをコピーして、umount します。 これで起動可能なファイルシステムのイメージができたはずです。
# cp /mnt/zimage_org/sbin/* /mnt/zimage/sbin # ls -l /mnt/zimage/sbin total 250 -rwxrwxr-x 1 root root 28851 Jul 17 22:05 cat* -rwxrwxr-x 1 root root 36814 Jul 17 22:05 dbg* -rwxrwxr-x 1 root root 50798 Jul 17 22:05 init* -rwxrwxr-x 1 root root 49867 Jul 17 22:05 ls* -rwxrwxr-x 1 root root 30011 Jul 17 22:05 pwd* -rwxrwxr-x 1 root root 50798 Jul 17 22:05 zxsh* # umount /mnt/zimage |
zxLinux テスト専用に、 32M のコンパクトフラッシュカードを1枚使うことにしました。 すでにバイナリキットを転送して、 MI-C1 上で zxLinux が起動することを確認してあります。
TurboLinux はノートPCにインストールしたので、 PCカードスロットが認識できれば そのまま読み書きをすることが可能です。 PCカードアダプタを使って、ノートPC にそのまま挿入してみます。
カードマネージャーがちゃんとフラッシュカードを認識してくれました。 コンパクトフラッシュカード (/dev/hdc1 に割り当てられた)をマウントして 読み書きを行います。
# mkdir /mnt/cf # mount -t msdos /dev/hdc1 /mnt/cf |
書き込みはうまくいきました。 が、なぜか eject するとカードマネージャーがハングアップしてしまいます。
# umount /dev/hdc
# /sbin/cardctl eject 1
: エラーメッセージ
|
一度ハングアップすると、cardctl reset しようが何しようが 挿入したカードを再認識しなくなってしまいます。 仕方ないので、コンパクトフラッシュへの転送は別の手段を使うことにします。
手持ちの WindowsCE ハンドヘルドPC (WindowsCE 2.11 HPC/PRO 3.01) に コンパクトフラッシュスロットが付いてるので、これを代わりに使ってみます。
まず WindowsCE HPC を ActiveSync3 で接続して、 Windows98 のデスクトップマシンをパートナー関係にします。 これを LAN カードで接続して、 WindowsCE HPC にもネットワーク設定を行います。
| WindowsCE は名前解決に WINS か DNS を使うようです。 LAN 直結環境だと IP を引けないのでうまく認識できません。 こんな時は母艦の IPアドレスを WindowsCE の WINS サーバーの欄に むりやり書き込んでやるとうまくいくようです。 |
ActiveSync を使えば、LAN 接続でモバイルデバイスを開いて、Windows 上から WindowsCE HPC のファイルシステムを参照することができます。 この方法でコンパクトフラッシュメの読み書きも可能です。
Windows98 上の explorer を使って、samba の Linux 上の ZLNXIMG.DAT を、 WindowsCE HPC のコンパクトフラッシュスロットのカードの __zaurus フォルダに書き込むわけです。
ようやくコンパクトフラッシュに、 ファイルシステムイメージを効率よく転送する手段を確保できました。 作成したイメージを MI-C1 で起動してみます。
マニュアル通りに作ったはずなのに、 なぜかカーネルブートのあと止まってしまいます。 プロンプトが表示されず何もできません。 どこに原因があるのかさっぱりわからないので、 /etc /usr /tmp など、必要そうなフォルダを作ってみたり いろいろ試しました。
起動する元のバイナリキットのイメージと中身を比較してみると、 /dev/hda というものがあります。(なぜかキャラクタデバイス)
# ls -l /mnt/zimage_org/dev total 0 crw-rw-rw- 1 root 6660 4, 0 Feb 10 02:48 console crw-rw-rw- 1 root 6660 150, 0 Feb 10 02:48 hda |
これを mknod してみてもやっぱり変わりません。 何度か悩んだ末、 ふと、最初に作った console デバイスのメジャー番号が 違ってることに気が付きました。 zxLinux開発ドキュメント V.0.3.2 では、メジャー番号が 2 になっています。 バイナリキットのイメージでは 4 です。 次のように作り替えてみます。
# rm /mnt/zimage/dev/console # /bin/mknod /mnt/zimage/dev/console c 4 0 |
これでようやく、起動するファイルシステムイメージを作ることができました。 ちなみに /dev/hda は無くても構わないようです。
早速簡単な C のコードを書いてみます。
/* zrun.c */
#include <stdio.h>
int
main()
{
printf( "zxLinux\n" );
return 0;
}
|
コンパイルする前に、 zxLinux開発ドキュメント V.0.3.2 を参考に Makefile を書いてみます。 この Makefile を使えば、 zxLinux開発ドキュメントにあるようなシェルの PATH 設定が不要になるはずです。
# Makefile ZTOP = /usr/local/zxlinux TARGET = zrun ZOBJ = zrun.o LDFLAGS = -lm CFLAGS = -O ## ---------------------------------------------------------------------- all: $(TARGET) ## ---------------------------------------------------------------------- ZBIN = $(ZTOP)/bin ZLIB = $(ZTOP)/sh-hitachi-elf/lib ZINC = $(ZTOP)/sh-hitachi-elf/include ZCC = $(ZBIN)/sh-hitachi-elf-gcc ZLD = $(ZBIN)/sh-hitachi-elf-ld ZSYSLIB = $(ZLIB)/prochead_main.o $(ZLIB)/crt0.o ZCFLAGS = -I$(ZINC) ZLDFLAGS= -L$(ZLIB) $(TARGET): $(ZOBJ) $(ZLD) -o $(TARGET) $(ZLDFLAGS) $(ZSYSLIB) $(ZOBJ) $(LDFLAGS) .c.o: $(ZCC) -c $(ZCFLAGS) $(CFLAGS) -o $@ $< .cpp.o: $(ZCC) -c $(ZCFLAGS) $(CFLAGS) -o $@ $< .c.S: $(ZCC) -S $(ZCFLAGS) $(CFLAGS) -o $@ $< clean: rm -f $(ZOBJ) |
なぜかコンパイルが通らずに、 大量の undefined reference が出ます。 どうやら FPU ライブラリらしいので、gcc のコンパイラライブラリを探します。 とりあえず次の変更で undefined reference は大幅に減りました。
# Makefileの修正点 : 略 ### 修正 LDFLAGS = -lzxl -lc -lm -lgcc : 略 ### 追加 ZGCCLIB = $(ZTOP)/lib/gcc-lib/sh-hitachi-elf/2.95.2 ### 修正 ZLDFLAGS= -L$(ZGCCLIB) -L$(ZLIB) |
これでもまだ謎のエラーが出ます。
% make /usr/local/zxlinux/bin/sh-hitachi-elf-ld -o zrun -L/usr/local/zxlinux/lib/gcc-li b/sh-hitachi-elf/2.95.2 -L/usr/local/zxlinux/sh-hitachi-elf/lib /usr/local/zxlin ux/sh-hitachi-elf/lib/prochead_main.o /usr/local/zxlinux/sh-hitachi-elf/lib/crt0 .o zrun.o -lc -lm -lgcc /usr/local/zxlinux/bin/sh-hitachi-elf-ld: warning: cannot find entry symbol star t; defaulting to 00001000 /usr/local/zxlinux/sh-hitachi-elf/lib/prochead_main.o(.text+0x4): undefined refe rence to `__ghsbegin_shadow' /usr/local/zxlinux/sh-hitachi-elf/lib/prochead_main.o(.text+0x10): undefined ref erence to `__ghsend_data' /usr/local/zxlinux/sh-hitachi-elf/lib/prochead_main.o(.text+0x14): undefined ref erence to `__ghsbegin_shadow' /usr/local/zxlinux/sh-hitachi-elf/lib/prochead_main.o(.text+0x18): undefined ref erence to `__ghsbegin_bss' /usr/local/zxlinux/sh-hitachi-elf/lib/prochead_main.o(.text+0x1c): undefined ref erence to `__ghsend_bss' make: *** [zrun] Error 1 |
いろいろ悩んだ末、 シンボル値とエラーから考えるに ld の elf フォーマットの指定がうまくいってないのではないか、 との結論に達しました。 試したところ、次の修正でようやくコンパイルが通るようになりました。 こんなこと zxLinux開発ドキュメント V.0.3.2 には書いてありませんが 気にしないことにします。
# Makefileの修正点 ZLDFLAGS= -b elf32-shl -T $(ZLIB)/ldscripts/shlelf.x -L$(ZGCCLIB) -L$(ZLIB) |
コンパイル通すだけでさんざん悩んだ末、 やっとできあがった実行プログラム。 ファイルシステムイメージに転送しました。 面倒なので転送手順も Makefile に書いてしまいます。
# Makefile に追加 install: cp -f $(TARGET) /mnt/zimage/bin ## ------------------------------------------------------------------ ZIMAGE = ZLNXIMG.DAT ZISIZE = 4096 ZMOUNT = /mnt/zimage ZMOUNTO = /mnt/zimage_org zimage_create: /bin/dd if=/dev/zero of=$(ZIMAGE) bs=1k count=$(ZISIZE) /sbin/mke2fs $(ZIMAGE) zimage_init: mkdir $(ZMOUNT)/dev mkdir $(ZMOUNT)/sbin mkdir $(ZMOUNT)/bin mkdir $(ZMOUNT)/etc mknod $(ZMOUNT)/dev/console c 4 0 mount: mount -t ext2 -o loop $(ZIMAGE) $(ZMOUNT) umount: umount $(ZMOUNT) mount_org: mount -t ext2 -o loop $(ZTOP)/zxlinux-000318/ZLNXIMG.DAT $(ZMOUNTO) zimage_copy: cp $(ZMOUNTO)/sbin/* $(ZMOUNT)/sbin mountcf: mount -t msdos /dev/hdc1 /mnt/cf umountcf: umount /dev/hdc1 |
以後やっぱり面倒なので、root で全部作業してしまいます。
# make clean # make # make mount # make install # make umount |
さて、実際にコンパイルしたバイナリを zxLinux で走らせると、やっぱり動かない!!
zxLinux を起動して /bin/zrun を実行しても、 そのままコマンドが固まってしまいます。 [中断] (おそらくSIGINT) によるインタラプトは可能です。 まだ何か足りないものがあるのでしょうか。
リモートデバッガも使ってみたいのですが、CE-170T は未だ紛失したままです。 (おかげで CE-AP1 レポートでも付属ソフトを試せなかった)
プログラムコードを修正しつつ、 何度かコンパクトフラッシュ転送をしてみて学んだことが一つあります。 デバッグ時に使うファイルシステムイメージは、できる限り小さい方がいいようです。 巨大なイメージを作ってしまうと、テストのたびに転送にやたら時間がかかります。 最終的には 512Kbyte のイメージでテストするようになってしまいました。
ここであきらめて、zxlinux に最初から付属している sbin コマンドのソースリストをダウンロードして見てみることにしました。 sbin-src-000318.tgz です。
その Makefile を見てみると、見慣れないオプションが多数使われています。 elf フォーマットの指定では、独自の設定ファイルまで使ってコンパイルしています。 ちょっと寂しさを感じました。 さらに libc を使わずに、なぜか自前でライブラリまで作ってあります。 画面出力も write() システムコールを使っています。 もしかして libc を使ってはいけないのでしょうか。
試しにコンパイルしようとしたところ、ヘッダファイルが足りません。 カーネルのソースが必要になるようです。 結局カーネル開発環境 zxkerndev-000326.tgz(9132Kbyte) と zxksrc-000318.tgz(16706KByte) もダウンロードするはめになりました。 (実際は zxksrc-000318.tgz だけでよかったみたいです)
sbin コマンドの make は、Makefile のパスを書き換えるだけですんなり通ります。 ついでにファイルシステムイメージも作り直して、sbin コマンド群を /bin に 入れて実験します。 zrun は固まるのに、pwd や ls はちゃんと動きます。 コンパイルはできています。 zrun のコンパイルとどこが違うのでしょうか。
libc を使わないで write() のみで描画してみたり (libc が無いと bcopy() を自分で書く必要が生じる)、 コンパイルオプションを変えてみたり、 いろいろ試したけど一向に動きません。
ここでふと、おかしなことに気がつきます。 MI-C1 zxLinux 上でコマンドを試していて、 ZLNXIMG.DAT がちゃんと更新されてるときと、 更新されていないときがあるのです。
どうやら ZLNXIMG.DAT を作り直した時しかうまく更新されていません。 もしやとおもって touch ZLNXIMG.DAT してみたところ、 ファイルシステムがちゃんと更新されています。
mount された ext2 イメージファイルは、そのファイルシステムの中身を 書き換えても、イメージファイルそのもののタイムスタンプは更新されません。 そしてさらに、WindowsCE の ActiveSync ではファイルの タイムスタンプが更新されていないと、 ファイルの上書きコピーがうまくできないようなのです。
それでコンパイルオプションをいくら変えて試してみても、 古いイメージのバイナリが実行されていて何も変わらなかったというわけです。 情けない。
ようやく、 動かない原因はコンパイラの -lm オプションであることを突き止めました。 これをつけないと、できあがったバイナリは zxLinux で実行できません。 (2000/07/19 修正: 上記のオプションを当初 -lm と書いていたのは間違いで、 正しくは -ml です。 指摘していただいた 溝手様 ありがとうございました。)
さらに、少しずつ動く環境で設定を変更していって、 結局 libc もちゃんと使えて、 コンパイルさえうまく設定すれば何も問題ないことがわかりました。 以下に、完成版の Makefile をあげます。
# zxLinux Makefile 2000 Ogasawara Hiroyuki ZTOP = /usr/local/zxlinux TARGET = zrun ZOBJ = zrun.o LDFLAGS = -lzxl -lc -lm -lgcc CFLAGS = -O2 ## ---------------------------------------------------------------------- all: $(TARGET) ## ---------------------------------------------------------------------- ZBIN = $(ZTOP)/bin ZLIB = $(ZTOP)/sh-hitachi-elf/lib ZINC = $(ZTOP)/sh-hitachi-elf/include ZCC = $(ZBIN)/sh-hitachi-elf-gcc ZLD = $(ZBIN)/sh-hitachi-elf-ld ZGCCLIB = $(ZTOP)/lib/gcc-lib/sh-hitachi-elf/2.95.2 ZSTRIP = $(ZBIN)/sh-hitachi-elf-strip ZSYSLIB = $(ZLIB)/prochead_main.o $(ZLIB)/crt0.o ZCFLAGS = -c -ml -I$(ZINC) ZLDFLAGS= -b elf32-shl -T $(ZLIB)/ldscripts/shlelf.x -L$(ZGCCLIB) -L$(ZLIB) $(TARGET): $(ZOBJ) $(ZLD) -o $(TARGET) $(ZLDFLAGS) $(ZSYSLIB) $(ZOBJ) $(LDFLAGS) .c.o: $(ZCC) $(ZCFLAGS) $(CFLAGS) -o $@ $< .cpp.o: $(ZCC) $(ZCFLAGS) $(CFLAGS) -o $@ $< .c.S: $(ZCC) $(ZCFLAGS) -S $(CFLAGS) -o $@ $< strip: $(TARGET) $(ZSTRIP) $(TARGET) clean: rm -f $(ZOBJ) install: $(ZSTRIP) $(TARGET) cp -f $(TARGET) /mnt/zimage/bin ## ---------------------------------------------------------------------- ZIMAGE = ZLNXIMG.DAT ZISIZE = 512 ZMOUNT = /mnt/zimage ZMOUNTO = /mnt/zimage_org zimage_create: /bin/dd if=/dev/zero of=$(ZIMAGE) bs=1k count=$(ZISIZE) /sbin/mke2fs $(ZIMAGE) zimage_init: mkdir $(ZMOUNT)/dev mkdir $(ZMOUNT)/sbin mkdir $(ZMOUNT)/bin mkdir $(ZMOUNT)/etc mknod $(ZMOUNT)/dev/console c 4 0 mount: mount -t ext2 -o loop $(ZIMAGE) $(ZMOUNT) umount: umount $(ZMOUNT) touch: touch $(ZIMAGE) mount_org: mount -t ext2 -o loop $(ZTOP)/zxlinux-000318/ZLNXIMG.DAT $(ZMOUNTO) zimage_copy: cp $(ZMOUNTO)/sbin/* $(ZMOUNT)/sbin mountcf: mount -t msdos /dev/hdc1 /mnt/cf umountcf: umount /dev/hdc1 |
新規イメージを作るなら、mount_org してある状態で次のようにします。
# make zimage_create # make mount # make zimage_init # make zimage_copy # make umount |
コンパイルしてイメージファイルを更新するなら次のようになります。 なお、libc を使った場合は strip しないと 512Kbyte のイメージには入りません。
# make mount # make install # make umount # make touch |
ここまでわかれば、あとはアプリケーションを作るだけです。 しかしここまで来る道のりがかなりたいへんでした。 TurboLinux の OS install 含めてまるまる二日かかったことになります。
結局 printf() 1行のプログラムしか動かすだけでせいいっぱい。 時間もなくなったところで アプリケーション開発そのものはまたの機会にしましょう。
プログラムを書いている時間よりも、 解説文を書いている時間の方が長いのではないかという つっこみは大正解です。
| [メニューに戻る] | [ZAURUS総合] | [DirectX] | [Ko-Window] | [Win32] | [WinCE] | [携帯電話] | [その他] |
| フルパワー全開 | Hyperでんち |