openSUSEでAruduino IDEを使うときの注意点

色々あって転職して会社が変わりました。

といってもやってる仕事内容はそんなに変わらずで、
ちょくちょく過去に自分で書いたメモを参考にしたりして作業してました。

毎度毎度そろそろ更新しよう・・・と思うのですがねぇ。


愚痴はさておき、openSUSEでAruduino IDEを使用する際に、
はまってしまった点があったのでメモ書きです。

結構前に興味本位で購入して、かるーく遊べると思って手を出したら、
USBシリアル経由でプログラムをダウンロードできなくてハマりました。

最初はIDEから「ツール」→「シリアルポート」を選ぼうとしたら灰色になっていて、
選択できない状態でした。

困ったなぁと思っててきとーにググってみると、"ttyACM0"じゃないと認識しないよ？
とか、Ubuntuの場合はttyUSB0でも接続できるパッチがあるよ？
なんて、いろんな情報が書いてありました。

色々やってみても全然状況は良くならなくて、おいおいどーいうこった不良品か？（笑）
なんて考え始めたので、初心に戻って単純に通信できるかを確認してみたところ・・・
なんてことない、デフォルト状態でuserでは/dev/ttyUSB0にアクセスする権限が無かった！
というオチでした。

ということで・・・・
usermod -Gでdialout uucp lockのグループを追加してあげた
ことで「ツール」→「シリアルポート」はちゃんと選択できるようになりました。

ttyUSB0のままでも大丈夫でしたよ！




過去の自分の記事に助けられたことが何度かあるので、
これからはもう少しマメに・・・・・。

UBIFSを使ってみた その３

続き。

UBIFSのImageを作成する方法です。

FilesystemのImage自体は、他のFilesystemと同じで、mkfsを使用します。
# mkfs.ubifs –r rootfs_dir –x none –m 2048 –e 129024\
   –c 4096 –o rootfs.ubifs
これでrootfs_dirっていう名前のディレクトリの中身をrootfs.ubifsっていう名前のimageにします。

-mはminimum I/O unit sizeでFlashの書き込みサイズを入れる。
-eはlogical erase block sizeでFlashのブロックサイズ（消去）を入れる。
-cはmaximum logical erase block countでFlashのブロックの数を入れる。
ということで、↑の例は2Kずつアクセスできる512MBのNANDになります。

 

さて、FilesystemのImageを作った後に、このImageをUBI用に変換しなければいけないんです。
そのためにubinizeを使用します。

まずは、↓のようなconfigファイルを作って適当な名前(rootfs_ubi.cfg)で保存する。
-----------------------------------------------------------------
[rootfs-volume]
mode=ubi
image=rootfs.ubifs
vol_id=0
vol_size=128MB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
-----------------------------------------------------------------
その後、ubinizeを使ってUBI用に変換してあげる。
# ubinize –o rootfs.img –m 2048 –p 128KiB –s 512 rootfs_ubi.cfg
これで、rootfs.imgという名前のUBI用Imageが完成します。

 

完成したImageを書き込む為には、Target上でubiformatを使います。
# ubiformat /dev/mtd0 –f rootfs.img
これで、mtd0をUBIにしてrootfs.imgを書き込んだ状態になります。

# ubiattach /dev/ubi_ctrl –m 0
をすると、/dev/ubi0_0が既に出来てるはずです。

 

作ったubifsをrootfsとして起動したい場合、起動時のcommandに”ubi.mtd=0 root=ubi0:rootfs”を追加すると、mtd0をubi0としてattachして、mountしてくれます。

u-bootの場合は、環境変数bootcmdに追加すればOKです。

 

ざっと、こんな感じです。

きっと、未来の私が確認しにくることでしょう(｀・ω・´)

UBIFS使ってみた その２

続き。
実際にUBIFSを使う方法です。

まずは環境。

kernelがUBIやUBIFSに対応していないとお話にならないので、kernelのmake menuconfigで内容の確認です。
↓ の２つが有効になってれば大丈夫だと思います。

