/var/log/messages

debugging with sixth sense

続 initsys.c 確認 (Pi-baremetal 確認)

コメント確認入れてみます。

  • 0xc0000000-0xc00fffff は coarse page table によって物理メモリにマップされる
  • メモリにロードされた kernel data を 0xc0000000 にマップ?

ええと、kerneldatatable の値は initsys.c にて 0x3c00 として定義されてます。

static unsigned int *kerneldatatable = (unsigned int * const)0x3c00; /* 1K */

あ、start.s に以下なコメントがありました。

/* kernel.img is loaded at 0x8000
 * Below that, 0x4000-0x7fff is the 1MB memory page table, then
 * 0x3c00-0x3fff is the kernel data coarse page table (see initsys.c)
 *
 * Stacks go below it, as follows:
 *
 * 0x2c00 - 0x3c00  User/system stack

あ、確かに initsys.c では以下な変数の定義もあります。

static unsigned int *initpagetable = (unsigned int * const)0x4000; /* 16K */

そりゃええんですが、0x3c00 から 0x3fff までの 1KB を 256 で分けて、で unsigned int な配列になるのか。で、基本的には _physbssend までの領域まで分が map される模様。

その後、bss な領域を 0 で初期化して mcr という命令で

  • 変換テーブルの登録
  • Domain 0 な Access Control List に Client な権限を設定
  • MMU を on に

してたりする模様ですがこのあたりマニュアルの確認必須ですorz

あとは r0 から r2 までを pop して main 手続きに制御を移しています。

纏めてみます

  • initsys 手続きは基本的にページテーブル初期化して main 手続き呼び出し
  • 0x80000000-0xz0ffffff は 0x00000000-0x29ffffff を指すようにする
  • 0x00000000-0x000fffff は同じアドレスを指すようにする
  • 0xf0000000 が 0x00000000 を指すようにする
  • 0xc0000000 は coarse page table として設定
  • coarse page table の初期化
  • bss 初期化
  • page table 登録
  • access permission の設定
  • MMU を on に
  • main 手続き呼び出し

ということで良いのかどうか。おそらく main に突入後も色々ヤッてるのではないかな。

ちょっと main 手続き見てみる

先頭で initpagetable の先頭要素を 0 で初期化してます。成程。

main 手続きが開始された時には initpagetable[0] が指してた領域は initpagetable[3840] が指してる状態になってます。で、その直後に TLB を Flush してます。その先の mem_init 手続きがまた気になりますね。

mem_init 含めてマニュアル確認して諸々纏めておく必要あるかも。

Comments