+0x0000 +--------------------------
|
+0x0040 |- - - - - - - - - - - - -
| BSD disklabel (404 bytes)
+0x01d4 |- - - - - - - - - - - - -
|
:
次にファイルシステム。 こっちについても細かいことは知らんけど NetBSD に限らず BSD UNIX で一般的に使われる FFSv1 はざっくり言うと以下図のような構造をしている。 超絶適当だけど、 ミソは、ファイルシステムが一切関知しない 8KB (固定) の領域が "ファイルシステム内の先頭に"あるということ。 なので 「このファイルシステムの開始位置」は +0x0000 だが、 このファイルシステムを読む人はおそらく大抵黙って先頭の 8KB を スキップした +0x2000 から処理を開始する。 FFSv2 の場合はこのブート用領域は 64KB 固定。
+0x0000 +-----------------------
| FFSv1 Boot Area
| (8KB)
+0x2000 +-----------------------
| FFS Super Block
|
| FFS Data Block とか (たぶん…)
:
+0x0000 +-----------------------
| Boot Area
| (8KB)
+0x2000 +-----------------------
| USTARFS
:
X680x0 で (SCSI) HD 起動する場合、IPLROM は
ディスクのセクタ#0 の先頭に "X68SCSI1" という8バイトのマジックがあることを確認する。
続いてディスクのセクタ#1 から1セクタ分をメモリの 0x2000 番地〜に読み込み、
その先頭バイトが $60 (BRA.[BW]命令の1バイト目) であることを確認してから、
0x2000 番地に処理を移す。出 IPLROM 記である。
ただし、この「セクタ」は Human68k の 1024 byte/sector のこと。
NetBSD カーネルの中ではメディアのセクタサイズに関わらず
512 byte/sector が用いられるようで、大変紛らわしいことになるので、
この記事ではこれ以降 1024 byte/sector のほうを「ブロック」、
512 byte/sector のほうを「セクタ」と勝手に呼び分けることにする。
この場合 1ブロック = 2セクタが常に成り立つ。
この記法に従ってこの段落前半の要点を書き直すと、
ディスクのブロック#0 の先頭のマジックを確認する、
続いてブロック#1 から1ブロック分をメモリの
0x2000 番地〜に読み込んで 0x2000 番地に処理を移す、となる。
もう一つ、 IPLROM が HD に処理を移す際には Human68k パーティションテーブルには関知していないのがミソ。
Human68k の FORMAT.X で HD にパーティションを切っていれば(かな?)、 ディスクのブロック#1 には Human68k のブートセレクタが書き込まれていて、 これが Human68k パーティションを見て起動先を選択、決定するはず。 Human68k パーティションテーブルはブロック#2 に書いてある。 つまりこういうこと↓
Block Sector Offset
#0 #0 0x0000 +-------------------------------------
| MagicString ("X68SCSI1", 8bytes)
#1 0x0200 |
|
#1 #2 0x0400 +-------------------------------------
| BootLoader (1024 bytes)
#3 0x0600 |
|
#2 #4 0x0800 +-------------------------------------
| Human68k Partition Table (256 bytes)
|- - - - - - - - - - - - - - - - - - -
#5 0x0a00 |
|
#3 #6 0x0c00 +-------------------------------------
:
Block Sector Offset
#0 #0 0x0000 +-------------------------------------------
| MagicString ("X68SCSI1", 8 bytes) ^
0x0040 | BSD disklabel (404 bytes) |
#1 0x0200 | |
| |
#1 #2 0x0400 +---------------------------------------- |
| ^ |
#3 0x0600 | | BootLoader (<7KB) |
| | |
#2 #4 0x0800 | | Human68k Partition Table (256 bytes) |
| | (But not available) |
#5 0x0a00 | | |
| | |
: : :
#15 0x1e00 | | FFSv1 Boot Area (8KB) |
| v v
#8 #16 0x2000 +-------------------------------------------
| FFS Super Block
またこの方式では、 プライマリブートローダはルートファイルシステムがセクタ#0 から始まると勝手に仮定しているだけで(手順7)、 BSD disklabel を読んではいないため、 セクタ#0 から始まらないルートパーティションからは起動できない。 まあディスクまるごと使うからには大抵セクタ#0 からルートパーティションを始めるだろうから問題になることは少なそうだけど。 今時の感覚から言えば、動くように組み合わせたから偶然動いてる状態とも言えるが、 当時のブートローダなんて多かれ少なかれそんなもんだと言われればそうかも知れない。
Block Sector Offset
#0 #0 0x0000 +-------------------------------------
| MagicString ("X68SCSI1", 8 bytes)
0x0040 | BSD disklabel (404 bytes, Not Used)
#1 0x0200 |
|
#1 #2 0x0400 +-------------------------------------
| 0-th BootLoader (1024 bytes)
#3 0x0600 | (BOOT MENU or mboot)
|
#2 #4 0x0800 +-------------------------------------
| Human68k Partition Table (256 bytes)
| [0] start = N, size = ...
| [1] ...
|- - - - - - - - - - - - - - - - - - -
#5 0x0a00 |
|
+-------------------------------------
:
#N #2*N 0x0400*N +-------------------------------------
| Primary BootLoader (<8KB)
| (boot_ufs or xxboot_ffsv1)
: FFSv1 Boot Area (8KB)
#(N+8) +-------------------------------------
| FFS Super Block
前提として、
フロッピーの場合主用途がインストールフロッピーなので、 ファイルシステムを USTARFS として話を進める。
Block Sector Offset
#0 #0 0x0000 +-------------------------------------------
| ^
0x0040 | | BSD disklabel (404 bytes, But not used)
#1 0x0200 | |
| |BootLoader (<8KB)
: :
#15 0x1e00 | |
| v
#8 #16 0x2000 +-------------------------------------------
| USTARFS
フロッピーの場合でもここまでのところ BSD disklabel は登場しないが、 USTARFS の場合そもそもこれより後も disklabel 自体が不要。 セカンダリブートローダは fd0a の 'a' は無視する仕様だし (そもそもカーネルでもここの 'a' はパーティションを表してはいない)、 インストールカーネルが、 n 枚組インストーラ (NetBSD/x68k の場合は通常2枚組) の もう排出された(かも知れない) 1枚目のフロッピーにアクセス行くのもおかしいし。
余談だけど、 フロッピー上に USTARFS ではなく FFS を作るのなら、 上記 HD 起動の Human68k と共存しないケースと同様に BSD disklabel で a: が0セクタから始まるように書いて、 ディスク先頭から xxboot_ffsv? を置けばいいはず (このケースだけ xxboot_ffsv? 内に BSD disklabel 用の空隙が必要)。 果たしてどれだけの使い道があるかは別として…。
Human68k パーティションテーブルは全部で 15個設定できるが、 このうち BSD disklabel として認識できるのは先頭の7つのみ。 そして BSD disklabel の c: は特別なパーティションなのでマッピングから除く。 つまり、以下のような対応になる。このマッピング順は固定。
Human68k
パーティション
テーブル対応する
BSD disklabel[0] a: [1] b: [2] d: [3] e: [4] f: [5] g: [6] h: [7]〜[14] 割り当て不可
NetBSD では伝統的に通常 a: をルートパーティション、b: をスワップとするので (しなくても動くのかも知れないけどお勧めはしない)、 Human68k と共存する場合は、実質、先頭の 2つを NetBSD 用に割り当てて、 Human68k パーティションはそれ以降に置くことになると思う。