---------------------------------------------------------
Device Drivers --->
    Memory Technology Device (MTD) support --->
        UBI – Unsorted block images --->
            <*> Enable UBI

File systems --->
    Miscellaneous filesystems --->
        <*> UBIFS file system support
---------------------------------------------------------

それから、image作成したり、formatしたりと操作するために、mtd-utilsに内包されている、ubi-utilsが必要になります。

ソースをmtd-utilsのrepositoryからdownloadして、Host用とTarget用の二種類makeして作成してください。

出来上がったものをHostとTargetのPathが通ってるところにコピーしてください。

 

UBIの使い方。

UBIを介してMTDにアクセスする為には、ubiattachでubiのdeviceを作成 and MTDと関連付けをしてあげる必要があります。

例えば、/dev/mtd1に対してattachする場合は、
# ubiattach /dev/ubi_ctrl –m 1
を実行すると、/dev/ubi0が作成されます。

/dev/ubixのxは、defaultだとattach順になりますが、-d optionを使用すると任意の番号になります。

UBIはvolumeというpartitionみたいなものをdevice毎に持ってます。
/dev/ubi0の中に複数のファイルシステムを作り、管理することが可能です。

例えば”testfs”という名前のvolumeを作成するにはubimkvolを使って、
# ubimkvol /dev/ubi0 –N testfs –m
と実行すると、/dev/ubi0_0が作成されます。

mountする際は、/dev/ubi0_0を指定しても大丈夫ですが、volume名を指定してもmountできます。
# mount –t ubifs ubi0:testfs /mnt
こんな感じです。

volumeを消したい時はubirmvol、MTDとの関連付けを外したい時はubidetachを使用します。

ただUBIを使いたいだけだったらこれだけでも十分だとは思いますが、やっぱり組込で開発していると、予め作成したimageファイルを書き込むのが一般的だと思います。

imageの作成方法や書き込み方はUBIFSの作成の仕方と一緒に書こうと思っていますが、なんだか文章が長くなってしまったので、続きは後ほどその３に書きます。

 

・・・お昼休み終わっちゃってるし (；・∀・)

UBIFS使ってみた その１

約１年ぶりの更新です。

１年前に腰を壊して以来、ずーっと放置してました(-_-;)
おかげで、英英辞典のやつは３日坊主になってますね・・・。

ぼちぼちゆっくりと更新していきまする。

 

さて、表題のUBIFSの話。

UBIFSはUBI専用のファイルシステムで、
”UBIFS may be considered as the next generation of the JFFS2 file-system.”
多分JFFS2の次の世代（後継と読んだ方がいいのかな？）になると考えてるらしい、MTD (Memory Technology Device) 用のファイルシステムです。

ではUBIとは何か？というと、”Unsorted Block Images”の略で、MTDと各ファイルシステムの間に入って、データを順番にではなく色んな場所に分けて書き込み（ウェアレベリング）をしてくれるものです。

Flash Memoryって簡単に言うと、コンデンサの周りを絶縁体で固めて漏電しないようにした物の集合体みたいなもので、書き込みする時は電子を貫通させてるんですね。
何回も貫通させてると劣化して書きこめなくなっちゃうんです。
同じところばっかり書き換えしていると、部分的に劣化してしまったりします。

よくPCで使用されているFATやNTFS等は部分的に壊れて（bad block）読めなくなってしまうと、他の様々なファイルも読めなくなっちゃいます。

SSD等は中に入ってるコントローラがウェアレベリングしてくれてるので大丈夫なんですが、NANDをそのまま使う組込の世界では、ファイルシステムで吸収してあげないといけないのですね。

そこで生まれたのがJFFS2やYAFFS2といったウェアレベリング対応のファイルシステムで、UBIはその機能をMTDとファイルシステムの間に入れることで、どんなファイルシステムでも使えるようにしよう！としたもの・・・だと思います。

でもFTLじゃないよ！！”UBI is not a Flash Translation Layer” って公式の説明には書いてありましたｗ

↓ は公式サイトにあるDocumentから持ってきた図。

 

困った事に、簡単な説明を書いただけで随分と長めの文章になってしまったので、使い方等は明日書こうかなと思います。

