MMUオン

とりあえずですが、MMUを有効にしてみました(リビジョン3)。
変換を行ったのは以下のページ(kernel領域)で、それ以外のページはストレートにマッピングしました。

マッピングサイズ
セクション(1MB)
仮想アドレス
物理アドレス
0x30000000(SDRAM)
変換テーブルの場所
0x31000000(SDRAM)


kernelイメージは、アドレス0からの仮想アドレスを前提にビルドを行っているため、以前のリビジョン(2)の状態では、dataセクションのアクセスは正常ではありませんでした。
(textセクションは相対アドレスのため動作はしていました)


今回の更新によって、startKernel関数に到達後の移植が進められるようになりました。
現在の具体的な状況としては、startKernel関数のはじめで、メモリ領域の初期後、ログを出力してビジーループで停止させています。

実行方法

実行までの手順を以下に示します(予め、クロスツールqemu-bishopがインストールされている事が前提です)。

  1. share/configs/Makefile.inc の MONADIR と PREFIX を環境に合わせて修正
  2. トップディレクトリでmake
  3. bin ディレクトリの runqemuスクリプトのBishopエミュレータのパスを環境に合わせて修正
  4. runqemu実行

すると、

('V`)< Mona version.0.3.0Alpha9 on ARM920T(S3C2440A/Bishop) $Date:: 2008-04-29 11:35:00 +0900#$ / 0x00000300

のようなログが出力されると思います。
(qemuモニタへ遷移するには、^C-a cです。一度改行すればモニタのプロンプトが見えます)

いいわけ

現在、移植に伴う数ある懸念の中で特に悩んでいるのが、アーキテクチャに依存するコードの切り分けです。


特定のアーキテクチャやプラットフォームに縛られず、複数のそれらをサポートするOSはその依存する部分を個別のディレクトリに管理していると思います。
そして、コンフィグレーションによってアーキテクチャの選択やコンポーネントの取捨ができるようになっており、その設定の結果がMakeやコードに反映されます。


これは、それぞれのOSで様々なルールがあり、一長一短があると思います。
このようなルールが無い場合、実際に移植を始める前に良く練るべきですが、これはかなりセンスが要ると思います。


そのセンスがなく、それを考えるだけでも大変なので、現在はad hocに進めています。
また遊び半分のため、必要になったらその時にまた考えるようにしたいと思います。