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を参照してください。

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

熟読しよう・・・。

aRtsの暴走

 

VMware上でOpenSUSE11.1を動かしていると、
徐々に動作が重くなっていって、しまいにゃ止まってしまうことがあります。

なーんでかなぁ？と思って調べてみると、
artsdのCPU使用率が99%をキープしていました。

とりあえずkillするとカクカク状態から脱出できたので、
原因はartsdなんですが、なんで暴走して・・・・
あれ、なんで起動してるんでしょうね？

artsdはaRts (analog Real time synthesizer) のデーモンです。

こいつはKDEの標準サウンドサーバなのですが・・・
わたしゃVMware上のやつはGNOMEで動かしてます。
# だってGNOMEのが軽いんだもの
# Xfce? ナニソレ?

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

一先ず、コントロールセンターのサウンドで、
・自動検出→ESD
・警告音と効果音→チェック無し
に、変更して様子見です。

 

ググってみると、同じ症状で困ってる人がそれなりにいそうなので、
もー少しつっこんで 調べれば分かりそうなものだけれど、
ゆっくり時間が取れたらみてみようかな。

VMware上のOpenSUSEなんて仕事でしか使わないしねぇ。
・・・なんて言ってると忘れそう（汗）

 

 

久々の更新。

嗚呼、udev調べないと中途半端だぁ。
忘れかけてたヨ。

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”デス。