2014年12月20日土曜日

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
とコマンドを入力してみてください。Hello, EFI!と文字列が出たら成功です!

UEFIの開発やProtocolについては、1日目の記事の最後に書いたドキュメントがオススメですが、
リファレンスよりも手軽にProtocolの型や名前だけ把握するには、
Phoenixのwikiが便利です。

2014年12月10日水曜日

@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さんにフォローされました.

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


なんか貰ったんですね,初夏の京都のOSCで.
おかげで部屋に彩りが増えました.
ありがとうございました

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

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

2014年12月3日水曜日

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が実行できたりします.
apps/ruby-example/sample-codes/に,このビルドされたイメージファイルで他に
実行できるサンプルのrubyスクリプトもあるので,適当に指定してみたりして試してみてください.

2014年12月1日月曜日

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は,当初のその制約から,ディスク先頭の第一セクタしかロードできませんでした.
よって,現在はその第一セクタ ― ディスク先頭512バイトの領域に
ブートローダーとパーティションテーブル(MBR)を格納し,そのブートローダーからOSを起動するという仕組みが一般的でしょう.
このブートローダーがMBMであればさらにパーティション毎の先頭のセクタ(PBR)のブートローダーを起動し,そのブートローダーが宜しくやってくれるというわけです.

この第一セクタ,つまりブートセクタをつかう方法は今や旧い方法となりました.
このブートセクタに置かれるブートローダーは容量の制約上技巧的な物にならざるを得ませんし,普通のファイルの容易に書き込みや入れ換えができるものでもないです.
多段階的な方法を取らねばマルチブートできないのもBIOSの制約から来るものです.

UEFIでは,ディスクの第一パーティションをFAT32でフォーマットし,これをシステムパーティションと呼びます.このシステムパーティションにUEFIのSDKで記述したアプリケーション,ブートローダーを配置します.
UEFIのアプリケーションバイナリはWindowsのEXE同様,PEバイナリとなります.

さて,このファイルをどう起動するよう指定するかというと,
UEFIのファームウェアそのものにブートマネージャーというマルチブートの際のOS選択画面の機能のようなものが備わってます.
このブートマネージャーに,ブートマネージャーに表示するエントリ名と,ブートローダーやUEFIアプリケーションのシステムパーティションでのパスを指定し,登録する事が可能です.
よって,OS毎に専用のローダーをUEFI SDKで記述し,それぞれのローダーをこのUEFIファームウェアのブートマネージャーに登録するだけでマルチブートが可能となるのです.

MBMやGRUBのような巨大なマルチブートのための"からくり"はもう必要ないのかもしれません.

もう一つ,ここで重要なのは,パーティションテーブルはMBRではなくなり,GPT形式となります.これは,パーティション数が最大128となり,1つのパーティションも2TiBの壁を越えて設定できます.パーティションの管理はGUIDを用いて行なわれます.



以上,軽くBIOSのおさらいも兼ねてUEFIとの違いに触れました.
UEFIのもう一つのBIOSとの違いとしてセキュリティ面で大幅に変化がありましたが,
これはまた別の機会に触れたいと思います.
また,度々文中に記載しましたがUEFIのSDK(EDK)の存在によりブートローダーの
作成は容易化しました.自作OSを作成する場合にもこれは大きなアドバンテージではないでしょうか.このEDKについても別の機会に触れたいと思います.

最後に,UEFIのドキュメントを紹介します.
まずUEFIの規格書は最大のドキュメントでしょう.
http://www.uefi.org/specifications

また,Intelが出しているペーパーブックは
UEFIアプリケーションの開発等で役立つほぼ唯一のドキュメントです

2014年11月27日木曜日

オーディオアンプを作ってみました。

初アンプ自作。

ぺるけさんのFET作動式ヘッドフォンアンプを作成。


ぺるけさんの作例をそのまま使わせてもらってます。
ただ、シャーシの穴開けをボール盤使える環境にある友人に依頼した時、依頼ミスで左右が反転したのでラグの位置等もそのようになってます。おかげで音量ツマミが左側になりましたが些細な事でしょう。
結局他にいくつか穴を開ける必要出てきて結局電動ドリル買いました。
ぺるけさんはオーディオクラスでないパーツを使っておられましたが、私はなんとなーくコンデンサを東信工業のUTSJにしてみました。初アンプ自作ですしオーディオに対して無知なのでこのコンデンサにしてどうとかあんまりわからんのですが。

一発で音が出て感動してますし、個人的には結構良いように思えます。
あとはボリューム抵抗のシャフトを切る道具もってなくてツマミをつけず裸のままにしてるのをなんとかしたいです

電気式華憐音楽集団2nd Live "Gig Detonator"

表題通りのライヴに参加してきました。




グッズ類

BLACK BOX、white box、Red Box

ライヴ、あまり行ったことなかったのですがなかなか楽しめました。
良いものですね。

ガジェットってどんどん増えますよね

最近買ったガジェットとかマシンとか。

まずPC-98

ええ、最近、最近買ったマシンです。
キーボードはPTOSキーボードなのでALPS電機の黄軸メカニカル!

PPC Mac (G5)

画像中央、スカイセンサー5800の台になっちゃてるやつです。
ええ、これも最近入手しました。はい。


3D対応シアターで使われてる3Dメガネ。ジャンク屋で入手
秋葉原の三月兎ですぐ売り切れたと話題の、PC-98やx68k向けCF2SxSI変換機、日本橋仕様。
生産中止した古い型のUSB TrackPointキーボード(US配列)


それと最近お気にいりのガラクタ屋でコントローラ付で1000円だったスーパーファミコン


という感じでなんか自宅のほうがジャンク屋になりかけている……むしろジャンク屋が自宅説