備忘録になるので忘れずに！
意外と過去の自分の記事って自分に役立つなぁって開発中に思いました。

container_of

 

LinuxのDevice Driverを眺めていると、ちょくちょく見かけるマクロです。
使う機会も割と多いため、覚えて損は無いです。

私も忘れないように一応メモを。

 

定義場所は”$(kernel_dir)/include/linux/kernel.h”
(kernelはlinux-2.6.34を参照)

#define container_of(ptr, type, member) ({ \
        const typeof( ((type *)0)->member ) *__mptr = (ptr); \
        (type *)( (char *)__mptr – offsetof(type,member) );})

Cast a member of a structure out to the containing structure.
てことで、memberを入れると、それを持ってる変数のaddressを返してくれるです。

 

具体的には、

struct test_structure {
    struct sub_structure member;
};

struct test_structure parent;
struct sub_structure *child = &parent.member;

struct test_structure *test;
test = container_of(child, struct test_structure, member);

これでtestにはparentのアドレスが入るって動きです。

 

「”私(1)”は”○○構造体(2)”の”××っていうmember(3)”です！」と言えば、
親を探してくれるって感じで覚えてます。
# 数字は引数の順番

ticklessなkernel

 

ノートPCや組み込み用のkernelでよくよくお世話になる、
tickless(CONFIG_NOHZ)のお話です。

 

LinuxのKernelは、定期的なtimer割り込みによって、
schedulerの管理をしています。

その定期的なtimer割り込みの単位をtickっていう言い方をして、
tickを格納している変数がjiffiesです。

timer割り込みの間隔は、CONFIG_HZによって設定されていて、
100HZ, 250HZ, 1000HZから選べるようになっているはず。
（Targetによって違いがあるかも）

仮に100HZとなっていたら1秒間に100回、つまり10msに一回の
timer割り込みが入り、その度にtickがカウントされるという仕組み
になっています。

 

定期的に割り込み処理が入り、schedulerが呼ばれますから、
当然idleの時間は短くなってしまいます。
（何もしなくても、ね）

そうなると、消費電力を気にするモバイル機器にとっては、
邪魔者以外何物でもなくなります。

 

そこで登場したのがtickless。

tickless(CONFIG_NOHZ)では、timer割り込みは動作せず、
scheuleは他の割り込みから呼ばれることになります。

jiffiesも同じタイミングでカウントされる為、定期的なカウントアップはしませんが、
時間管理として使用できるようにきちんと補正しています。

そーすることで、定期的に起こる無駄な処理を省き、idle時間を長くすることで、
消費電力を抑えることができます。

 

っとまぁ、こんな感じのものです。

自分で選んで使用してる癖に、度忘れしてしまっていたので、
思い出しながら書いてみました。

Debian系でnetwork interfaceの設定

 

なんだか、久々にブログ書いている気がする。

 

本日はちょこっとメモを。

Debian系ディストロでnetwork interfaceのIPアドレスを、Hotplug時に割り振る方法が分からなかったので、残しておきます。

 

やりたかったこと：
・とあるinterfaceに対してIPアドレスを静的に割り振る
・hotplug時に自動的に割り振るようにする

Debian系ディストロの場合、/etc/network/interfacesファイルに、
全network interfaceの設定が書いてあるです。

auto eth0
iface eth0 inet static
    address 192.168.0.1
    network 192.168.0.0
    netmask 255.255.255.0
    broadcast 192.168.0.255

って感じで書いてあるのだけど、このままだとhotplug対応してないみたいなんです。

それだと、usb ethernet gadgetなど後で接続するinterfaceは、
とーっても不便なので、ちょいと探してみました。

 

答え：

/etc/network/interfacesファイルを編集。

allow-hotplug $(device name) を追加でOK。
例） allow-hotplug etc0

 

ちなみに、OpenSUSEの場合は、
/etc/sysconfig/network/ifcfg-$(device name)ファイル
がInterfaceの数だけ存在して、STARTMODE=’hotplug’って
書いてあげることで同じことができるです。

全然違うと混乱しますよねぇ。

