投稿

12月, 2014の投稿を表示しています

ブートローダーは4行で実装される

この記事はUEFI Advent Calender自作OS Advent Calenderのためにかかれました。
22日(+3日)の記事です。

遅れてもうしわけないです。

ブートローダー

まず、自作OSにはブートローダーによってカーネルをロードしなければはじまりません。
特段複雑なローダーがなくとも、たとえばBIOSから直接起動するのなら
そのための形式で用意せねばなりません。
しかし、これが自作の入口としてかなりの関門になってしまっているのではないでしょうか。

なので自作OSからはちょっと離れますが、ブートローダーについて書きます。

UEFI

ということで、UEFI Appsとしてブートローダーを実装する話です。
まず、UEFIとは何かについてはUEFI Advent Calender 1日目の記事を、
そしてこの作業の前知識としてUEFI Advent Calender 12日目の記事を参照していただけると良いです。

一応ざっとUEFIについて触れておくと、
BIOSの代替規格のファームウェアで、多機能かつ高機能。また、可搬性も考えられています。

UEFIのファームウェア上で直接動作できるUEFI Appを記述するには、
tianocoreがBSDLで公開しているEDKというツールキットか、
Gnu toolchainと合わせて使えるgnu-efiというBSDLのライブラリを用います。
EDKでも一応gcc等が使えます。

EDKは、パッケージとして豊富にライブラリが揃っており、libcやbsd socket、pythonがつかえます。
gnu-efiは、Linux/OS Xの上で開発するにはEDKより手軽にはじめる事ができます。

UEFI AppはWindows同様PE形式のバイナリなので、
実はEDKやgnu-efiがなくとも*.dllなバイナリ(つまりrelocatableでsharedなPEバイナリ)を作成してから、objcopyコマンドとかで必要な部分だけ取り出して拡張子がefiのファイルにするとかでも一応動作できるバイナリを作る事は可能です(が、面倒です)

UEFIのAPIであるProtocolは初期状態でもFile I/OやGraphicsの処理まで揃っていますが、
自分でUEFI Driverを実装してこのドライバをロードすればProtocolを増…

UEFIアプリケーションのはじめかた

UEFI Advent Calender 12日目だったoruminです
盛大に遅刻かましてもはや遅刻とさえ言えない感じです。

UEFIのアプリケーション、まずどう作るかわからない方も多いかと思います。

まず、UEFIが実行できる実行形式について、これはWindowsと同じPEバイナリです。

また、EDKのようなツールキットを用いる必要がありますが、
今回はgnu-efiで説明します。

gnu-efiとは、BSDLなEFIアプリケーション開発用ライブラリです。
LinuxやBSDでの開発に親和性が高いと思われます。

これは最近だとaptやpacmanでそのままバイナリインストールが可能です。

そして、次にこのようなファイルを用意します




前者がUEFIでのHello, World!です。efi_mainがエントリポイント、
ImageHandleもSystemTableもUEFIのAPI(Protocol)を呼び出し、使うのに必要なパラメータとなります。
今回は、gnu-efiの初期化をしてから文字列を出力するだけなので特に使用していません。
デバッグ文字列出力は
SystemTable->ConOut->OutputString(SystemTable->ConOut, L"Hello, EFI!\n"); でも良いのですが。

後者のMakefileについては、書いてある通りです。
ライブラリとインクルードファイルの指定、
それにリンカスクリプトやスタートアップルーチンはgnu-efiのものを使うように指定。
shared objectな実行ファイルを作ってから、
objcopyコマンドで必要な部分を抜き出す(ELFヘッダは要らないので)
という流れになります。
CFLAGSについては、色々ごちゃっと指定してますが、
まず必須なのは-fPICと-fshort-wchar、そしてx86_64であれば-DEFI_FUNCTION_WRAPPERだけで、あとのは特段必ず指定しないといけないものではないです。

さて、これでmakeをしますと、hello.efiが作成されるので、

あとはEFIシステムパーティション直下にでも置いてあげて、起動時にUEFI Shellを立ち上げてから
hello.efi
とコマンドを入力してみてください。…

@toshi_aにTLを大破させられて1年がたちました……

mikutter Advent Calender 9日目の記事です.

みなさん,去年のAdventCalenderは覚えておいででしょうか.きっと,
全部覚えてる人は少ないでしょう.
@toshi_a被害者の会http://orumin.blogspot.jp/2013/12/toshia.html

mikutter Advent Calender 2013 8日目の記事の様子です.
TLを壊されました.そしてささやかな復讐をしました.

そう,あれから1年がたったのです.

何か記念(怒)に書こうと思ったのですがネタが特に思い付きませんでした.
適当に今年の振り返りでも書きます.

あれから色々ありました.

