_ 一人もくもく.

UEFI

へにゃぺんて氏の同人誌 UEFI を斜めに読んでちょっと知識を補充してから
bootloader まわりの FileSystem parser とか書いていこうか、とおもったら
なんか色々細かいところが違うような.
example の関数ポインタを時前で宣言しているのとか色々変では、と思いながら
efi-gnu の書き方なのか、と思いつつ edk2 を見直すとどうも, UefiMain に
振れないっぽい. Entry を降ってもなぜか build でこけてしまう.
変わりに ShellCEntryLib とかいうところに振られており, main か ShellAppMain
にいっているっぽい. libc 関連のサポートと, edk2-libc で分離されちえる側に
AppPkg がいるのでそういうことなのかも、と思わんでもないが..

読書

"蜘蛛ですが、なにか#12"
kindle で配信されていたのだがようやく読む. web 版が最近更新されていないが基本再構成なので
話はまあ、既視感が強い. 記憶より口語調が強いように感じるがこんなもんか.

UEFI

結局 現行の EDK2 の Hello を参考にしていくか、ということにしたがその前に
実機確認、ということで昨日入手してきた thinkpad に ubntu の bootx64.efi を差し替え
る形でやってみるがどうも出ない. こまった.

お片付け

しようと思いつつ手をつけてさらに汚すという..
本って整理しようとすると読んでしまうのよね.

UEFI

目先を変えて uefi を google 先生に聞いていると, 色々衝撃的なものがひっかかる.
極めつけは https://github.com/hikalium/liumos か.
Makefile を斜めに読むと llvm には subsystem が定義してあって、云々と読める.
ついでに引数でとっているのを見るに, UEFI はおそらく仕様レベルで stack に API
というか ABI というかのアクセサを積んで call してくる、という仕様ではないか
と勝手に仮説を立ててみる.
まあ、ここまでの知見でバイナリそのものは primitive な PE で EFI filesystem
に固有名称で指定されたのを直打ちで叩きにくる、なのでたぶんこれで良いとおもうのだが.

UEFI

UEFI Specification 2.8 sec 2.3 あたりを読むとスタックを規定しての呼出しという
ある種の calling convention が仕様では、という仮説は正しそう.
ということは, SYSTEM_TABLE とかの仕様を, 先頭ポインタを stack +N にして offset
を mapping すれば IF にアクセスできる、というような挙措になると考えられる.
実際いくつかの llvm ベースのコードを見ると, efi.h のでどこがよくわからんが
そのような感じにみえるので正解っぽい.
とりあえず, 依存関係少なそうな netbsd から拝借して適当に minimal example を作成.

UEFI

ちょっと実機の動作実績みつけられなかったが subsystem を参照にした hello world
を作成。
netbsd からの header だとどうも色々最小限しかないのとか依存関係解決するのが面倒
なので腹くくって UEFI specification から作成する.
とりあえずうそっこ definition はって, 必要そうなのをコピー.
build が通る程度に改変する. 細かい厳密性とかは考えないで hello world.
どうやら無事に出るっぽい. 実機がちょっと悩んだが, while で無限待ちさせると表示で
止まったのでたぶん大丈夫.
ようするにまとめとしては, PE/COFF で, stack がある種の calling convention に
のっとている binary を作成しろ、ということに尽きるのだと思う.

_ 固定化が鍵だと思うのだが何がパラメタなのやら.

生活固定化

年始なのでちょっと廻りはじめる. 午前というか起床してからの
ちょっとした障害を取り除くのが肝で, その為には睡眠時間 + α
なんじゃないか, というのが今のところの分析.
幸いというか進捗を削ってでも睡眠を優先させているので睡眠の
ほうは意外と上手くいっている感じ.