2013/07/14(日)LInux開発入門(外部URL参照)

初学者のためのLinux起動シーケンス概要

題名はもっともらしいですが、とりあえずURL貼っておくだけで。。。
Linux kernelが起動するまで、と、起動してからユーザランドに渡るまで、
ユーザランドの起動処理、くらいに分類できるかな、と思います。
最後のユーザランド起動処理の手前までは、Androidも一緒でしょう。(未確認)

京都マイクロコンピュータ様のblogリンクが多いのは、それを見てまとめておこうと感じたからです(^^;
他にもネタが出てきたら追加しいこうと思います。オレオレメモってやつですね(ぉ

起動シーケンス(uboot/barebox)

ちょうどこの切り替わりに遭遇していました。
昔からのマイコンは、外部メモリからbootしていましたよね。
ワンタイムROM、UVEPROM、EEPROM・・・と来ていますね。

昨今は原低のため、外部記憶にSD card/NAND Flashのみという構成を取るようになってきているので、
SoC内のMaskROMに埋め込まれているbootloaderから起動してくれます。
このへんの設定は、SoC次第ですし、boot modeでNORからの起動するようなものもいます。
かならずMaskROMからしか起動しないのもきた気がする。
U-bootのデバッグ

ユーザランドの処理(Linux版)

initrd有効の場合は、initramの/linuxrcから起動したはず。
process id=1として、最初に起動されるのは、kernel parameterにinit=で指定したもの、
それがなければ、/sbin/initの順にチェックして、rootfsがmount出来なかったり、init実行ファイルが
なければ、OOPS吐いて止まります。ポーティング作業とか疲れてくるとよく見かけます(謎

ユーザランドの処理(Android版)

Androidのinit処理の流れ。Linuxの普通?のinitとはフローが違うので参考に。
いきなり渡されて流用できるとは思っていなかったからなぁ。こちらと別のblogを参考にさせていただいた記憶が…。
Androidのinit

その他紹介したい記事

「組み込みエンジニアのためのLinux入門 仮想メモリ編」

kernel documentも見ておきましょう。最後はソースコードが正義です。。

LInux開発入門

2013/06/09linux::入門編import
冒頭から逃げを書いておきますが・・・
手探り状態、読者対象が具体的に見えない状況下で記載を始めます。
昨今、マトモな出版物も増えてきているので、需要がないかもしれませんが、少しでも道標になれば幸いです。

Linux OSを用いた開発

以前までは、組み込みといえばuITRON系のRTOSが幅をきかせていましたが、
プロセッサ能力向上・メモリ単価の減少、要求要件の拡大などの要因により、
見直されてきているように思います。
最も影響があるのはNetwork Protocol Stackや、複数プラットフォームで共通的に使えるソフトでしょう。

もちろん、ITRON系のリソースも現役です。少ないROM/RAM、軽量なマイコンでも動くので、住み分けができるでしょう。
より低機能であればOSレスもありますし、畑は広大です。

さておき、ひとことでLinux OS開発といっても、OSはもよとり、コンパイラ・アセンブラ・リンカその他ツール類すべてがOpen Source Softwareを使用します。自らソースコードを元に開発環境や実行環境を用意することができます。MicrosoftのVisual Cのように、コンパイラに対価を支払うのとは対照的ですが、何か問題が起きたとき、起きそうなとき、それを知るための方法を、どのように確保するのか、が課題となります。これを商売にしている会社もありますね。

構成

以下に、クロス開発環境を前提としたソフトの構成例を記します。
開発ツールを買えば、裏ではこれらのソフトを準備してくれたりします。
MSDOSやWindows、商用UNIXでやってきた方には、高い金でコンパイラや統合開発環境を買った記憶があることでしょう。

Linux_SW_001.png


黄色い部分が、ターゲットに載せるべきものです。
右下にある、libraryを除く開発ツールは、必須ではありません。必要に応じてセルフ開発環境やデバッグツールを取り込むのがよいでしょう。

ubuntoやdebianの各arch向けディストリを使う場合は、セルフ環境も必要になりそうな気はします。いや、基本はバイナリインストールになっているしょうか。

ベンダ提供

あえてドライバ・アプリのところへ、ベンダ提供〜を記載しました。
実務で使っていると、必ずしもすべてをopenにしているのでは無いですから、ね。各社の製造ソフトに関しても、GPL伝播していないものは公開義務を負いませんから公開されることは無いです。GPLv2までの場合は、その再配布責任を追うことから、なんらかの手段で製品で使用したtarballなどの提供を受けることができます。
液晶テレビ・レコーダ・STB・そのほかそれっぽい家電の説明書を眺めてみれば、Open Source使用の旨と、その製品で使用したものの入手方法が記載されているでしょう。
尤も、オンラインでさくっと手に入るところもあれば、電話問い合わせ・郵送による配送もあります。
エンドユーザから公開の依頼が頻繁にはないのでしょう、かねぇ?

ライセンスの話が出てきましたが、これだけで深いネタになります。
僕も把握しきれておらず、法的な問題になる場合は判例を調べた上で判断したほうが良いでしょう。
個人で楽しむ分にも、価値が認められ、公開義務を追うような作りをした場合は、開示を迫る人がでてくるかもしれません。

toolchain

いわゆるコンパイル環境、です。ソースコードをターゲットで動くバイナリに変換します。
最近は LLVMというのが注目を集めているようです?

汎用性を考慮されたソフトの配布では、Makefileを利用していることでしょう。
また、autoconfや独自のconfigrationツールを用意して、buildするホスト環境差分を自動的に検出・適切に変更するような手段を提供しています。

しばらくしてわかったこと

何事も過去の経緯を知ることが理解への早道に繋がることがあります。同じようなものがなぜ複数存在するのか、ディストリビューションのそれぞれの目的、本当に全てが無料なのか。製品に搭載するために必要なことは?などなど。いまだにわからない事だらけですが、所詮個人がわかる範囲なんてのはしれてるわけで。

必要なとき、必要なところで、短時間でほしい情報に辿りつけるハナ・直感力を持てるようにしておくのが、対策となろうかと思います。もしくは大まかに畑を分割して、担当範囲を分けておくか、です。ですよね・・・?
後半は妄想でしかないので...