likely()とunlikely()

 

時々とんだ勘違いすることがあるので、忘れないようにmemoです。

Linuxのsourceを眺めてると度々、
if (likely(skb != NULL)) とか、
if (unlikely(local_softirq_pending())) のように、
わざわざif文をlikely() or unlikely()で括ってるものを見かけます。

“un”が頭についてると、ひっくり返したくなる気持ちがこみ上げてきて、
どーしても混乱しちゃうのは私だけですかねぇ？

 

とりあえず・・・・
likely()は、答えが真の場合に高速動作するようにコンパイルしなさい！
unlikely()は、答えが偽の場合に高速動作するようにコンパイルしなさい！
っていう意味です。

それぞれの中身は、
#define likely __builtin_expect(!!(x), 1)
#define unlikely __builtin_expect(!!(x), 0)

__builtin_expect()は、GCCに対し分岐方向のヒントを与えるものです。
第一引数が第二引数の場合は、高速動作するようにしてね！ってね。
# 通常の道をどれにするかのヒントでしょうね（突き進む方向とジャンプする方向）

 

実際にsourceを読む際は、一切無視して構わないってことです。
なのに、時々勘違いしてしまう。

うーむ。

 

新しいノートPCをGetしたことだし、Blogもボチボチ再開しよう。
そんな風に思いながら早５日。

覚えたことを忘れない為に、Blogに書いていたはずなのに、
続かなきゃ意味ないですね（汗）

調べたものや、読んだ書籍など、ネタは溜まってきてるので、
これからちょこちょこと更新するようにします。
# 読んでくれてる方宛？ いや未来の自分宛

buildrootを使ってみよう その２

 

buildrootを使ってみよう その１の続きです。

buildrootをmakeした結果、outputディレクトリの下に、
開発環境やファイルシステム等が生成されていました。

buildroot/output/staging/usr/bin –> gcc等
buildroot/output/staging/usr/lib –> libc.so等
buildroot/output/target –> ファイルシステム
buildroot/output/images –> イメージ化済のファイルシステム(ext2等)

buildroot-2009.11ではこんな感じです。
# versionによっては異なることもあるようです

今回はARM用にmakeしてみたので、
arm-linux-XXXっていうファイルがたくさんできました。

 

さて、肝心の動作確認です。
Target用の実行ファイルを作成し、qemuを使って実行してみます。

実行ファイルは、おなじみhello.cです。
makeは今回作成したarm-linux-gccです。
libraryも含めるように-staticを付けてmakeしました。

 

ドキドキしながら動作させてみると、サクっと動いちゃいました。

こーんな感じです。

上から、
１．fileの内容を確認
２．x86上で普通に実行
３．qemu上で実行

rootで実行してるのは、色を付けたかっただけです。

# あー・・・へいよーぐっつすっすはスルーしてください
# 先日みたニコニコ動画のとある動画の影響デス

 

これで、実機でも動くことを確認できたら、文句なしですね！

実はお仕事で使ってるのがARMなので、
隙を見てコッソリ動かしてみようかと思ってます。

ファイルシステムの方は・・・流石にコッソリFlashに焼くとかは無理だなぁ（汗）
今度やすーいボードを買うことも検討してみよう。

 

ところで、qemuのインストール方法ですが、
openSUSEならYaST2のSoftware Managementで、
”qemu”を検索して、出てきたのをインストールするだけです。

引っかかるのが一個だけなので何も悩む必要ないですね。

zypper install qemu でもきっと大丈夫だと思います。
# 私は試してません

他のディストロでも、apt-getやらyumやらで簡単にインストールできるはずです。

インストールするとqemu-XXXっていう実行ファイルがたくさん使えるようになるので、
アーキテクチャに合わせて使ってみてください。

buildrootを使ってみよう その１

 

buildrootというのは、様々なTargetの開発環境やルートファイルシステムを、
kernelのmenuconfigと同じTUIで作成できるTool(?)です。

ファイルの集合体って言った方がいいのかもしれないですね。
使用するライブラリがuClibcなので、組み込み向けです。

menuはこんな画面です。