まずなぜか@toshi_aさんにフォローされました.

そして,
とりあえず私がひっこしたおかげでイベントとかに参加しやすくなったので,


つくもたんでそういえばだけど本棚の上はこーなってるんですよ。奥はとしぁさんから頂いて手前はぺんぎんさんから頂きました pic.twitter.com/vLz5QVYfbg
— 側転幼女おるみんちゃん (@kotatsu_mi) 2014, 12月 9 なんか貰ったんですね,初夏の京都のOSCで.
おかげで部屋に彩りが増えました.
ありがとうございました

とくにそれからはmikutter関連でなにかあったりはしてないのですが,
mikutterそのものは3系になりさらに進化して良いです.
ArchLinuxユーザーの私は新しいmikutterをすぐに使えてとても有り難いですね.
ということでArchをつかおう!

あれ,なんかArchの宣伝になってしまった,まあいいや,oruminでした.

Ruby on OSv

これはOSv Advent Calender 2+1日目の記事です.
グアムのハワイのワイキキビーチで書き上げたからまだ12/2という"てい"でよろしくおねがいします.



OSvのCRuby移植担当してたoruminです.
OSv1日目の記事@syuu1228さんが説明されていた通り,現在OSvで
複数の言語ランタイム/アプライアンスが動作します.

CRubyも移植は一応の完成を見ることができ,動作させる事が可能です.
今回は動作方法について書きます.

じゅんび

まずはリポジトリのcloneから.
$ git clone http://github.com/cloudius-systems/osv.git osv その後,忘れずsubmoduleをinit & updateしましょう
$ cd osv && git submodule --init update ビルドのためには,いくつかパッケージが必要です.
https://github.com/cloudius-systems/osv/blob/master/README.md
に必要なパッケージはFedora,Debian,Archについて記述されています.

しかし,Fedora20を用意できるのであれば,osvのディレクトリで,
$ sudo ./script/setup.py と実行すれば必要なパッケージを全て準備してくれます.

ビルド 

ビルドは単純です.
$ make -j`nprocs` image=ruby-example このようにしたら,あとはビルドが終わるまで待機です.
なお,rubyのビルド中にエラーで失敗する時は,-jフラグを外してもう一度やってみてください.
まだrubyとosv kernelの並列ビルドがうまくいかない時があるようです(すみません)

実行

次のスクリプトでOSvは実行できます
$ ./script/run.py どうでしょうか? うまくいけば
OSv v0.16-814d434
eth0: 192.168.1.89
Hello, world! のように表示されます.
また,
$ ./script/run.py -e "/ruby.so /irb" のように起動引数を手動で設定すれば,irbが実行できたりします…

What's UEFI

UEFI Advent Calender一日目,oruminです.

初っ端なのでまずUEFIとは何かについて書こうと思います.

・UEFIとは?

UEFIとは,ファームウェアの一種です.
一般的なPCはBIOSからOSを起動している事はご存知だと思われますが,
実はBIOSは最早過去の遺物となりました.

BIOSの代替として2000年頃からIntelが開発していたEFIは,
多くの企業とコンソーシアムを立ち上げ,現在UEFIとして規格が策定されています.
2010年頃からはIntelのマザーボードを皮切りとして一般向けにも採用され,
現在市場にあるPCのほぼ全てがUEFIでしょう.
BIOSの設定画面だと思っているそれは最早UEFIです


・BIOSとの違いは?

大きな違いはデファクトスタンダードとしてなんとなしに採用されてきたBIOSと違い,
多くの企業のコンセサスの元策定された規格が存在し,閲覧が可能である事です.

この規格は,ブートローダや診断ツールといったものの開発が容易であるよう,
プログラミングのためのインターフェイス,APIが規定され公開されています.
これを扱うためのSDKが公開されているため,C言語やPythonといったもので
診断ツール等を記述可能になっています.

なんと,UEFIのAPIを用いて記述したアプリケーションプロラムは,OSが起動する前の段階(pre-OS Environment)でUEFI内蔵のShellから起動する事ができます.

また,IBM-PCの時に作られたBIOSは16bit Intel CPU前提のアークテクチャであるため,
多くの制限がありましたが,UEFIの場合はこの制限が無くなり,CPUのアーキテクチャに非依存です.Intel CPUのReal modeでないとBIOSから起動できない,などという事がないためブートローダーも16bitでなく32bitプロセッサなら32bit,64bitプロセッサなら64bitの命令がつかえるため,メモリも潤沢に使えます.

現在はx86,x86_64,AArch64のUEFI実装が存在します.

そして,一番のBIOSとの違いはブートシーケンスにあるのではないでしょうか.

・UEFIのブートシーケンス

BIOSは,当初のその制約から,ディスク先頭の第一セクタしかロードできませんでした.
よって…