このドキュメントは、アットマークテクノ社から発売されている、ARMベースの小型汎用CPU ボードArmadillo-400シリーズ(420, 440, 460)上でRTコンポーネントを動作させる方法について解説します。
Armadillo-400シリーズは、Freescale i.MX25(ARM926EJ-S)を搭載した小型CPUボードです。 Armadillo-200シリーズと比較して、SDメモリカードスロット搭載、タッチパネル液晶インターフェース(440,460のみ)搭載、ROM/RAM容量の増強、Android対応などより使いやすい組み込みCPUボードとなっています。
アットマークテクノからは、さまざまなドキュメントが提供されていますので、RTCをArmadilloに移植する前にこれらをよく読んで理解してください。
Armadillo-400シリーズドキュメント | ||
スタートアップガイド | v1.1.7 | PDF, HTML |
製品マニュアル | ||
ハードウェアマニュアル | v1.8.0 | PDF, HTML |
ソフトウェアマニュアル | v1.7.2 | PDF, HTML |
製品ドキュメント | ||
リビジョン情報 | v1.5.0 | PDF, HTML |
Atmark Dist 開発者ガイド | v1.0.9 | PDF, HTML |
ATDE3 インストールガイド | v3.0.1 | PDF, HTML |
開発ガイドブック | ||
Armadillo実践開発ガイド 第1部 | v2.2.0 | PDF, HTML |
Armadillo実践開発ガイド 第2部 | v2.2.0 | PDF, HTML |
Armadillo実践開発ガイド 第3部 | v2.1.0 | PDF, HTML |
これらのドキュメントは公式サイトで更新されていないかどうか、事前にご確認ください。
Armadillo-400シリーズは組み込みCPUボードのため、PC上のクロスコンパイル環境上でRTコンポーネント開発し、それをSDメモリなどにコピーして起動させる必要があります。RTコンポーネントを動作させるまでの手順はおおよそ以下のようになります。
なお、上記の「開発環境 ATDE3 のセットアップ」および「クロス開発」を実行した開発環境 ATDE3 for OpenRTM はこちらで配布していますので、これを利用する場合は コンポーネントの実行のための準備 から読み進めてください。
ATDE (Atmark Techno Development Environment) 3は、Armadillo-400シリーズ用の開発環境です。 実体は、VMware上で動作する Debian GNU/Linux 5.0 (“Lenny”)をベースにしたVMイメージです。 したがって、まず使用するPCにVMwareがインストールされている必要があります。
ATDEを動作させるにはVMwareをインストールする必要があります。 VMwareはVMware, Incが販売している仮想PC環境で、WindowsやLinux (あるいはMac OS X上)、または独自のOS上で動作します。 VMwareにはいろいろなバージョンがありますが、ここでは無償で利用できるWindows版のVMware Playerを利用します。
まず、VMware Playerのインストーラをダウンロードします。
Webページの手順に従ってVMware Playerのインストーラをダウンロードします。 ダウンロードしたインストーラを起動し、指示に従ってインストールします。
インストール後、再起動を求められますので再起動します。 再起動後、スタートメニューからVMware Playerを起動します。
起動を確認したら、ひとまず右上の×ボタンを押し終了します。
アットマークテクノのサイトからATDE3をダウンロードします。 ここではArmadillo-400シリーズ用のATDE3をダウンロードします。(ATDE2やATDE4は異なるシリーズのCPUボード用の開発環境ですので、ダウンロードしないでください。)
&color(red){※ATDEおよびドキュメントが更新されている可能性があるので、ATDEダウロードサイトでご確認ください。}
ダウンロードしたZIPファイルを展開すると、atde3-<バージョン番号> というフォルダができます。
フォルダの内部を見てみます。atde3 (種類:VMwre構成ファイルとなっている方) がVMwareの構成ファイルです。 このファイルをダブルクリックすると、VMware Player上でこの仮想マシン(VM)が起動します。
前述のように、ATDE3のフィルだ内のatde3 (種類:VMwre構成ファイルとなっている方, 実際のファイル名は atde3.vmx) をダブルクリックするとこのVMが起動します。
もう一つの起動方法としては、スタートメニューから VMware Playerを起動し
から、上記のatde3.vmx を指定する方法があります。
いずれかの方法で起動すると、以下のような画面が現れます。
VMwareの画面上をクリックすると、制御がVMwareに移ります。Enterを押すか、しばらく待つとLinux (Debian) が起動します。 起動すると以下のようなログイン画面が現れます。
ATDE3はデフォルトで、以下のユーザアカウントおよびパスワードが設定されています。
ユーザ名 | パスワード | 権限 |
atmark | atmark | 一般ユーザ |
root | root | 特権ユーザ |
ユーザ名 atmark、パスワード atmark を入力し、一般ユーザとしてログインしてみます。
なお、非常に簡単なパスワードしか設定されていませんので、長時間起動しておく場合はパスワードを変更したほうがよいでしょう。 以下、安全な環境下で、開発時のみ短時間起動すると仮定して、上記の設定のまま解説を進めます。
VMがネットワークにアクセスできるか確認します。
アプリケーション->インターネット->Iceweaselウェブ・ブラウザ からWebブラウザを起動します。
URLにopenrtm.org等を入力し、Webページが表示されることを確認します。
ATDE3を利用するために、いくつか必要な事項を設定剃る必要がありますが、以下の一括設定スクリプトを利用すると、簡単にセットアップができます。 なお、このスクリプトで行なっている詳しい内容についても説明します。
こちら一括設定スクリプトをダウンロードします。 ダウンロードしたスクリプトに実行権限を与え、実行します。
atmark@atde3:~$ wget http://svn.openrtm.org/Armadillo/trunk/atde3/atde3setup.sh atmark@atde3:~$ chmod 755 atde3setup.sh atmark@atde3:~$ ./atde3setup.sh
現在のパスワード (atmark) を求められますので入力します。
atmark@atde3:~$ ./atde3setup.sh [sudo] password for atmark: パスワードを入力 : パッケージデータベースの取得 : Do you want to install ssh? (y/n) <- yを入力 : 以降全てyを入力 ワークグループはデフォルトのWORKGROUPでOK WINSの質問に関してはデフォルトのNO : New SMB password: atmark Retype new SMB password: atmark : Stopping Samba daemons: nmbd smbd. Starting Samba daemons: nmbd smbd. atmark@atde3:~$
以上で、基本的設定は終了です。以下、スクリプトで行なっている内容を自ら行う場合の作業手順を示します。
公開されているATDE3の環境では、パッケージのリポジトリのURLが古いため、そのままではapt-getなどでパッケージを取得することができません。 以下のように、/etc/apt/soruces.list を編集する必要があります。以降の作業を行うために、この作業は必ず行なってください。
$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.org $ sudo sed -i 's/ftp.jp/archive/g' /etc/apt/sources.list $ sudo apt-get update
sources.list を source.list.orgとしてバックアップを取り、sources.list内の ftp.jp を全て archives に置換しています。 その後、apt-get update でデータベースを更新しています。
必須ではありませんが、sshをインストールしておけば、TeraTermなどでログインして作業を行うことができます。 通常、VMwareのゲストOSからホストOS、またはその逆にコピー&ペーストができないので、ターミナルで接続して作業するほうが便利な場合があります。
$ sudo apt-get install openssh-server # パスワード: atmark を入力 # すべてYと答える
次に、このゲストOSのIPアドレスを調べます。
atmark@atde3:~$ /sbin/ifconfig eth0 eth0 Link encap:イーサネット ハードウェアアドレス 00:0c:29:df:22:59 inetアドレス:192.168.0.2 ブロードキャスト:192.168.0.255 マスク:255.255.255.0 inet6アドレス: fe80::20c:29ff:fedf:2259/64 範囲:リンク UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1 RXパケット:70593 エラー:0 損失:0 オーバラン:0 フレーム:0 TXパケット:20438 エラー:0 損失:0 オーバラン:0 キャリア:0 衝突(Collisions):0 TXキュー長:1000 RXバイト:17346973 (16.5 MiB) TXバイト:11133415 (10.6 MiB) 割り込み:18 ベースアドレス:0x2024
192.168.0.2 がこのゲストOSのアドレスです。TeraTermなどで、このアドレスにsshで接続してみます。
TeraTermの場合、known hostにこのホストを追加するかどうか尋ねられますので、Yesと答えて次に進みます。 IDとパスワードをたずれられますので、上と同様にatmark/atmarkと入力します。
なお、DHCP接続の場合、IPアドレスが起動毎に変わる可能性があり、sshで接続する際に毎回IPアドレスを使用する必要があるかもしれません。 その場合、ネットワーク接続方式を「ブリッジ接続」から「NAT」にし、固定IPアドレスを設定すると便利です。 /etc/network/interfaces を以下の例ように書き換えることで固定IPアドレスを設定することができます。
auto eth0 iface eth0 inet static address 192.168.0.2 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.1 dns-nameservers 192.168.0.1
なお、詳細についてはLinuxおよびDebianの参考書、Webページを参照してください。
VMwareのホストOSがWindowsの場合、ホストOSとゲストOS間でファイルのやり取りをしたいことがよくあります。 例えば、ゲストOSでコンパイルしたバイナリを、Armadilloで実行する際にSDカードにコピーする場合、ゲストOSで直接SDカードを読み書きすることもできますが、Windows上でゲストOSからSDカードへファイルをコピーしたほうが便利なこともあります。
ゲストOSにSambaをインストールしておけば、簡単にゲストOSのファイルを操作することができます。
まず、sambaをインストールします。Sambaインストール後に、Sambaのコンフィギュレーションファイル /etc/samba/smb.confのバックアップをとっておきます。
atmark@atde3:~$ sudo apt-get install samba atmark@atde3:~$ sudo mv /etc/samba/smb.conf /etc/samba.smb.conf.org
ホームの下に、smb.conf という名前で以下の内容のファイルを作成します。
[global] workgroup = WORKGROUP server string = %h server dns proxy = no log file = /var/log/samba/log.%m max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes [homes] comment = Home Directories browseable = yes read only = no create mask = 0755 directory mask = 0755 valid users = %S
バックアップをとったファイルの代わりに、上記の内容のファイルを /etc/samba/以下にコピーします。
atmark@atde3:~$ cat > smb.conf # 上の内容をコピペ、Ctrl+Dを押す。 atmark@atde3:~$ sudo cp smb.conf /etc/samba
atmarkというユーザのパスワードを設定します。
atmark@atde3:~$ sudo smbpasswd -a atmark # パスワード: atmark を入力
sambaサービスを再起動します。
atmark@atde3:~$ sudo /etc/init.d/samba restart
これで、samba経由でゲストOS上のファイルをWindowsから操作できるようになりました。 Windowsでエクスプローラ(≠インターネットエクスプローラ)を起動します。(マイコンピュータをクリック or Windowsキー+e)
先ほど調べたIPアドレス (上の例では 192.168.0.2) の前に¥マークを2つつけて、エクスプローラのアドレスバーに入力します。
\\192.168.0.2
初回接続時にはIDとパスワードが訊かれますので、先ほど設定したIDとパスワード (atmark/atmark) を入力します。
自分のホームフォルダがatmarkおよびhomeという名前のフォルダとして参照できます。
クロス開発とは、ターゲットとは異なるアーキテクチャ上でそのターゲット用のバイナリを開発することです。
ArmadilloはARM Ltd.により開発されたARMアーキテクチャのCPUを搭載している組み込みコンピュータです。 一方、大半のPCはIntelが開発した i386 (または x86_64) アーキテクチャのCPUを搭載しています。 通常、ARM CPU上で実行できるバイナリ(コマンド、アプリケーション)は、i386 CPU上では実行できませんし、i386 CPU用のバイナリは、ARM CPU上では動作しません。 CPU毎に異なるバイナリ実行形式を用意してあげる必要があります。
通常ARM CPUは安価・省電力である一方、PCなどと比べるとメモリやハードディスクが少なく(ハードディスクが無いことも多い)、速度も遅いので、ARMを搭載した組み込みコンピュータ上でコンパイルなどの開発作業を行うことは効率的ではありません。 (実際、Armadillo-400シリーズに組み込まれているARM CPUはそれほど遅くはなく、一昔前のPCくらいの速度はありますので、開発作業は不可能ではありませんが。。。)
そこで、一般的なPC上で、ARM CPU上で実行可能なバイナリを作成(クロスコンパイル)するクロス開発が通常行われます。
ATDEはArmadillo用のクロス開発を行うための各種ツールがあらかじめインストールされており、標準ライブラリのみ使用するのであれば、そのままの環境で開発することができます。 /usr/arm-linux-gnueabi の下には、ARM用にコンパイルされた実行ファイルやライブラリファイルが格納されています。 以下のようにfileコマンドを使って確認してみてください。
atmark@atde3:~$ file /usr/arm-linux-gnueabi/lib/libc-2.7.so /usr/arm-linux-gnueabi/lib/libc-2.7.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, stripped
ELF 32-bit LSB shared object, ARMという文字が見えますが、これはこのライブラリがARMアーキテクチャ用のものであることを表しています。
標準以外のライブラリが必要な場合、ARM Linux用にコンパイルされたDebianパッケージを、クロス開発環境にインストールすることで、これを利用したアプリケーションなどをコンパイル・リンクすることができます。
以下、OpenRTM-aistをクロスコンパイルするために必要なパッケージのインストール、クロスコンパイル方法について解説します。
クロス開発を行うためには、ARM用の各種ライブラリをインストール剃る必要があります。ATDE3では既に大半のライブラリが用意されており、簡単なプログラムであればほぼそのままで利用できますが、OpenRTM-aistを使用する場合はomniORBやlibuuidなどOpenRTMが利用しているライブラリをインストール剃る必要があります。
OpenRTMを利用するために必要なライブラリをインストールするには、一括インストールスクリプトpkg_install_atde3.shを利用すると便利です。
以下、pkg_install_atde3.sh が行なっていることを簡単に説明します。
ARM用のライブラリは以下のサイトに様々なアーキテクチャ用にまとめて置かれています。
例えば、omniORBは、
以下に置かれています。libomniorb4のパッケージだけでも、これだけあります。
libomniorb4-1_4.1.2-1+b1_alpha.deb 22-Apr-2008 16:47 1.5M libomniorb4-1_4.1.2-1+b1_amd64.deb 13-Apr-2008 22:47 1.4M libomniorb4-1_4.1.2-1+b1_arm.deb 14-Apr-2008 07:47 1.4M libomniorb4-1_4.1.2-1+b1_armel.deb 14-Apr-2008 21:17 1.2M libomniorb4-1_4.1.2-1+b1_hppa.deb 14-Apr-2008 12:32 1.6M libomniorb4-1_4.1.2-1+b1_i386.deb 14-Apr-2008 16:02 1.4M libomniorb4-1_4.1.2-1+b1_ia64.deb 14-Apr-2008 12:32 1.8M libomniorb4-1_4.1.2-1+b1_mipsel.deb 14-Apr-2008 15:47 1.2M libomniorb4-1_4.1.2-1+b1_powerpc.deb 14-Apr-2008 15:47 1.5M libomniorb4-1_4.1.2-1+b1_s390.deb 14-Apr-2008 17:02 1.4M libomniorb4-1_4.1.2-1+b1_sparc.deb 14-Apr-2008 05:47 1.4M libomniorb4-1_4.1.2-1_mips.deb 24-Apr-2008 21:58 1.3M
aplha, hppa, mipsdel などおそらく聞きなれないアーキテクチャのパッケージもあれば、i386, amd64, powerpc などのおなじみのアーキテクチャのものもあります。 ARM用のパッケージには、armとarmelの2種類がありますが、Armadillo-400シリーズでは通常 armel アーキテクチャのパッケージを利用します。
ARMには現在2種類のABI (Application Binary Interface) があり、それぞれ OABI (Old ABI), EABI (Embedded ABI) と呼ばれます。 arm パッケージはOABI用にコンパイルされたものであることを意味し、armel パッケージはEABI用にコンパイルされたものであることを意味します。 なお armel は ARM little-endian (eとlが逆のような気もしますが) の略で、実際バイエンディアンCPUであるARM用に armeb (ARM big-endian) という名称もありますが、こちらは使われていないようです。
クロス開発用のライブラリをインストールするためには、apt-getではなくapt-crossコマンドを利用します。 apt-cross は異なるアーキテクチャ用のパッケージを、クロス開発用パッケージとしてインストールしてくれるコマンドです。 apt-get同様 /etc/apt/sources.list にあるリポジトリからパッケージをインストールしてくれます。依存関係も解決してくれますが、ホストの依存関係を壊してしまうこともあるようです。
もし、/etc/apt/sources.list に以下の行がない場合、追加する必要があります。
deb http://archive.debian.org/debian/ lenny main contrib non-free deb-src http://archive.debian.org/debian/ lenny main contrib non-free
apt-cross は以下の様に使用します。
apt-cross --arch armel --suite lenny --install package_name
OpenRTMをコンパイルするために必要なパッケージは以下のとおりです。
i386用パッケージはapt-getで、armel 用パッケージはapt-crossでインストールします。
上記の手順でインストールしたomniORB-4.1.2は、コンパイル時のオプションの関係で、double型のデータをネットワーク経由でやり取りすると、値が化けるというバグがあります。したがって、doubleを利用するコンポーネントを使う場合、omniORBを再コンパイルする必要があります。 omniORB-4.1.6以降ではこのバグの対処がなされているので、再コンパイルする場合は4.1.6以降のバージョンを推奨します。 omniORBのクロスコンパイルの手順をまとめたスクリプトを利用することもできます。(このスクリプトは4.1.6以前、以後を判断して、4.1.6より前のomniORBには自動的にパッチを当てます。)
$ tar xvjf omnioRB-4.1.6.tar.bz $ cd omniORB-4.1.6 $ ./configure --prefix=/usr/arm-linux-gnueabi CXX=/usr/bin/arm-linux-gnueabi-g++ CC=/usr/bin/arm-linux-gnueabi-gcc CXXFLAGS=-s CFLAGS=-s --build=i386-linux-gnu --host=arm-linux-gnueabi --target=arm-linux-gnu --with-omniorb=/usr/arm-linux-gnueabi --with-includes=-I/usr/arm-linux-gnueabi/include $ make clean $ make CC=gcc -C src/tool/omniidl/cxx/cccp $ make CXX=g++ -C src/tool/omniidl/cxx $ make CC=gcc-3.4 -C src/tool/omkdepend $ make $ sudo make install
途中、CC=gcc, CXX=g++ などと指定しているのは、ホスト(i386)環境上で動かす必要のあるomniidlの関連モジュールをコンパイルしているためです。 (omniORBはビルドの途中で、幾つかのIDLファイルをomniidlでコンパイルしますが、omniidl自体がARM用実行ファイルだと実行できないため。)
また、上記のスクリプトを使った場合、
$ tar xvjf omnioRB-4.1.6.tar.bz $ cd omniORB-4.1.6 $ wget http://svn.openrtm.org/Embedded/trunk/Armadillo/atde3/tools/omniorb_crossbuild.sh $ chmod 755 omniorb_crossbuild.sh $ ./omniorb_crossbuild.sh /usr/arm-linux-gnueabi $ sudo make install
となり、若干手順が簡単になります。
なお、omniORB-4.1.2のパッケージがインストールされた状態で上書きインストールすることになりますが、気にしないでください(笑
OpenRTM-aistはビルドシステムにautoconf/automakeを利用しているため、configureのオプションを幾つか指定するだけでクロスコンパイル可能です。
$ wget http://openrtm.org/pub/OpenRTM-aist/cxx/1.1.0/OpenRTM-aist-1.1.0-RELEASE.tar.bz2 $ tar xvjf OpenRTM-aist-1.1.0-RELEASE.tar.bz2 $ cd OpenRTm-aist-1.1.0 $ ./configure --prefix=/usr/arm-linux-gnueabi CXX=/usr/bin/arm-linux-gnueabi-g++ CC=/usr/bin/arm-linux-gnueabi-gcc CXXFLAGS=-s CFLAGS=-s --build=i386-linux-gnu --host=arm-linux-gnueabi --target=arm-linux-gnu --with-omniorb=/usr/arm-linux-gnueabi --with-includes=-I/usr/arm-linux-gnueabi/include $ make $ make install
以上でOpenRTM-aistがクロス開発環境にインストールされました。
ここで、OpenRTM-aistに付属のサンプルをArmadillo上で実行してみます。 Armadillo-400シリーズはSDメモリカードスロットがついており、SDメモリに実行ファイル、ライブラリおよびrtc.conf等の設定ファイルをコピーしArmadilloに挿すことで、RTコンポーネントを実行することができます。
UNIX (Linux) では Windows とは異なり、システムのすべてのファイルやフォルダがルート('/') を頂点とする一つのツリー(木)構造を構成します。 (Widnowsでは、ドライブという概念があり、C:\, D:\, ... を頂点としたツリーが複数存在します。)
UNIXではシステムにディスク (ハードディスク、USBフラッシュメモリ、SDカードメモリ等) をつないだ場合、すでに存在するツリーのどこかにディスクを接続します。これをマウント (mount) と呼びます。
工場出荷状態のArmadillo-400シリーズでは、SDメモリカードを挿しても自動的にはマウントされないかもしれません。 ここでは、Armadillo起動後にSDメモリカードを自動的にマウントするように設定します。
ArmadilloにSDメモリカードを挿して起動します。アカウント名root、パスワードrootでログインします(デフォルト設定)。 まず、mountコマンドで何がどこにマウントされているかを確認します。
atmark-dist v1.30.0 (AtmarkTechno/Armadillo-440) Linux 2.6.26-at16 [armv5tejl arch]
armadillo440-0 login: root Password: [root@armadillo440-0 (ttymxc1) ~]# mount /dev/ram0 on / type ext2 (rw) proc on /proc type proc (rw) usbfs on /proc/bus/usb type usbfs (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw) ramfs on /home/ftp/pub type ramfs (rw)
proc, usbfs sysfs udev ramfs はそれぞれ疑似デバイスなので、今は無視してください。 /dev/ram0 というのはRAMディスクです。Armadilloではフラッシュメモリに格納された / (ルート) から始まるディスクイメージをRAM領域に展開してRAMディスクとして / にマウントして利用しています。
もし、このリストに /dev/mmcblk0p1 から始まる行が含まれている場合 SD メモリがすでにマウントされている可能性があります。/dev/mmcblk0p1 はSDメモリカードへのアクセスをファイルに抽象化したデバイスファイルです。mmcblk0p1 は
mmcblk + 0 + p + 1 ( mmcblock型のデバイスの0番目の1番目のパーティション )
という意味です。ls -l /dev/mmcblk* でほかのデバイスを見てみると、
# ls -l /dev/mmcblk* brw-rw---- 1 root root 179, 0 Jan 1 1970 /dev/mmcblk0 brw-rw---- 1 root root 179, 1 Jan 1 1970 /dev/mmcblk0p1
/dev/mmcblk0 というデバイスもあることがわかります。これはSDメモリカード全体のデバイスファイルで、その下に第1番目のパーティションとして /dev/mmcblk0p1 が存在するといったイメージで考えてください。
ここで利用するのは、パーティション1のデバイスである /dev/mmcblk0p1 です。 以下のようにタイプしてください。
[root@armadillo440-0 (ttymxc1) ~]# mount -t vfat /dev/mmcblk0p1 /mnt [root@armadillo440-0 (ttymxc1) ~]# mount /dev/ram0 on / type ext2 (rw) proc on /proc type proc (rw) usbfs on /proc/bus/usb type usbfs (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw) ramfs on /home/ftp/pub type ramfs (rw) /dev/mmcblk0p1 on /mnt type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
SDメモリの第1パーティション /dev/mmcblk0p1 が /mnt 以下にマウントされていることがわかります。 なお、最初のコマンドで -t vfat というオプションは対象デバイスのファイルシステムを指定するためのオプションで、VFAT (Virtual File Allocation Table) の略で、Windows 95 以降で採用されたロングファイル名が利用可能なファイルシステムです。 最近のWindowsではNTFSが主流ですが、USBメモリ、SDメモリなどでは VFAT た exFATなどのファイルシステムがよく利用されています。
もし、-t vfat オプションでうまくマウントできない場合は、WidnowsにSDメモリカードを挿してVFATでフォーマットしなおしてください。
さて、SDメモリカードがマウントできることが確認できたので、この作業を自動化します。 /etc/config/rc.local というファイルは、システムが起動時に自動で呼び出してくれるシェルスクリプトです。(rc: run commands の略) vi を利用してrc.localを編集します。viの使い方はWebなどを参照してください。
[root@armadillo440-0 (ttymxc1) ~]# vi /etc/config/rc.local
このファイルの最後のほうに、以下のコマンドを追加します。
if test -b /dev/mmcblk0p1; then echo -n "Mounting SD memory" mount -t vfat /dev/mmcblk0p1 /mnt check_status fi
if test -b ~ で /dev/mmcblk0p1 というブロックデバイスファイルがあるかどうかをチェックしています。ある場合は、Mounting SD memory とコンソールに表示し、mountコマンドでSDメモリを /mnt にマウントします。
起動時に以下のように done/failed といったメッセージがコンソールに表示されましたが、
Starting lighttpd: done Creating avahi.services: done Starting avahi.daemon: done Starting Xfbdev: failed
これは、起動時の実行したコマンドが正常に終了したかを示しています。 この done/failed を表示していたのが check_status というコマンドで、直前のコマンドの実行が成功したか否かを表示します。
SDメモリを自動的にマウントするだけでなく、マウントしたSDメモリカードに入っているRTCを自動的に起動するように設定します。
マウントしたSDメモリのトップにboot.shというシェルスクリプトを置き、そこにRTCを起動する手順を記述するものとします。 rc.local には以下のようなコマンドを SDカードをマウントするコマンドの後に 記述します。
if test -f /mnt/boot.sh; then echo -n "Starting RTCs" sh /mnt/boot.sh check_status fi
Armadillo-420/440 等ではリアルタイムクロックをバックアップする電池などは搭載されていないため、起動直後のクロックは無意味時刻を示します。 そこで、NTPで正確な時刻にセットします。
SDメモリカードをマウントするコマンドの前にに以下のコマンドを入力してください。
echo -n "Adjusting clock" ntpclient -h ntp.ring.gr.jp -s check_status
これで、Armadilloがネットワークにつながっていれば、NTPで正確な時刻を取得してクロックに設定します。
さて、ここまで編集したrc.localは、そのままでArmadilloを再起動すると消えてしまいます。 上でも述べたように、Armadillo のシステムファイルはフラッシュメモリ上に圧縮され格納されており、起動時にRAM領域に展開されて利用されます。 システム上のファイルを変更しても、電源を切って再投入すれば、すべてのファイルは元に戻ります。
しかし、/etc/config ディレクトリ以下のファイルだけは、システム全体とは別の領域に格納されており、flatfsdというコマンドに-sオプションをつけて起動することにより変更を保存することができます。
[root@armadillo440-0 (ttymxc1) ~]# flatfsd -s flatfsd: saving fs to partition 0, tstamp=1 flatfsd: Wrote 5686 bytes to flash in 1 seconds [root@armadillo440-0 (ttymxc1) ~]#
これでArmadillo側の事前の準備は完了です。電源を入れなおして再起動してみてください。 再起動後ログインし、mountコマンドでSDメモリがマウントされていることを確認します
なお、flatfsdの詳細についてはArmadilloのサイトの以下の文書を参照してください。以下のようなディレクトリ構成でファイルを配置します。
sdmemory + lib: ライブラリを格納するディレクトリ + rtc: RTコンポーネントを格納するディレクトリ + rtc.conf: RTコンポーネントの設定ファイル + boot.sh: RTコンポーネント起動スクリプト
libディレクトリには、RTコンポーネントを実行するのに必要なライブラリを格納します。最低限必要なライブラリは以下のものになります。
この他、動作させたいRTコンポーネントが依存しているライブラリがあれば、それらもいっしょにlibディレクトリにいれておきます。
さて、上記のライブラリや、RTCが依存ライブラリをしているライブラリを調べるには、どのようにすれば良いのでしょうか? Linuxでの開発経験がある人は、ldd コマンドを思いつくかもしれません。 lddコマンドは実行ファイルや共有ライブラリの依存関係を表示するコマンドで以下のように使用します。
atmark@atde3:~$ ldd /usr/lib/libm.so /lib/ld-linux.so.2 (0xb7f36000) linux-gate.so.1 => (0xb7f35000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da6000)
libm (sin, cos関数など含む数学ライブラリ) はlibc など幾つかのライブラリに依存していることがわかります。
しかし、あいにく対象はARM用のライブラリであり、lddは利用することはできません。 こう言った場合には、readelfコマンドを使用します。ARM用のバイナリに対して利用できる arm-linux-gnueabi-readelf コマンドは /usr/bin/arm-linux-gnueabi-readelf にあります。
$ arm-linux-gnueabi-readelf -d /usr/arm-linux-gnueabi/lib/libomniORB4.so | grep NEEDED 0x00000001 (NEEDED) Shared library: [libomnithread.so.3] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6]
このように、libomniORB4.soが依存しているライブラリを調べることができます。 対象とする実行ファイルやライブラリが依存しているライブラリを再帰的にに調べ上げて、libディレクトリにコピーする必要があります。
SDメモリに格納されたライブラリをを利用してRTコンポーネントを実行するには、SDメモリのlibディレクトリにライブラリサーチパスを通す必要があります。
SDメモリは /mnt ディレクトリにマウントとすると、ライブラリのパスは /mnt/lib となります。ライブラリサーチパスを通すには、環境変数 LD_LIBRARY_PATH にこのパス /mnt/lib をセットする必要があります。
export LD_LIBRARY_PATH =/mnt/lib
このほか、rtcディレクトリ以下にあるRTCの実行ファイルをすべて起動するスクリプトの例を以下に示します。
#!/bin/sh MOUNT_POINT=/mnt export LD_LIBRARY_PATH=$LIBPATH:$MOUNT_POINT/lib/ comps=`ls $MOUNT_POINT/rtc` for r in $comps; do $MOUNT_POINT/rtc/$r -f $MOUNT_POINT/rtc.conf & done
LD_LIBRARY_PATHにパスを通して、rtcディレクトリの中にあるRTコンポーネントの実行ファイルを全て起動します。
PC上で実行する場合と同様にRTコンポーネントを起動後、その名前と参照を登録するネームサーバを、corba.nameservers オプションで指定します。また、デバッグフェーズではログに関するオプションも指定した方が良いかもしれませn。
corba.nameservers: 192.168.11.10 logger.log_level: PARANOID logger.file_name: /mnt/rtc%p.log
この例では、ネームサーバのアドレスを192.168.11.10に、ログレベルをPARANOID (すべてのメッセージをログに残す) に指定し、そのログファイル名をSDメモリ上の /mnt/rtc<プロセス番号>.log にしています。
詳しくは、デベロッパーズガイドの設定ファイル (基礎編)およびrtc.conf設定項目一覧を参照してください。
以上の作業を自動化するスクリプトが、openrtm_sdmem.sh です。このスクリプトのヘルプを示します。
atmark@atde3:~$ openrtm_usbmem.sh -h Usage: openrtm_usbmem.sh -d <dir> -r <rtc> -l <libdir> This script creates a directory to be copied to USB memory for Armadillo execution environment. One or more RTCs can be specified by -r and are copied to rtc directory. Dependent libraries are automatically analyzed and copied to lib directory. boot.sh to launch RTCs and rtc.conf for RTCs are also created. -d <dir> Target directory -r <rtc> Target RTC binary -l <libdir> Library search path -h Print this help EXAMPLE $ cd my_component_dir $ ls mycomponent mycomponent.so $ openrtm_usbmem.sh -d /tmp/usbmem -r mycomponent -l . -l ../deplibdir
-dオプションでファイルをコピーするターゲットディレクトリ、-rオプションでRTコンポーネントの実行ファイル、ーlでライブラリを検索するディレクトリをそれぞれ指定し実行します。
Armadillo上でOpenRTM-aistのサンプルコンポーネント SeqOutComp を実行してみます。 SeqOutCompは/usr/arm-linux-gnueabi/share/openrtm-1.1/examples の下にインストールされていますので、以下のように実行します。
atmark@atde3:~$ openrtm_sdbmem.sh -d ~/sdmemory -r /usr/arm-linux-gnueabi/share/openrtm-1.1/example/SeqOutComp Now Armadillo's USB memory image is created. Target directory: /home/atmark/sdmemory Target RTCs: /usr/arm-linux-gnueabi/share/openrtm-1.1/example/SeqOutComp Library search path: /usr/arm-linux-gnueabi Searching lib under /usr/arm-linux-gnueabi copying /usr/arm-linux-gnueabi/lib/libRTC-1.1.0.so -> /home/atmark/sdmemory/lib Searching lib under /usr/arm-linux-gnueabi copying /usr/arm-linux-gnueabi/lib/libcoil-1.1.0.so -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libuuid.so.1 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libdl.so.2 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libpthread.so.0 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libomniORB4.so.1 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libomnithread.so.3 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libomniDynamic4.so.1 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libstdc++.so.6 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libm.so.6 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libc.so.6 -> /home/atmark/sdmemory/lib copying /usr/arm-linux-gnueabi/lib/libgcc_s.so.1 -> /home/atmark/sdmemory/lib /home/atmark/sdmemory/boot.sh created. /home/atmark/sdmemory/rtc.conf created. NOTE: Edit /home/atmark/sdmemory/rtc.conf for your environment.
sdmemoryディレクトリ以下には、ファイルが以下のように配置されました。
atmark@atde3:~$ ls -R sdmemory/ sdmemory/: boot.sh lib rtc rtc.conf sdmemory/lib: libRTC-1.1.0.so libdl.so.2 libomniDynamic4.so.1 libpthread.so.0 libc.so.6 libgcc_s.so.1 libomniORB4.so.1 libstdc++.so.6 libcoil-1.1.0.so libm.so.6 libomnithread.so.3 libuuid.so.1 sdmemory/rtc: SeqOutComp
Linux経由でコピーする方法は、手順が煩雑なので非推奨です。 また、SDメモリカードアダプタの接続方法により異なるため、以下の手順で実行できるとは限りません。
まず、VMwareの「仮想マシン」->「仮想マシンの設定」からの設定で、USBコントローラが有効になっていることを確認します。
次にVMを起動し、SDメモリを挿入します。VMware Playerでは画面の右下に、接続されているデバイスの一覧が表示されます。このうちどれか一つがSDカードのデバイスに対応します。マウスカーソルをアイコン上に置くとバルーン表示されますので確認してください。
SDカードのデバイスが見つかったら、アイコンを右クリックし接続します。
ATDEでは通常SDメモリやUSBメモリ等は自動的にマウントされます。 ここで、コマンドラインから mount コマンドを入力してSDメモリのマウントポイントを調べます。
atmark@atde3:~$ mount | grep media /dev/sdb1 on /media/SD type vfat (rw,nosuid,nodev,uhelper=hal,shortname=lower,uid=1000) atmark@atde3:~$
リムーバブルディスクはデフォルトでは /media の下にマウントされます。 ここでは SDメモリは /media/SD にマウントされたことがわかります。
先ほど作成した sdmemory ディレクトリの内容を、SDメモリにコピーします。
atmark@atde3:~$ cp -r sdmemory/* /media/SD/
SDメモリをアンマウントします。
atmark@atde3:~$ umount /media/SD
ここでは、Armadillo上で動作するSeqOutCompと、PC上で動作するSeqInCompを接続してみます。
PCのIPアドレスを調べます。コマンドプロンプトから
> ipconfig
と入力し、PCのIPアドレスを覚えておきます。 ネットワーク・インターフェースが複数ある場合は注意が必要です。 VMwareがインストールされている場合、ほぼ100%複数のネットワーク・インターフェースが存在します。 実際にネットワークにつながっているインターフェースを見つけて、そのアドレスを覚えておいてください。
rtc.confに次の1行を追加します。
# corba.endpoints: 192.168.11.16 corba.endpoints: <ip address>
<ip address>には先程覚えたアドレスを記載します。Vista以降のWindowsではUACにより C:\Program Files\OpenRTM-aist 以下の rtc.conf を書き換えることはできませんので、その場合 C:\tmpなど適当なフィルダに SeqInComp.exe とrtc.confをコピーして上の1行を追加してください。
次に、以下のようにネームサーバやコンポーネントを起動します。
RTSystemEditorでネームサーバに接続します。
ArmadilloをシリアルケーブルでPCと接続し、PC側でターミナルソフト(TeraTerm等)を起動して、Armadilloをモニタリングしてください。 SDメモリをArmadilloに挿し、Armadilloに電源を入れ起動します。
うまく行けば、PC上のネームサーバにSequenceOutCompという名前のコンポーネントが起動していることを確認できます。
Armadillo 側で起動した SequenceOutCompoと、PC側で起動した SequenceInComp というコンポーネントを接続してみます。
接続完了後、2つのコンポーネントをActivateすると、PC側で起動した SequenceInComp のコマンドプロンプトに連続した様々な数字が表示され、Armadillo の SeqOutCompから数値が送られていることが確認できます。
Armadilloの電源を入れてください。
工場出荷状態のArmadilloは起動可能なカーネルおよびユーザランドが書き込まれてい無いことがあります。 アットマークテクノで配布しているデフォルトのカーネルとユーザランドを書き込んで機能可能な状態にしてからご利用ください。
有効なネットワークにLANケーブルを接続してください。
ArmadilloはデフォルトではDHCPでアドレスを取得してネットワークに接続します。 利用しているLAN上にDHCPがない場合、DHCPサーバを立てるか、Armadilloに固定アドレスを振る設定を行ってくださ。
SDメモリカードはArmadilloの起動前にカードスロットに差し込む必要があります。Armadillo動作中、RTC起動中に抜き差ししないでください。
必要なファイルが一つでも欠けている場合コンポーネントは起動しません。 Armadilloにログインし、/mnt ディレクトリを確認してみます。
atmark-dist v1.30.0 (AtmarkTechno/Armadillo-440) Linux 2.6.26-at16 [armv5tejl arch] armadillo440-0 login: root Password: root [root@armadillo440-0 (ttymxc1) ~]# ls -R /mnt /mnt: boot.sh* rtc/ rtc1577.log* rtc1709.log* rtc1747.log* lib/ rtc.conf* rtc1688.log* rtc1728.log* /mnt/lib: libRTC-1.1.0.so* libgcc_s.so.1* libomnithread.so.3* libc.so.6* libm.so.6* libpthread.so.0* libcoil-1.1.0.so* libomniDynamic4.so.1* libstdc++.so.6* libdl.so.2* libomniORB4.so.1* libuuid.so.1* /mnt/rtc: SeqOutComp*
上記の例SeqOutCompを動作させるには、このような構成になっている必要があります。
Armadilloにログインして、マウントポイントを確認します。
[root@armadillo440-0 (ttymxc1) ~]# mount /dev/ram0 on / type ext2 (rw) proc on /proc type proc (rw) usbfs on /proc/bus/usb type usbfs (rw) sysfs on /sys type sysfs (rw) udev on /dev type tmpfs (rw) ramfs on /home/ftp/pub type ramfs (rw) /dev/mmcblk0p1 on /mnt type vfat (rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1)
最後の行、/dev/mmcblk0p1 が /mnt ディレクトリにマウントされています。 もし、/dev/mmcblk0p1 がマウントされていない場合、
# mount -t vfat /dev/mmcblk0p1 /mnt
のようにして手動でマウントしてみます。
起動スクリプトにバグがあり、RTコンポーネントが起動できないケースがあります。 起動スクリプト boot.sh に書いてある手順通りに、シリアル端末からRTCを実行してみる。
Armadilloに複数のネットワークインターフェースがあり、PC側から届かない方のアドレス (Unreachable) がセットされている場合、システムエディタがRTCのプロファイル情報を取得できずにゾンビ表示になります。
Armadillo上で実行するRTC用のrtc.confにendpointを設定してください。
corba.endpoints: 192.168.0.10: # 192.168.0.10: はArmadilloのネットワークインターフェースのアドレス
PCとArmadilloの間にファイヤウォールがある場合、またはArmadilloがNATを介してネームサービスに名前を登録している場合、PC側からはArmadilloに到達することができずにゾンビン表示となります。
ArmadilloをPCと同じセグメント(ネットワーク)に接続して起動してください。
ポートの接続をする際にはコンポーネント同士でポートのオブジェクト参照を交換します。 その際、相手のポートのIPアドレスおよびポートを利用して相手のポートの接続しに行くため、両RTC間が相互に到達可能なIPアドレスである必要があります。
特にPC側はVMwareなどがインストールされており、ネットワークインターフェースをたくさん持つ状態になっています。 たとえば、PC側のRTCが持つVMネットワークのプライベートアドレス 192.168.5.10 を、RTC上のRTCのオブジェクト参照内に埋め込むと、Armadillo側のRTCは 192.168.5.10 にポートの接続をしに行こうとします。この192.168.5.10というアドレスは、VMwareの仮想プライベートネットワーク内でのみ有効なアドレスなので、Armadillo側のRTCは到達し得ないポートに接続しに行こうとし、タイムアウトになるまで試行します。 この時、RTSystemEditorはRTCから応答が返ってこないため固まります。
この場合、PC側のRTCが読み込むrtc.confにendopiintを設定する必要があります。 ipconfig 等のコマンドでPCの実際のLAN上でのアドレスを調べ (仮に150.29.123.123とします)、
corba.endpoints: 150.29.123.123:
のようにcorba.endpointsオプションに指定します。最後のコロン「:」は必ず付けてください。
実行しているRTCと、そのRTCが利用しているライブラリ (Linuxでは.so、WindowsではDLL) のバージョンに不整合がある場合、何らかの操作をすると落ちるケースがあります。 RTCとそのRTCが参照しているライブラリのバージョンを確認してください。
自作のRTCの場合、RTCに実装したロジックにバグがあればRTCは落ちます。 OpenRTM-aistに付属のサンプルRTCは簡単なロジックのものしかありませんので、この原因の可能性は低いでしょう。
OpennRTM-aistのバグの可能性がある場合は、
を添えてメーリングリストにて報告してください。
その他、どうしてもうまくいかない場合は、メーリングリスト ( OpenRTM-users ) で気軽に質問してください。
OS (Operating System) のもっともコアとなる部分をカーネルと呼びます。 カーネル (= OS) は、アプリケーションプログラムに対して、CPU、メモリ、ディスクなどのリソースの分配や管理、ハードウエアへの抽象化されたアクセスの提供等を行います。
原則として、すべてのデバイスはカーネルが提供するファイルとして抽象化されたドライバ (デバイスファイル) 経由で、アプリケーションプログラムからアクセスされます。
基本的にハードウエアベンダがそのデバイスドライバを提供するWindowsとは異なり、Linuxでは、一般に配布されているカーネルのソースコード内に基本的なすべてのデバイスドライバが含まれています。 デバイスドライバは、カーネル内に静的に組み込まれるドライバと、モジュールとして個別にコンパイルされ、必要になった時点で読み込むモジュール型のデバイスドライバがあります。
たいていのドライバは、Static としても Module としてもコンパイル可能で、カーネルの設定時に選択できます。
この2種類のドライバはそれぞれメリット・デメリットがあります。
最近のほとんどのLinuxディストリビューション (Debian, Ubuntu, Fedora, CentOSなど)
ではほぼすべてのドライバをはじめからモジュール形式でコンパイルしたものをカーネルと一緒に配布しています。
しかし、かつてPCの速度が遅く、メモリが少なかった時代には、自分の環境にあったカーネルを自分でコンパイルすることはLinuxユーザが行う環境設定の第一歩でした。 Armadilloのような組み込みデバイスにおいては、現在においてメモリもディスクスペースも貴重ですので、自分の用途に合ったカーネルを設定・コンパイルする必要があります。
ユーザランドとは、OSが動作するのに必要な部分のうち、カーネル以外の部分を言います。
ユーザランド = OS - kernel
ユーザランドには、
等があります。 Armadilloでは、ユーザランドを圧縮したイメージの状態でFlashメモリに格納し、起動時にRAMに展開してルートファイルシステムとしてマウントし利用します。 ユーザランドにファイルを追加したい、あるいは削除した場合、ユーザランドのイメージを作り直し、Armadilloにダウンロードする必要があります。 ユーザランドは通常10MB程度あり、シリアルポート経由でArmadilloにダウンロードするため、入れ替えには10分程度かかります。 頻繁に入れ替えるのは大変ですので、ユーザランドの入れ替えを考えている場合は、よく計画して行ったほうがよいでしょう。
Armadilloのような組み込みデバイスでは、ディスクスペースは大変貴重です。 一方で、Linuxシステムは起動するだけでも多くのコマンドが必要となります。 そこで、ディスクおよびメモリスペースを節約するために考え出されたのがBusyBoxです。 BusyBoxは、lsやcp, mvなど/binにインストールされているようなコマンド群の代わりを一つの実行ファイルで行います。
Armadilloでは、ユーザランドのコマンドの多くがBusyBoxにより実現されています。
上で説明したカーネルのドライバのうち、静的に組み込まれるドライバはカーネル内部に存在しますが、モジュールドライバはファイルとしてユーザランドに存在します。 Armadilloでは通常以下のディレクトリ
/lib/modules/2.6.26-at16/kernel/drivers # ^^^^^^^^^^^^この部分はカーネルのバージョン
に格納されています。モジュールがインストールされていれば、
$ find /lib/modules/2.6.26-at16/kernel/drivers ./ ./net ./net/wireless ./net/wireless/rt5370sta.ko ./scsi ./scsi/scsi_wait_scan.ko
このように、<device名>.ko というファイルがいくつか見つかるはずです。
カーネルモジュール内部にはカーネルのバージョンが保持されていて、異なるバージョンのカーネルにはモジュールをロードできないようになっています。
カーネルとカーネルモジュールは必ずセットで作成します。 したがって、カーネルモジュールを含むユーザランドとカーネルは原則としてセットで作成する必要があります。
Armadilloのような組み込みLinux環境では、利用できるメモリやディスクに制限があるため、必要最低限のカーネルやユーザランド(種々のコマンド群やアプリケーションを含めてこう呼ぶ) しかインストールしません。
ArmadilloではカーネルもユーザランドもFlashメモリ上に格納され、起動時にRAMにに展開され利用します。起動後にユーザランドに変更を加えても、Flashメモリ上のユーザランドのイメージには変更は反映されないため、ユーザランドに新たなコマンドを加えたり設定を変更したい場合は、PC上でクロス開発し、ユーザランドをイメージ化しArmadilloのFlashメモリにダウンロードする必要があります。
これを行うための環境が Armark Distです。 Atmark Dist は uClinux という MMU (Memory Management Unit) がない組み込み紺ぴぃーた向けのLinuxのためのソースコードベースのディストリビューション uCLinux distが元になっています。 もちろんArmadilloはMMUを搭載したARM9ベースのCPUボードですので、uCLinuxを使う必要はありませんが、uCLinux distの組み込み向けユーザランドを作成する機能を利用し、Armadillo用のカーネルとユーザランドを作成するよう拡張したものを Atmark Distとしてリリースしています。
Armark Distの一般的な使い方は、上述のアットマークテクノの解説をご覧ください。
この解説では、
を利用するために、カーネルおよびユーザランドの再設定および利用方法について説明します。
基本的な手順は atmark-dist 開発者ガイド第3章 に従います。
まずはじめに、Atmark DistとLinuxカーネルをダウンロードします。
アットマークテクノのダウンロードサイトには、全体とデバイスごとのフォルダにAtmark Distとカーネルソースが置かれています。 カーネルソースはデバイス毎に若干異なるようですので、基本的にはデバイス個別のフォルダにおかれているAtmark Distとカーネルソースをセットで利用するとよいでしょう。
以下、作業ディレクトリをホームディレクトリ直下の work というディレクトリにします。(ディレクトリ名は任意ですが、以下便宜上workとします。)
$ cd $ mkdir -p work/atmarkdist $ cd work/atmarkdist $ wget http://download.atmark-techno.com/armadillo-440/source/dist/atmark-dist-20120727.tar.gz $ wget http://download.atmark-techno.com/armadillo-440/source/kernel/linux-2.6.26-at16.tar.gz $ tar xvzf atmark-dist-20120727.tar.gz $ tar xvzf linux-2.6.26-at16.tar.gz
Atmark Distはビルドの過程で、カーネルソースを参照します。Atmark Distがカーネルソースを認識するためには、Atmark Distディレクトリの直下にカーネルのディレクトリが存在する必要があります。 そのため、カーネルソースディレクトリへのシンボリックリンクを張ります。
$ mv atmark-dist-20120727 atmark-dist # 便宜上ディレクトリ名を変える $ cd atmark-dist $ ln -s ../linux-2.6.26-at16 linux-2.6.x # ln -s ../linux-2.6.26-at16 linux-2.6.26でもよい
ディレクトリ構成はこのようになっているはずです。
~/work + atmarkdist + armark-dist + bin + config + : + linux-2.6.x -> ../linux-2.6.26-at16 へのシンボリックリンクをあらかじめ張る + : + vendors + linux-2.6.26-at16
Atmark Distのメニューを起動します。
$ cd ~/work/atmarkdist $ make menuconfig
Vendor/Product では ArmarkTechno、ProductではArmadillo-440を選択する。
に設定。Exitを2回選択し、設定を保存するかきかれるのでOKを選択すると、次はカーネルの設定画面が起動する。
以降、対象とするドライバ毎に説明する。
アットマークテクノのダウンロードサイトからダウンロード可能なカーネルは、Armadillo-400シリーズで動作させるための最低限のドライバのみ組み込まれており、その他のデバイスを利用する場合は自分でカーネルを再コンパイルして組み込む必要があります。
ロボットシステムでよく用いられる北陽電機のレーザ測域センサ URG シリーズも、Armadilloのデフォルトカーネルでは利用することができないデバイスの一つです。
ここでは、URGセンサを動作させるために必要な CDC ACMドライバの組み込み方を説明します。
+ atmark-dist + linux-2.6.x -> ../linux-2.6.?? へのシンボリックリンク + linux-2.6.?? -> 以下は 2.6.26-at16 を仮定しています
上記のディレクトリ構成を仮定します。Atmark-dist を展開したディレクトリ内で
$ make menuconfig
とコマンドを入力すると、以下のような画面が表示されます。
メニュー中央の青い長方形がカーソルです。 カーソルキーで上下に動かし、Enterキーで選択し、配下のサブメニューに入ります。
ここでは、Vendor/Product SelectionおよびKernel/Library/Defaults Selectionメニューを設定します。
Vendor/Product Selectionでは、ターゲットのベンダとプロダクトを指定します。 (SnapGear) Vendorと表示されているところにカーソルを移動し、Enterをします。
ベンダ名はアルファベット順に並んでいるので、カーソルキーで上のほうに行き AtmarkTechno を Enter キーを押して選択します。
次に、プロダクトを選択します。
アットマークテクノの製品名一覧が表示されるので、自分が使用しているプロダクト名 (ここでは Armadillo-440) を選択します。
VendorProduct Selectionメニューを抜け、Kernel/Library/Defaults Selectionメニューを選択します。
まず以下のように、カーネルソースとクロス開発環境およびライブラリを選択します。
次は、このAtmark-dist Configurationの後に、カーネルやユーザランドの設定を行うかどうかの選択をします。
今回は、CDC ACMドライバを組み込むだけで、ユーザランドには手を加えないので、Customize Kernel Settings にのみスペースキーを押してチェックを入れます。
以上、設定が終了したら、Exit でメニューを抜けます。最後に Do you wish to save your new kernel configuration? と尋ねられるので Yes を選択して Atmark-Dist Configurationを終了します。
Atmark-Dist Configurationを終了すると、シェル画面に戻り、コンパイルを開始します。しばらくするとカーネルの設定メニューが表示されます。
Atmark-Dist同様、青い長方形がカーソルで、カーソルキーで上下に移動、Enterまたはスペースキーで選択します。
デバイスドライバを組み込むので、Device Driverを選択します。
下のほうにある USB Support サブメニューに入ります。
CDC ACMドライバは USB Modem (CDC ACM) support というところにあります。
USB Modem (CDC ACM) support にカーソルを持っていき、スペースキーを押します。スペースキーを押すごとに、< >(無印) -> <M>(モジュール) -> <*> (組込ドライバ) のようにマークが変更されます。組込みドライバにする場合は、チェックボックスを以下のように <*> (アスタリスク) に設定します。
カーネルモジュール型ドライバにしたい場合は、チェックボックスを以下のように <M> に設定します。
以上でCDC ACMドライバの設定は終わりです。Exitを何回か選択して Linxu Kernel Configuration を抜けます。
最後にカーネル設定を保存するかどうか尋ねられるので、Yesと答えて終了します。
以上が終了したら、コンパイルを行います。 atmark-dist 直下のディレクトリで make clean と make を行います。 以前コンパイルしたオブジェクトファイルなどが残っている場合があるので、make clean は必ず行ってください。 コンパイルはPCの性能にもよりますが、数分から十数分かかります。
atmark@atde3:~/work/atmarkdist/atmark-dist$ make make -C tools/sg-cksum make[1]: ディレクトリ `/home/atmark/work/atmarkdist/atmark-dist/tools/sg-cksum' に入ります : 数分から十数分 : /home/atmark/work/atmarkdist/atmark-dist/tools/cksum -b -o 2 /home/atmark/work/atmarkdist/atmark-dist/images/linux.bin.gz >> /home/atmark/work/atmarkdist/atmark-dist/images/linux.bin.gz make[1]: ディレクトリ `/home/atmark/work/atmarkdist/atmark-dist/vendors/AtmarkTechno/Armadillo-440' から出ます atmark@atde3:~/work/atmarkdist/atmark-dist$
コンパイルが終了すると、image ディレクトリの下に、linux.bin.gz, romfs.img.gz といったイメージファイルができているはずです。 途中でコンパイルエラーになっている場合、このイメージは作成されませんので、作成されたイメージファイルのタイムスタンプをよく確認してください。
atmark@atde3:~/work/atmarkdist/atmark-dist$ ls -al images/ 合計 43296 drwxr-xr-x 2 atmark atmark 4096 2012-08-19 12:47 . drwxr-xr-x 15 atmark atmark 4096 2012-08-19 12:47 .. -rwxr-xr-x 1 atmark atmark 3617965 2012-08-19 12:47 linux.bin -rw-r--r-- 1 atmark atmark 1764568 2012-08-19 12:47 linux.bin.gz -rw-r--r-- 1 atmark atmark 27803685 2012-08-19 12:47 romfs.img -rw-r--r-- 1 atmark atmark 11071893 2012-08-19 12:47 romfs.img.gz
それぞれ、
となっています。
作成したカーネルとユーザランドのイメージをArmadilloに書き込み(ダウンロード)ます。 (組込みの分野では、ROM領域へプログラムを書き込むことを一般にダウンロードと呼びます。)
カーネルやユーザランドへのイメージの書き込みは以下のサイトが参考になります。
書き込みはLinuxからでも、Windowsからでも行うことができますが、ここでは、Windows用のHermit-At Win32を用いてイメージを書き込む方法を説明します。
PCにシリアルポートがある場合は、PCとArmadilloをシリアルケーブルで接続します。 PCにシリアルポートがない場合、USB-シリアル変換コネクタなどを用いてArmadilloとPCを接続してください。 デバイスマネージャでどのシリアルポートがArmadilloにつながっているか確認してください。
ArmadilloのDCコネクタ付近に4本(2x2)のピンヘッダが出ています。 このうち、逆サイドのLANコネクタやUSBコネクタに近い2ピンをジャンパでショートさせます。 これで、hermitによりROM書き込みモードになります。 この段階ではまだArmadilloに電源を入れないでください。
Hermit-At Win32 WindowsからArmadilloのフラッシュメモリ領域に各種イメージを書き込むためのツールです。 以下のサイトからダウンロードできます。
hermit.exe を起動するとこのようなウインドウが現れます。
まず、使用するシリアルポートを選択します。 ここでは、COM2がArmadilloに接続されているシリアルポートです。
Memmapボタンを押してみてください。PCとArmadilloが正しく接続されており、ArmadilloがHermitのダウンロードモードになっていれば、メモリマップが表示されます。
これから書き換えようとしているのは、kernel のカーネル領域と、userlandのユーザランド領域です。
まず、カーネルの書き換えを行います。 Erase ボタンを押し、Regionのプルダウンで kernelを選択し、実行ボタンを押します。
ダイアログが表示されカーネル領域が削除されます。
次にダウンロードボタンを押し、Image で先ほど作った linux.bin.gz を、Regionで kernel 選択します。
Image の右側の ... ボタンを押すと、ファイル選択のためのダイアログが開きます。ATDE3 for OpenRTM ではsambaが設定されていますので、アドレスバーのところに
\\192.168.5.132 <- ATDE3 for OpenRTMのアドレス または \\192.168.5.132\atmark\work\atmarkdist\atmark-dist\images
のように、ATDEのアドレスを入力します。アカウント名(atmark)とパスワード(atmark)を入力し、先ほど作成したlinux.bin.gzのフォルダにアクセスし、ファイル (linux.bin.gz) を選択します。
linux.bin.gz (拡張子が見えず linux.bin と表示されますが、種類がGZファイルとなっているほう) を選択します。以上が終わったら実行ボタンをクリックします。 書き込みダイアログが表示され、数分でカーネルの書き込みは終了します。
次にユーザランドを書き換えます。 カーネル同様、
を行います。 ユーザランドはファイルサイズが大きいため、書き換えには十数分かかります。
以上で、カーネルとユーザランドの書き換えは終了です。
Armadilloのジャンパピンをオープンにして、電源を再投入します。この時URGセンサはまだ接続しないでください。
URGセンサはUSB Modeとして /dev/ttyACM0 (2つ目以降はttyACM1, ttyACM2, ...) というデバイス名で利用できます。
起動後、rootでログインして、デバイスが存在するかどうか確認してみてください。
[root@armadillo440-0 (ttymxc1) ~]# ls /dev/ttyACM* ls: /dev/ttyACM*: No such file or directory
USGセンサはまだ接続されていないのでまだデバイスファイルは存在しません。 次に、URGセンサを接続してみます。URGセンサをArmadilloのUSBコネクタに接続すると以下のようなメッセージが表示されます。
usb 1-1: new full speed USB device using fsl-ehci and address 4 usb 1-1: device descriptor read/64, error -71 usb 1-1: configuration #1 chosen from 1 choice
CDC ACMドライバをカーネルに直接組み込んだ場合は、/dev/ttyACM0 ができているはずです。モジュールとして組み込んだ場合は、ドラバモジュールをロードする必要があります。デバイスモジュールのロードには modprobe コマンドを使います。
[root@armadillo440-0 (ttymxc1) /etc]# modprobe cdc-acm Using /lib/modules/2.6.26-at16/kernel/drivers/usb/class/cdc-acm.ko cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters [root@armadillo440-0 (ttymxc1) /etc]# ls -l /dev/ttyACM* crw-rw---- 1 root root 166, 0 Aug 19 14:55 /dev/ttyACM0
以上で、CDC ACMドライバがシステムに組み込まれていることが確認できました。
CDC ACMドライバをカーネルに直接組み込んだ場合は、URGセンサを接続しArmadilloを起動すると自動的にデバイスが利用可能になりますが、モジュールとして組み込んだ場合 modprobe でドライバモジュールを組み込む必要があります。
Armadillo の /etc/config/rc.local にmodprobeコマンドを追加することで、自動時に自動的にモジュールをロードするよう設定します。
[root@armadillo440-0 (ttymxc1) ~]# vi /etc/config/rc.local
viエディタでrc.localのPATH設定を行っている部分の後ろくらいに以下のようなコマンドを入力します。
PATH=/bin:/sbin:/usr/bin:/usr/sbin # ここから if test -f /lib/modules/2.6.26-at16/kernel/drivers/usb/class/cdc-acm.ko; then echo -n "Loading CDC ACM driver" modprobe cdc-acm check_status fi # ここまで
上述したように、/etc/config 以下のディレクトリは保存可能なコンフィギュレーション領域ですので flatfsd コマンドを使って保存することができます。
[root@armadillo440-0 (ttymxc1) ~]# flatfsd -s flatfsd: saving fs to partition 0, tstamp=1 flatfsd: Wrote 5720 bytes to flash in 1 seconds
Armadilloを再起動して、ドライバ組み込まれるかどうかを確認します。
起動中以下のようなメッセージが出るか
Loading CDC ACM driverUsing /lib/modules/2.6.26-at16/kernel/drivers/usb/class/cdc-acm.ko cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters done
dmesg コマンドを使って確認することができます。
cdc_acm 1-1:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
以上でURGセンサのためのCDC ACM USB Modemドライバの組込みは終了です。
この節で使用したファイルを以下からダウンロードできます。
ファイル名 (サイズ) | 説明 | 日付 |
ドライバ設定: カーネルモジュール | ||
cdcacm_mod_linux.bin.gz 1,764,568 bytes |
CDC ACM ドライバを組み込んだArmadillo-440用カーネルイメージ。 CMSのシステムの都合上ファイル名が linux.bin_.gz となっています。 |
2012.08.19 |
cdcacm_mod_romfs.img.gz 11,071,893 bytes |
CDC ACM ドライバを組み込んだArmadillo-440用ユーザランドイメージ。 CMSのシステムの都合上ファイル名が romfs.img_.gz となっています。 |
2012.08.19 |
cdcacm_mod_kernel_config.config 43,774 bytes |
上記設定をしたLinuxカーネル設定ファイル。(元ファイル名は linux-2.6.x/.config) | 2012.08.19 |
ドライバ設定: カーネル組込み | ||
cdcacm_embd_linux.bin.gz 1,764,568 bytes |
CDC ACM ドライバを組み込んだArmadillo-440用カーネルイメージ。 CMSのシステムの都合上ファイル名が linux.bin_.gz となっています。 |
2012.08.19 |
cdcacm_embd_romfs.img.gz 11,071,893 bytes |
CDC ACM ドライバを組み込んだArmadillo-440用ユーザランドイメージ。 CMSのシステムの都合上ファイル名が romfs.img_.gz となっています。 |
2012.08.19 |
cdcacm_embd_kernel_config.config 43,774 bytes |
上記設定をしたLinuxカーネル設定ファイル。(元ファイル名は linux-2.6.x/.config) | 2012.08.19 |
ArmadilloでRalink Chipの無線LANアダプタを利用する方法について説明する。 対象とするのは、比較的ポピュラーな Ralink Chipを(RT3070/RT3370/RT5370/RT5372系チップ) 搭載したUSB無線LANインターフェース。
Armadillo-440用のデフォルトのカーネル (linux-a400-1.09.bin.gz) では無線LANに関するオプションが有効になっていないため、無線LANを有効にしカーネルの再コンパイルが必要となる。
上のようなカーネルの設定画面が表示されたら、下記の無線LANデバイスに関するオプションにチェックをつける。
Exitしてカーネルの設定メニューを抜ける。
カーネルの設定画面を抜けると、ユーザランドの設定画面が起動する。
Network Applicationsの設定に入り、下の方の hostap にチェックをいれる。すると、更に下層のメニューが開くので、wpa_supplicant にチェックを入れる。
この他
などのWLAN関係のツールがチェックされていることを念のため確認。
以上が終わったらExitで抜ける。
このままmakeを行うと、madwifi関係のコンパイルでエラーになるため、user/hostap/wpa_supplicant/.config の設定を変更する。
$ vi user/hostap/wpa_supplicant/.config
として、以下のように CONFIG_DRIVER_MADWIFI=y をコメントアウトする。
# Driver interface for madwifi driver #CONFIG_DRIVER_MADWIFI=y # Change include directories to match with the local setup CFLAGS += -I$(ROOTDIR)/$(LINUXDIR)/drivers/net/wireless/madwifi
以上が終了したら、コンパイルを行います。 atmark-dist 直下のディレクトリで make clean と make を行います。 以前コンパイルしたオブジェクトファイルなどが残っている場合があるので、make clean は必ず行ってください。 コンパイルはPCの性能にもよりますが、数分から十数分かかります。
atmark@atde3:~/work/atmarkdist/atmark-dist$ make make -C tools/sg-cksum make[1]: ディレクトリ `/home/atmark/work/atmarkdist/atmark-dist/tools/sg-cksum' に入ります : 数分から十数分 : /home/atmark/work/atmarkdist/atmark-dist/tools/cksum -b -o 2 /home/atmark/work/atmarkdist/atmark-dist/images/linux.bin.gz >> /home/atmark/work/atmarkdist/atmark-dist/images/linux.bin.gz make[1]: ディレクトリ `/home/atmark/work/atmarkdist/atmark-dist/vendors/AtmarkTechno/Armadillo-440' から出ます atmark@atde3:~/work/atmarkdist/atmark-dist$
Ralinkのサイトからドライバのソースコードをダウンロードする。
以下に、Ralinkチップを使用したUSB無線LANデバイスのリストを示す。
RT3070/RT3370/RT5370/RT5372系チップ用ドライバは以下からダウンロード可能。
メーカー | 型番 | VID:PID | Chip |
RT8070系チップ | |||
BUFFALO | WLI-UC-GNM | 0411:01a2 | RT8070V |
LOGITEC | LAN-GMW/DS | 0789:0168 | RT8070V |
LOGITEC | LAN-GMW/PSP | 0789:0168 | RT8070V |
LOGITEC | LAN-W150N/U2 | 0789:0164 | RT8070V |
RT3070系チップ | |||
PLANEX | GW-USMicroN | 2019:ED14 | RT3070L |
PLANEX | GW-USMicroN-G | 2019:ED14 | RT3070L |
PLANEX | GW-USMicro300 | 2019:AB29 | RT3072L |
Logitec | LAN-W150N/U2DS | 0789:0164 | RT3070? |
Logitec | LAN-WN11/U2 | 0789:0164 | RT3070L |
BUFFALO | WLI-UC-GN | 0411:015D | RT3070L |
BUFFALO | WLI-UC-GNHP | 0411:0158 | RT3070L |
BUFFALO | WLI-UC-GNP | 0411:019E | RT3070L |
BUFFALO | WLI-UC-GNT | 0411:015D | RT3070L |
BUFFALO | WLI-UC-GNM | 0411:01A2 | RT3070L? |
BUFFALO | WLI-UC-GNM2 | 0411:01A2 | RT3070L? |
BUFFALO | WLI-UC-GNM2R | 0411:01A2 | RT3070L? |
BUFFALO | WLI-UC-G301N | 0411:01A2 | RT3070L? |
IODATA | WN-G150U | 04BB:0947 | RT3070 |
RT3370系チップ | |||
BUFFALO | WLI-UC-G300N | 0411:00E8 | RT3370 |
BUFFALO | WLI-UC-G300HP | 0411:0148 | RT3370 |
BUFFALO | WLI-UC-GNHP | 0411:0158 | RT3370 |
BUFFALO | WLI-UC-GN | 0411:015D | RT3370 |
BUFFALO | WLI-UC-GNP | 0411:019E | RT3370 |
BUFFALO | WLI-UC-GNM | 0411:01A2 | RT3370 |
Logitec | LAN-W300N/U2 | 0789:0166 | RT3370 |
PLANEX | GW-USMini2N | 2019:AB25 | RT3370 |
RT5370系チップ | |||
BUFFALO | WLI-UC-G300N | 0411:00E8 | RT5370 |
BUFFALO | WLI-UC-AG300N | 0411:012E | RT5370 |
BUFFALO | WLI-UC-G300HP | 0411:0148 | RT5370 |
BUFFALO | WLI-UC-GNHP | 0411:0158 | RT5370 |
BUFFALO | WLI-UC-GN | 0411:015D | RT5370 |
BUFFALO | WLI-UC-GNP | 0411:019E | RT5370 |
BUFFALO | WLI-UC-GNM | 0411:01A2 | RT5370 |
Logitec | LAN-W300N/U2 | 0789:0166 | RT5370 |
PLANEX | GW-USMini2N | 2019:AB25 | RT5370 |
RT2800系チップ用ドライバは以下からダウンロード可能。RT3070/RT3370/RT5370/RT5372系チップ用ドライバで動作するとの情報もあるが詳細は不明。
http://www.ralinktech.com/en/04_support/license.php?sn=5021
メーカー | 型番 | VID:PID | Chip |
RT2800系チップ | |||
BUFFALO | WLI-UC-G300N | 0411:00E8 | RT2800 |
BUFFALO | WLI-UC-AG300N | 0411:012E | RT2800 |
BUFFALO | WLI-UC-G300HP | 0411:0148 | RT2800 |
BUFFALO | WLP-UC-AG300 | 0411:0150 | RT2800 |
BUFFALO | WLI-UC-GNHP | 0411:0158 | RT2800 |
BUFFALO | WLI-UC-GN | 0411:015D | RT2800 |
BUFFALO | WLI-UC-G301N | 0411:016F | RT2800 |
BUFFALO | WLI-UC-GNM | 0411:01A2 | RT2800 |
Logitec | LAN-WN22/U2 | 0789:0162 | RT2800 |
Logitec | LAN-WN12/U2 | 0789:0163 | RT2800 |
Logitec | LAN-W150/U2M | 0789:0164 | RT2800 |
Logitec | LAN-W300N/U2 | 0789:0166 | RT2800 |
Logitec | LAN-W150N/U2 | 0789:0168 | RT2800 |
Corega | CG-WLUSB2GNL | 07AA:002F | RT2800 |
Corega | CG-WLUSB2GNL | 07AA:003C | RT2800 |
Corega | CG-WLUSB300AGN | 07AA:003F | RT2800 |
Corega | CG-WLUSB300GNS | 07AA:0041 | RT2800 |
Corega | CG-WLUSB300GNM | 07AA:0042 | RT2800 |
PLANEX | GW-US300MiniS | 2019:AB24 | RT2800 |
PLANEX | GW-USMini2N | 2019:AB25 | RT2800 |
PLANEX | GW-US300MiniW | 2019:ED06 | RT2800 |
RT2870系チップ | |||
エレコム | LAN-W150N/U2KT | 0789:0168 | RT2870 |
BUFFALO | WLI-UC-G300N | 0411:00E8 | RT2870 |
Logitec | LAN-WN22/U2 | 0789:0162 | RT2870 |
Logitec | LAN-WN12/U2 | 0789:0163 | RT2870 |
Logitec | W150/U2M | 0789:0164 | RT2870 |
Corega | CG-WLUSB2GNL | 07AA:002F | RT2870 |
Corega | CG-WLUSB2GNL | 07AA:003C | RT2870 |
Corega | CG-WLUSB300AGN | 07AA:003F | RT2870 |
PLANEX | GW-USMini2N | 2019:AB25 | RT2870 |
PLANEX | GW-US300Mini | 2019:ED06 | RT2870 |
PLANEX | GW-USMicroN | 2019:ED14 | RT2870 |
ダウンロードしたソースをatmark-distと同じディレクトリに展開する。 なお、ダウンロードしたソースはファイル名の拡張子がbz2のみになっているが実際はtar.bz2圧縮である。
$ tar xvjf 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.bz2 $ mv 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO RT3070 // ディレクトリ名が長いので修正 $ cd RT3070
を当てる。
$ wget http://aaaaa/RT3070.patch $ patch -p1 < RT3070.patch
makeする。 atmark-dist と同じディレクトリ以外に展開した場合、環境変数 ATMARKDIST_DIRに設定してmakeする必要がある。 以下の例では、atmark-dist が /home/atmark/work/atmark-dist にあると仮定している。
$ ATMARKDIST_DIR=/home/atmark/work/atmark-dist make $ ATMARKDIST_DIR=/home/atmark/work/atmark-dist make install
これにより、atmark-dist/romfs以下のディレクトリにカーネルモジュール (rt5370sta.ko) と設定ファイル (RT2830STA.dat) が保存される。
Armadilloに書き込むための romfs イメージを再度作成する。
$ cd /home/atmark/work/atmark-dist $ make image $ ls -al images 合計 45300 drwxr-xr-x 2 atmark atmark 4096 2012-08-12 11:46 . drwxr-xr-x 15 atmark atmark 4096 2012-08-13 01:26 .. -rwxr-xr-x 1 atmark atmark 3626594 2012-08-12 15:54 linux.bin -rw-r--r-- 1 atmark atmark 1769841 2012-08-12 15:54 linux.bin.gz -rw-r--r-- 1 atmark atmark 29314085 2012-08-12 15:54 romfs.img -rw-r--r-- 1 atmark atmark 11603547 2012-08-12 15:54 romfs.img.gz
カーネル linux.bin.gz およびユーザランド romfs.img.gz
hermitなどを立ち上げてromfs.img.gz をユーザランドにダウンロードする。 詳細については、アットマークテクノの以下のページを参照してください。
# wpa_passphrase <SSID>
により、パスフレーズ入力プロンプトが表示されるので、パスフレーズを入力すると以下のように暗号化された psk のキーが出力される。
# wpa_passphrase HOGE # reading passphrase from stdin 4332221111 network={ ssid="HOGE #psk="4332221111" psk=b7752c14f1586911c99a4bbce1ad3921f5bbbb9e62a05dcc8f7be6fae8c2fca5
無線LAN用に /etc/config/interfaces を以下のように修正する。
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8) auto lo ra0 iface lo inet loopback #iface eth0 inet dhcp iface ra0 inet dhcp pre-up modprobe rt5370sta wpa-ssid MARISA wpa-psk b7752c24f1586911c99a4bbce1ad3921f5bbbb9e62a05dcc8f7be6fae8c2fca5 scan_ssid 0 ap_scan 11
さらに、flatfsd で変更された interfaces ファイルを flatfsd で config 領域に保存する。
# flatfsd -s
再起動し無線LANが動作していることを確認する。
Configuring network interfaces: Using /lib/modules/2.6.26-at16/kernel/drivers/net/wireless/rt5370sta.ko rtusb init rt2870 ---> usbcore: registered new interface driver rt2870 no /sbin/wpa_supplicant found; none killed. ioctl[SIOCSIWPMKSA]: Network is down ioctl[SIOCSIWMODE]: Network is down Could not configure driver to use managed mode 0x1300 = 00064300 ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 4 value 0x0 - udhcpc (v0.9.9-pre) started Sending discover... Sending discover... Sending discover... Sending select for 192.168.11.16... Lease of 192.168.11.16 obtained, lease time 86400 done Starting inetd: done
ログイン後、iwconfig, ifconfig などで動作状況を確認できる。
# iwconfig ra0 ra0 Ralink STA ESSID:"MARISA" Nickname:"RT2870STA" Mode:Managed Frequency=2.437 GHz Access Point: 00:3A:9D:DC:7C:6A Bit Rate=270 Mb/s RTS thr:off Fragment thr:off Encryption key:BA10-1A03-2808-3D5E-1F43-2A50-BF10-25A7 Security mode:open Link Quality=100/100 Signal level:-53 dBm Noise level:-74 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 # ifcnofig ra0 ra0 Link encap:Ethernet HWaddr 00:22:CF:41:6F:4D inet addr:192.168.11.16 Bcast:192.168.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:658590 (643.1 KiB) TX bytes:50439 (49.2 KiB)
何らかの理由でモジュールがロードできていない場合、無線LANデバイスは使用できない。
# lsmod (ロードされているモジュールを見る) Module Size Used by Not tainted rt5370sta 752944 1 - Live 0xbf000000
もし、rt5370sta モジュールがロードされていない場合、手動でロードしてみる。
# modprobe rt5370sta または # insmod /lib/modules/2.6.26-at16/kernel/drivers/net/wireless/rt5370sta.ko
モジュールがロードされているのにに、ネットワーク・インターフェース ra0 が起動しない場合、手動で起動してみる。
# ifconfig ra0 up # ifconfig ra0 ra0 Link encap:Ethernet HWaddr 00:22:CF:41:6F:4D inet addr:192.168.11.16 Bcast:192.168.11.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:658590 (643.1 KiB) TX bytes:50439 (49.2 KiB)
ネットワークインターフェースが割り当てられない場合、手動でDHCPクライアントを起動してみる。
# udhcpc -b -p /var/run/udhcpc.ra0.pid -i ra0
この節で使用したファイルを以下からダウンロードできます。
ファイル名 (サイズ) | 説明 | 日付 |
ドライバ設定: カーネルモジュール | ||
rt3070_mod_linux.bin.gz 1,765,638 bytes |
CDC ACM, RT3070系ドライバを組み込んだArmadillo-440用カーネルイメージ。 CMSのシステムの都合上ファイル名が linux.bin_.gz となっています。 |
2012.08.19 |
rt3070_mod_romfs.img.gz 11,594,936 bytes |
CDC ACM, RT3070系ドライバを組み込んだArmadillo-440用ユーザランドイメージ。 CMSのシステムの都合上ファイル名が romfs.img_.gz となっています。 |
2012.08.19 |
rt3070_configs.tar.gz 19,440 bytes |
上記設定をしたLinuxカーネル設定ファイル。 | 2012.08.19 |
rtc-make-cross [OPTION]... [make OPTIONS]...
rtc-make-cross はRTコンポーネントのクロスコンパイルを補助するツールです。 rtc-template や RTCBuilder が生成する旧形式の Makefile をサポートしてい ます。
このコマンドは make コマンドのラッパーとして働き、環境変数 CC/CXX/AR/LD をクロスコンパイルに必要なツールへのパスに設定し、make を 実行します。
このコマンドはシステムの /usr 以下の Endebian クロス開発環境を検索し、 クロスコンパイルに必要なツールを見つけます。このコマンドがクロスコンパ イルツールチェーンを見つけるためには、Endibian クロス開発環境が通常のイ ンストールルールに基づき /usr 以下にインストールされている必要がありま す。それぞれのクロス開発環境は arm-linux-gnu, powerpc-linux-gnu といっ た名前でなければなりません。
2つ以上のクロス開発環境が見つかった場合は、使用するクロスコンパイルアー キテクチャを -a オプションを使用して指定する必要があります。インス トールされているクロス開発環境が1種類の場合、その環境が使用されま す。-aでアーキテクチャを指定する必要はありません。
-a で利用可能なアーキテクチャ名は -h オプションでヘルプを表示さ せると確認することができます。
$ rtc-make-cross -h Usage: rtc-make-cross -a <arch_name> [make options] -a target architecture name -h print this help Available architectures: arm powerpc
この環境では、armとpowerpcのクロス開発環境が利用できることがわかります。
上記以外のコマンドラインオプションは、すべて make コマンドに渡されます。 下の例は、make において clean ターゲットを実行します。
$ rtc-make-cross -a arm clean
下の例では、Makefile として Makefile.ConsoleIn を指定します。
$ rtc-make-cross -a arm -f Makefile.ConsoleIn
バグを発見した場合は、<n-ando@aist.go.jp> ご連絡ください。
このコマンドは安藤慶昭 <n-ando@aist.go.jp> により作成されました。
Copyright (c) 2012, Noriaki Ando
rtc-cmake-cross [OPTION]... [make OPTIONS]... rtc-ccmake-cross [OPTION]... [make OPTIONS]...
rtc-cmake-cross はRTコンポーネントのクロスコンパイルを補助するツールで す。RTCBuilder が生成する新形式の CMake (CMakeList.txt) をサポートして います。
このコマンドは cmake および ccmake コマンドのラッパーとして働きます。ク ロス開発環境を自動的に調査し、cmake でのクロスコンパイルに必要な、いわ ゆる ツールチェーンファイル を生成します。 cmake/ccmake に対して -DCMAKE_TOOLCHAIN_FILE オプションでツールチェーンファイルを cmake/ccmake に渡し実行します。
このコマンドはシステムの /usr 以下の Endebian クロス開発環境を検索し、 クロスコンパイルに必要なツールを見つけます。このコマンドがクロスコンパ イルツールチェーンを見つけるためには、Endibian クロス開発環境が通常のイ ンストールルールに基づき /usr 以下にインストールされている必要がありま す。それぞれのクロス開発環境は arm-linux-gnu, powerpc-linux-gnu といっ た名前でなければなりません。
2つ以上のクロス開発環境が見つかった場合は、使用するクロスコンパイルアー キテクチャを -a オプションを使用して指定する必要があります。インス トールされているクロス開発環境が1種類の場合、その環境が使用されま す。-aでアーキテクチャを指定する必要はありません。
-a で利用可能なアーキテクチャ名は -h オプションでヘルプを表示さ せると確認することができます。
$ rtc-make-cross -h Usage: rtc-make-cross -a <arch_name> [make options] -a target architecture name -h print this help Available architectures: arm powerpc
この環境では、armとpowerpcのクロス開発環境が利用できることがわかります。
上記以外のコマンドラインオプションは、すべて cmake/ccmake コマンドに渡 されます。下の例は、buildディレクトリを作成し、そこでcmakeを実行します。
$ mkdir build $ cd build $ rtc-cmake-cross -a arm ..
下の例では、cmake に対して変数 OPENRTM_INCLUDE_DIR をコマンドラインから指定して ccmake を実行します。
$ rtc-cmake-cross -a arm -DOPENRTM_INCLUDE_DIR=/usr/openrtm-1.1 ..
バグを発見した場合は、<n-ando@aist.go.jp> ご連絡ください。
このコマンドは安藤慶昭 <n-ando@aist.go.jp> により作成されました。
Copyright (c) 2012, Noriaki Ando