試しにTargetとしてARMを選択してみると、

いっぱい出てきました。

こりゃ便利。
いちいち開発環境整えるだけでも大変ですからねぇ・・・。

Targetの選択と、Toolchainの選択と、Packageの選択をして、
makeをすれば簡単にできあがり！

の予定です。

 

実はmakeしながらブログ書いてます（汗）
kernelもそうですが、最初の一回目のbuildはすっごい時間かかるので、
動作確認はまた今度かな。

評価ボード等、実機で動かせるものは持っていないので、
QEMUを使ってみようと思ってます。

QEMUを使えば、クロスコンパイルして作成した実行ファイルを、
ホストコンピュータ上で実行できます（できるはずです）

ファイルシステムは無駄になっちゃうけど・・・・。

 

 

buildrootを使ってみよう その２に続く。

犯人はKDevelop

 

先日、aRtsの暴走で、

ということでESD (Enlightened Sound Daemon) が動いてて欲しいわけで、
aRtsが起動してる理由がサッパリ分かりませぬ。

なんて言ってましたが、犯人が分かりました。

私のような環境で作業するような人なんて、ほとんどいないでしょうから、
きっと困ってる人は少ないと思いますが・・・自分の為にメモ。

 

私がVMware上で使用してるOpenSUSE11.1のデスクトップはGNOME。
なのに、よくKDEの統合開発環境であるKDevelopを使用する。

実はこいつを起動するとKDEのサウンドサーバであるaRtsが起動するようなんです。

そして”何か”と競合してCPUを占有し始めるという。

 

まぁ・・・こんなあべこべなことをしている私が悪かったりもしますが、
これにはちょっとした理由があるのです。（いいわけもーど）

Anjutaのgrep機能が使いづらいんだ！！
Eclipseを私の作業PC上のVMwareで動かすと重いんだ！！
Kateを使いたかったのにどーしても起動してくれないんだ！！

ってことでKDevelopに行き着いたという。

うーん、色んなところで横着したのが原因かｗ

 

ちなみに、KDE4からaRtsではなくPhononになりました。

ってことで、私のようにあべこべな環境で開発するか、KDE3.5を使うかじゃないと、
aRtsとは出会えません。

今となっては（今じゃなくても）レアケースですね、きっと。

 

 

 

あれ・・・もしかしてサウンドをESDじゃなくてaRts使用するようにすれば、
普通に動いてくれそう？？

やってみようかな。

Kernelブートイメージファイルの名前と意味 その２

 

その１でブートイメージファイルを沢山書きましたが、
宿題が結構残っていましたので消化しました。

 

まずはxipImage

xipImage
XIP(eXecute in Place)形式というやつで、
RAMへ展開せずに、極力そのまま使えるようにしたものらしいです。
NORフラッシュ等に余裕があるなら使えそうな形ですね。
今度試してみよう。

menuconfigで設定する人は、
”Boot options –> Kernel Execute-In-Place from ROM”にチェックを入れて、
”Boot options –> XIP Kernel Physical Location”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_XIP_KERNEL”をyにして、
”CONFIG_XIP_PHYS_ADDR”にアドレスを入れる。

んで、お仕事でも使用しているボードでコッソリと試して・・・

試し・・・て・・・・

動かないorz

どうやら、NORがByteアクセス出来ない為に、ちゃんと動かんのです。
まさか実験の為だけにH/W何とかしろなんて言えないので断念です。

 

お次はrImage

rImage
ramcopy形式とMakefileには書いてありました。
無圧縮の形で、とにかく仮想空間への展開だけしてるのでしょうか？
じつはちょっと動きが分からないので、宿題デス。
# 実際ブートローダからjumpしたら動かなかｔｔ

menuconfigで設定する人は、
”Boot options –> Kernel Uncompressed, RAMCOPY”にチェックを入れて、
”Boot options –> RAMCOPY Kernel source address”にアドレスをいれる。

.config直接いぢる人は、
”CONFIG_RAMCOPY_KERNEL”をyにして、
”CONFIG_RAMCOPY_SOURCE_ADDR”にアドレスを入れる。

こっちは動きました。
ほんとにそのまんま、コピーしてジャンプして動くシンプルな形です。

前回は、一先ずDRAMにイメージを展開して、それをLoadしてた為に、
CONFIG_RAMCOPY_SOURCE_ADDRと展開元アドレスが違ってたから、
うまく動かなかったってところですね。

シンプルなので起動速度は結構早いです。
uImageと比べると300msくらいは早くなった気がします。

 

・・・・msかよ！
って思われるかもしれませんが、今時の組み込みLinuxの起動時間は、
ms単位で縮めなきゃいけない状況なのですよ。

uncompressedなんでもちろん容量は大きくなりますが、
所詮はkernelなんで数Mの範囲ですしいいかな。

うん、起動時間とは逆にNORの容量がどんどん増えてきてるので、
kernelを極限まで小さく！なんてことはしなくても大丈夫になりましたねぇ。

 

ってなわけで、宿題消化！

autocmd

 

色々あって、久々の更新。

おかげでOpenSUSE11.2リリースした瞬間にインストールしたのに、
すっかり下記損ねてしまいました。

後で書くつもりです・・・。

 

さて、前回の宿題です。

autocmdは、”ファイルを開いた”とか”バッファから読み込んだ”とか
イベントに応じて自動実行されるコマンドです。

vim usersが好んで好んでやまない機能なようで、
検索すると色々と便利なコマンドが紹介されています。

バイナリデータを16進数表記する方法は、この記事に載っています。
# 使わせてもらいまーす、感謝です。

詳細な使用方法は、このドキュメントに載っています。

 

・・・・けど、個人的にはあまり必要ないなぁと思ってます。
# vim usersには申し訳ないが

私がviを使用する理由は、
・お手軽に使える
・動作が軽い
・Linuxなら必ず使用できる
てな感じなんです。

ちょこっとした用事や、急いでサクっと作業する際に使うので、
自分でカスタム出来るように勉強しても利点が少ないかなぁ・・・。

ここは少し甘えて、先人たちのリソースをありがたく使わせてもらおうと思います。
よさそーなコマンドがあったら紹介しますネ。

CUIのバイナリエディタ

 

Linuxで私の願いを叶えてくれるバイナリエディタを見つけたのでメモです。

 

Linuxにだって沢山のバイナリエディタが存在します。
KDEならKHexEdit、GNOMEならghexなどなど。

でも、私が知っていたのは全部GUIなんですよね。

組み込み開発なんかしてると、Debug用のUARTくらいしか、
Outputできるものが無いことが多いんです。

だから、viのbinary版みたいなものを探していたんですわ。

vimなら”vi –b”で開けばbinaryモードで開ける！！
なんてhelpには書いてありましたが、開いても化け化けで、
16進数表記じゃないんですもの・・・。

とはいえ、odやhexdumpじゃ見てるだけだし、
bviやhiといったフリーソフトはあるようですが、
できれば基本ソフトでなんとかしたい・・・と思ってたんです。

 

で、調べてみたら・・・

「vimならバイナリデータを16進数表記に変換できます」
ΩΩΩ < ナ、ナンダッテー！？

やり方は、”vi -b”(バイナリモード)で開いた後に、
:%!xxd
と打ち込めば変換できます。

元に戻す場合は、
:%!xxd –r
と打ち込めば戻ります。

xxdは16進数変換をしてくれるLinuxのコマンドです。

:%!は、バッファ全体を次に記述されたコマンドに渡し、
結果を反映させて表示しなおす機能のようです。

つまり、バッファ全体をxxdで変換して反映させるという動きなんですね。
表示方法が変わるのではなく、実際に書き換えちゃってます。

ってことでこのまま保存すると困ったことになりそうですから、
必ず元に戻す必要がありますね！

 

色々な方々が記事にしてましたので、ググってみると幸せになれます。

ちなみに、autocmd使えば楽になるよーっていう書き込みを見たのですが、
それほどvimを使いこなしてない私にとってはautocmd自体も？？？です。

ということで、後でautocmdなるものも調べなきゃですね。

 

記事書く度に宿題が増えてる気がするのは気のせいだろうか。

Kernelブートイメージファイルの名前と意味 その１

 

Kernelをbuildすると、最終的にvmlinuxというファイルができますよね。

これはもちろん、kernelをコンパイルしてLinkした結果で、
普通はELF(Executable and Linking Format)形式の、
デバッグシンボル等が付いてる形で出力されます。

これを各アーキテクチャで起動するように変換したものを、
ブートイメージファイルって呼んでます。

zImageとかbzImageなんて名前のファイルですね。

基本的には、実際に動作するプログラム部分だけ抜き出したbinaryに、
それを読み込んだり展開したりするプログラムをくっ付けた形のものです。

 

折角手元にARMアーキテクチャの開発環境がありますので、
Makefileなどを参考にブートイメージファイルの名前と意味を調べてみました。

・・・けど、いくつか分からない部分も出てきちゃいました。

宿題が残ってしまったので、今回はその１なんです。

 

 

zImage

gz圧縮されたイメージファイル。

解凍プログラム→解凍・展開→Kernel起動の順に動作し、
よく組み込みシステムで使われる。

 

bzImage

bzipで圧縮されてる以外はzImageと同じ。（はず）
i386用はこれが多いらしい？

でもopenSUSEって/boot/vmlinuzを読んでるよね・・・。

 

xipImage

XIP(eXecute in Place)形式というやつで、
RAMへ展開せずに、極力そのまま使えるようにしたものらしいです。

NORフラッシュ等に余裕があるなら使えそうな形ですね。

今度試してみよう。

 

rImage

ramcopy形式とMakefileには書いてありました。

無圧縮の形で、とにかく仮想空間への展開だけしてるのでしょうか？
じつはちょっと動きが分からないので、宿題デス。
# 実際ブートローダからjumpしたら動かなかｔｔ

 

uImage

u-boot用のHeaderが付いたイメージファイルですね。
bootmコマンド等で起動する際にはこのイメージを使用します。

ARMやPowerPCなどではお世話になる形式ですね。

 

xipuImage

xipImageのu-bootバージョンです。
これも一緒に試してみなければ・・・。

 

bootpImage

initrdを含む形のブートイメージファイルのようですね。

kernel2.6からはinitrdからinitramfsになったので、
古いシステムで使用できるように対応してあるの・・・かな？（汗）

正直使ったことないので、今度試すかな。

 

 

調べたのは以上！

残りや宿題はまた今度ー。

beagleを停止してみる

 

先日、aRtsが暴走していた時に、一緒にCPUを占有していた人がいます。
その名もbeagled。

beagleはmonoプラットフォームで動くデスクトップ検索で、
最近のLinuxは大抵はデフォルトで有効になってると思います。

googleデスクトップみたいなもんです。
# そー解釈してますｗ

idle時などにファイルやディレクトリのインデックスを付ける為、
一所懸命動き出すわけなんですが、マシンスペックによっては
結構重たく感じると思います。

VMwareで使用している方のOpenSUSEは、
基本デスクトップ検索なんて使わないというか・・・
grepで十分！なので止めてしまいました。

GNOMEであればコントロールセンターから検索設定を選んで、
チェックを全て外せば止まるはずです。

KDEでも同じような項目があるでしょう。(きっと)
# うちのノートに入ってるOpenSUSEはKDEだけど重くないし気にしてなーい
# 帰ったら見てみるか・・・

 

KDE4.1以上を使っていて、NEPOMUKを有効にしている人は、
beagleではなくてNEPOMUKを無効にすればそれで良いと思いますが、
わざわざ使用してる人のに分からないなんて嘆く人はいませんねｗ

NEOPMUK(Networked Environment for Personalized, Ontology-based Management of Unified Knowledge)
に関しては、セマンティックデスクトップの導入を図るNepomukとKDEを参照してください。

何故ここに書かないかって、私もデスクトップ検索機能以外よく知ｒ

熟読しよう・・・。

ttyS1が使えない？！

 

最近、仕事現場がお祭りです。

そんな身の上話はおいといて・・・・

 

複数UARTのChannelを持っている装置でのお話です。

UART0 : とあるmodule
UART1 : console出力用232c

という構成で、UART0を無効にしていました。

そーすると、Linux上ではconsoleがttyS0になります。
この時は何も弊害なく動作していました。

 

ある時、UART0側を有効にしました。

そーすると、Linux上ではconsoleがttyS1になります。
・・・・なんと、動かない！

kernelのメッセージ出力は確かにされていて、
ドライバも正常に動作しているように見えてるのですが、
userlandの部分(INITから先)が全く表示されず。

telnetでログインすると、なんと/dev下にnodeが一切無く、
udevd（だけ）が起動していないという状態でした。

しかも、telnet上で手動でudevdを起動するとなんも問題なく、
echo >/sys/class/tty/ttyS1/uevent
でttyS1がdev下に生成されるのです。

 

なーんでそんなことが起こるのか、全然分かりませんでしたが、
原因はKGDBのSerialPortが1だったからでした。

標準出力とかぶってしまった為、上手く動作しなかったようです。

KGDBなんて使っていなかったので、気にもしていなかったのですが、
知人が偶然発見し、なんとか解決に至りました。

 

こんな動きをするんですねぇ・・・。
なかなか解決し辛い事象だと思いますので、書いてみました。

同じ現象でお悩みの方がいるかは分かりませんが、
KGDBを使用の際はお気をつけて。

Oopsメッセージの解析方法

 

ksymoopsというtoolを使用することで、Oopsメッセージをもう少しだけ分かりやすく、
表示することができます。

準備するファイルは、
・panic時に出力されるOopsメッセージ
・KernelをBuild時に生成されるSystem.map

使用方法は、
# ksymoops –m [System.map] [oops_message]

 

ksymoopsはkernel.orgのpub（ここ）から、ソースをDownloadして、
makeして使用するのが一般的らしいのですが、
組み込み用のディストロの場合、提供Toolの中に入ってることが多いです。

若干名前が違うかもしれませんが・・・・
（Montavistaの場合は、$(arch)-ksymoops）

 

詳しい内容は、
Linuxカーネルを読む -カーネル解析-
に書いてありましたので、参考にURL張っておきます。

Kernelの逆アセンブラを見る方法

 

逆アセンブラを見なきゃいけない状況に何故かなってしまったので、
一先ず表示方法のメモです。

objdump –d --start-address=0xXXXXXXXX --stop-address=0xXXXXXXXX $(KERNEL_SOURCE)/vmlinux

panicになった時に、Oopsメッセージ以外情報がないというかわいそうな状況になったら、
逆アセンブラで共に頑張りましょう！

 

orz

 

9/17追記：

-g オプションを付けてコンパイルしたvmlinuxの場合は、
objdumpに –S オプションを付けると、対応するC言語のソースも一緒に表示されます。

アセンブラだけじゃチンプンカンプンなので、ありがたいオプションですね。

udev その2.5

 

udev その２の続き・・・のようなもの。

仕事の合間を縫って調べてるのでスローペースなのですが、
まとめるには結構ややこしい機能なので、半分いいわけ（涙）になってます。

はてさて、最近気づいてしまったことがあります。

 

udev その１で起こった症状。

ethXの数字がどんどん増えていってしまう現象は、
udev-140で起こってる現象です。

対して私が落としてきたソースはudev-147でした。

とはいえ、大した差はないだろーと思って比較してみたら、
なーんとディレクトリツリーからして違うじゃないですか！

 

ということで、少し見直しますかねぇ。

Targetにudev-147を入れられないのがちょっと痛いなぁ。
# 諸処の理由により入れられないのです。

 

今までに分かったこと：

udevadm monitor で/sys/class/net/eth0とか見ても、
rename失敗は残っていても、rulesへの追加は残ってない。

mdioの数がPHYの数と合わない(+1)
rulesを見ると、eth0と同じMACアドレスが1回起動する度に
2個増えるのだけど、もしかして関係ある？？

 

とりあえず、ほとんど進んでいないので、”その2.5”デス。