Skip to content

Instantly share code, notes, and snippets.

@nullnilaki

nullnilaki/gist:9872138

Created March 30, 2014 12:26
Show Gist options
  • Save nullnilaki/9872138 to your computer and use it in GitHub Desktop.
Save nullnilaki/9872138 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.txt
§ ユーザ組み込みドライバ作成の手引
☆ 概要
ここでは，EWS-UX/V(Rel4.2MP) および UP-UX/V(Rel4.2MP)でサ
ポートされる，VME バス上に接続されるデバイスに対するドライバ
の作成方法ならびにカーネルへの組み込み方法について説明します。
ドライバを新規に作成される場合，「 デバイスドライバリファレ
ンス 」 に記述された規定に沿って作成しなければいけませんが，
ここでは，実際に EWS4800 および UP4800 のVMEバス実装モデルで
のハードウェアとのインタフェースや作成手順を説明します。
なお、EWS4800/UP4800システムでは 24ビットアドレスモード、
16ビットアドレスモードでの DMA転送はサポートしていませんので、
そのような VMEボードの実装はできません。
☆ インタフェース(UP4800 モデル660/680/690)
◇ アドレスマップ
UP4800 モデル660/680/690 のVME アドレスとCPU アド
レスは以下に示すとおり 1対1に対応しています。
0x0000 0000+------------+ +------------+0x0000 0000
| | | |
| | | |
| | | |
| | | |
| | | |
+------------+ -------- +------------+
0xF200 0000| VME 空間 | | VME 空間 |0xF200 0000
0xF3FF FFFF|( VME - 1 ) | |( VME - 1 ) |0xF3FF FFFF
+------------+ -------- +------------+
0xF400 0000| VME 空間 | | VME 空間 |0xF400 0000
0xF5FF FFFF|( VME - 2 ) | |( VME - 2 ) |0xF5FF FFFF
+------------+ -------- +------------+
0xF600 0000| VME 空間 | | VME 空間 |0xF600 0000
0xF7FF FFFF|( VME - 3 ) | |( VME - 3 ) |0xF7FF FFFF
+------------+ -------- +------------+
| | | |
0xFFFF FFFF+------------+ +------------+0xFFFF FFFF
CPU 物理アドレス VME アドレス
上図に示した通り，VMEアドレスの0xF2000 0000～0xF7FF FFFF
までの空間は， CPU 物理アドレス上 の VME1,2,3 空間に 1対
1にマッピングされています。また，VME1,2,3 の各空間は，さ
らに以下に示すように分類されます。
VME - 1 VME - 2 VME - 3
0xF200 0000 0xF400 0000 0xF600 0000+---------------------+
| |
| |
| |
| |
| VME |
| |
| エージェント空間 |
| ( 32 ビットモード ) |
0xF380 0000 0xF580 0000 0xF780 0000+---------------------+
| VME |
| エージェント空間 |
| ( 24 ビットモード ) |
0xF3FF 0000 0xF5FF 0000 0xF7FF 0000+---------------------+
| ショート I/O 空間 |
0xF3FF FFFF 0xF5FF FFFF 0xF7FF FFFF+---------------------+
VME - 1,2,3 空間
次に物理アドレスと仮想アドレスの対応を以下に示します。
+----------+ +----------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | . 0xCA00 0000
| | . | |
| | . | VME 空間 |
| | . |(VME - 1) |
| | . 0xCFFF FFFF.
| | . .| |
| | . . | |
| |. . | |
0xF200 0000. . | |
| | . | |
| | . | |
| | . | |
| | . | |
| |. | |
0xF7FF FFFF. | |
| | | |
+----------+ +----------+
物理アドレス 仮想アドレス
◇ VME 空間のマッピングについて
UP4800 モデル 660/680/690では、VME空間は常に仮想アドレ
スの 0xCA000000 ～ 0xCFFFFFFF にマップされており、直接
アクセスすることが可能です。
◇ キャッシュの制御について
UP4800モデル660/680/690では、カーネルがメモリをアクセス
する際に必ずキャッシュが使用されます。これはVMEバスがメモ
リをアクセスする場合にもあてはまります。
UP従来機種(UP4800モデル520/620/625/630/635)ではVMEバスが
メモリをアクセスする際にキャッシュが使用されなかったため、
CPU(カーネル)とVMEバス間でメモリを介してデータの受け渡しを
行うようなケースでは、VMEバスがリード／ライトしたメモリの
データと、CPUがリード／ライトしたキャッシュのデータの内容
の整合性が取れなくなることがありました。そこで、UP従来機種
では CPUがこのような空間のリードを実行する前、および VMEバ
スがリードを行う前に cache_flush(D3K)、cache_invalid(D3K)
関数等を使用して、この空間に対応するキャッシュ上のデータを
ライトバック、インバリデートする等により実メモリ上のデータ
を保証する処理が必要でした。
UP4800モデル660/680/690では、このような処理は不要になり
ましたが、cache_flush(D3K)、cache_invalid(D3K) が使用され
ても実際には何の処理も行われないので、UP-UX/V(Rel4.0)用に
作られたドライバに改造を加える必要はありません。
また、nocachealloc(D3DK)関数を用いてキャッシュ無効空間
として CPUと VMEバス間のデータ授受に用いるメモリを確保す
ることにより、CPUからキャッシュを使用しないで直接メモリを
アクセスする手段も、UP従来機種で使用されていましたが、
UP4800モデル660/680/690では nocachealloc(D3DK)関数を用い
て確保されたメモリであっても、実際にはキャッシュを用いて
アクセスされるので、このような処理は不要です。これについて
も、UP-UX/V(Rel4.0)用に作られたドライバに改造を加える必要
はありません。
☆ インタフェース(UP4800 モデル625/635)
◇ アドレスマップ
UP4800 モデル625/635 の VME アドレスとCPU アドレスは
以下に示すとおり 1対1に対応しています。
0x0000 0000+------------+ +------------+0x0000 0000
| | | |
| | | |
| | | |
| | | |
| | | |
+------------+ -------- +------------+
0xF200 0000| VME 空間 | | VME 空間 |0xF200 0000
0xF3FF FFFF|( VME - 1 ) | |( VME - 1 ) |0xF3FF FFFF
+------------+ -------- +------------+
0xF400 0000| VME 空間 | | VME 空間 |0xF400 0000
0xF5FF FFFF|( VME - 2 ) | |( VME - 2 ) |0xF5FF FFFF
+------------+ -------- +------------+
0xF600 0000| VME 空間 | | VME 空間 |0xF600 0000
0xF7FF FFFF|( VME - 3 ) | |( VME - 3 ) |0xF7FF FFFF
+------------+ -------- +------------+
| | | |
0xFFFF FFFF+------------+ +------------+0xFFFF FFFF
CPU 物理アドレス VME アドレス
上図に示した通り，VMEアドレスの0xF2000 0000～0xF7FF FFFF
までの空間は， CPU 物理アドレス上 の VME1,2,3 空間に 1対
1にマッピングされています。また，VME1,2,3 の各空間は，さ
らに以下に示すように分類されます。
VME - 1 VME - 2 VME - 3
0xF200 0000 0xF400 0000 0xF600 0000+---------------------+
| |
| |
| |
| |
| VME |
| |
| エージェント空間 |
| ( 32 ビットモード ) |
0xF380 0000 0xF580 0000 0xF780 0000+---------------------+
| VME |
| エージェント空間 |
| ( 24 ビットモード ) |
0xF3FF 0000 0xF5FF 0000 0xF7FF 0000+---------------------+
| ショート I/O 空間 |
0xF3FF FFFF 0xF5FF FFFF 0xF7FF FFFF+---------------------+
VME - 1,2,3 空間
次に物理アドレスと仮想アドレスの対応を以下に示します。
+----------+ +----------+
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | . 0xCA00 0000
| | . | |
| | . | VME 空間 |
| | . |(VME - 1) |
| | . 0xCFFF FFFF.
| | . .| |
| | . . | |
| |. . | |
0xF200 0000. . | |
| | . | |
| | . | |
| | . | |
| | . | |
| |. | |
0xF7FF FFFF. | |
| | | |
+----------+ +----------+
物理アドレス 仮想アドレス
◇ VME 空間のマッピングについて
UP4800 モデル 625/635 では、VME空間は常に仮想アドレス
の 0xCA000000 ～ 0xCFFFFFFF にマップされており、直接ア
クセスすることが可能です。
◇ キャッシュの制御について
通常カーネルは、キャッシュを使用してメモリをアクセスし
ます。一方 VMEバスがメモリをアクセスする場合には、キャッ
シュは使用されません。このため、CPU(カーネル)とVMEバス間
でメモリを介してデータの受け渡しを行うようなケースにおい
て、このメモリに対し、カーネルが通常の方法で、キャッシュ
を使用してアクセスする場合には、キャッシュ上のデータとメ
モリ上のデータの内容が異なることがあります。このような
ケースは、VMEバスがライトしたメモリを、CPUがキャッシュを
使用してリードする場合に発生します。また、UP4800 モデル
625/635では CPUがキャッシュを使用してライトした通常の場合
にも発生します。
そこで、CPUがこのような空間のリードを実行する前、および
VME がリードを行う前には cache_flush(D3K)、cache_invalid(D3K)
関数等を使用して、この空間に対応するキャッシュ上のデータ
をライトバック、インバリデートする等により実メモリ上のデー
タを保証する処理が必要となります。
詳しくは、「デバイスドライバリファレンス」の caches(D3K)
のページを参照願います。
または、nocachealloc(D3DK)関数を用いてキャッシュ無効空
間として CPUと VMEバス間のデータ授受に用いるメモリを確保
することにより、CPUからキャッシュを使用しないで直接メモリ
をアクセスすることも可能です。
☆ I/O ドライバを構成する関数
「デバイスドライバリファレンス」の D2セクション(ドラ
イバエントリルーチン)を参照願います。
☆ I/O ドライバで使用するカーネル関数
「デバイスドライバリファレンス」の D3セクション(カー
ネルユーティリティルーチン)を参照願います。
☆ I/O ドライバで使用するデータ構造体
「デバイスドライバリファレンス」の D4セクション(カー
ネルデータ構造体)を参照願います。
☆ カーネルとI/O ドライバのリンク
◇ ヘッダファイル
必要ならば I/O ドライバのヘッダファイルを
/usr/include/sys ディレクトリ配下に作成します。
◇ 割り込みベクタ番号
ユーザに対し開放している割り込みベクタ番号の範囲は10
進数で 192～255( 16進数で 0xC0 ～ 0xFF) となっています。
◇ 割り込みベクタテーブル
割り込みベクタテーブルは、各ドライバ固有の System(4)
ファイルの記述内容に従い、idbuild(1M)コマンドにより自
動的に作成されます。
割り込みベクタテーブルはシステムで 1つだけ作成されま
す。ユーザが作成した I/Oドライバの割り込み処理関数は、
各ドライバ固有の System(4)ファイルにて指定された割り込
みベクタ番号に対応した位置に登録されます。
System(4)ファイルに関しては、「UNIXカーネル再構築方
法の変更」ならびに「UNIXカーネル構築コマンドの変更」を
参照願います。
☆ unix カーネルの構築
「 unix カーネル再構築方法の変更 」ならびに
「 unix カーネル構築コマンドの変更 」を参照願います。
☆ インタフェース(EWS4800 モデル215/220/230/260)
◇ アドレスマップ
EWS4800 モデル215/220/230/260 のVME アドレスとCPU アド
レスとの対応を以下に示します。
0x0000 0000+------------+ +------------+0x0000 0000
| | | |
0x0800 0000+------------+. | |
| VME 空間 | . | |
|( VME - 1 ) | . | |
0x0FFF FFFF+------------+. . | |
| | . . | |
0xE000 0000+------------+ -------- +------------+0xE000 0000
| VME 空間 | . . | VME 空間 |
|( VME - 2 ) | . . |( VME - 2 ) |
0xEFFF FFFF+------------+ -------- +------------+0xEFFF FFFF
| | . .| |
0xF800 0000+------------+ -------- +------------+0xF800 0000
| VME 空間 | . | VME 空間 |
|( VME - 3 ) | .|( VME - 3 ) |
0xFFFF FFFF+------------+ +------------+0xFFFF FFFF
CPU 物理アドレス VME アドレス
上図に示した通り，VMEアドレスの0xF8000 0000～0xFFFF FFFF
までの空間は， CPU 物理アドレス上 の VME1,3 空間の両者に
マッピングしています。また，VME1,2,3 の各空間は， さらに
以下に示すように分類されます。
VME - 1 VME - 3
0x0000 0000 0xF800 0000+------------------------+
| VME |
| |
| エージェント空間 |
| ( 32 ビットモード ) |
0x0800 0000 0xFF00 0000+------------------------+
| VME |
| バッファエリア |
| (CPU からはアクセス |
| 禁止 ) |
0x0FFF FFFF 0xFF80 0000+------------------------+
| VME |
| エージェント空間 |
| ( 24 ビットモード ) |
0xE000 0000 0xFFFF 0000+------------------------+
| ショート I/O 空間 |
0xEFFF FFFF 0xFFFF FFFF+------------------------+
VME - 1,3 空間
VME - 2
0xE000 0000 +------------------------+
| VME |
| エージェント空間 |
|(32 ビットモード) |
0xEFFF FFFF +------------------------+
VME - 2 空間
注意： EWS4800 モデル 215 VME-2 空間は存在しません。
次に物理アドレスと仮想アドレスの対応を以下に示します。
+----------+ +----------+ +----------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | . 0x0800 0000 . | |
| | . | | | |
| | . | VME 空間 | . | |
| | . |(VME - 1) | | |
| | . 0x0FFF FFFF. . | |
| | . .| | | |
| | . . | |. . | |
0xA000 0000|. . | | | |
0xA800 0000. . | | . . | |
| kseg1 | . | | | |
| | . | | . . | |
| | . | | | |
| | . | | . . | |
| |. | | | |
0xAFFF FFFF. | | . .| |
0xC000 0000| | | 0xF800 0000|
| | | | . | |
| | | | | VME 空間 |
| | | | . |(VME - 1,3)
| | | | | |
| | | | .| |
+----------+ +----------+ +----------+
仮想アドレス 物理アドレス VME アドレス
◇ VME2,3 空間のマッピングについて
VME1 空間は，仮想空間のkseg0,1 空間と常時マップしてい
るため，kseg0,1 空間から直接アクセス可能です。しかし
VME2,3 空間にアクセスする場合，あらかじめ，mmap 関数を用
いてそれらの空間を仮想空間にマッピングしなければなりませ
ん。この詳細については「デバイスドライバリファレンス 」
の mmap の項を参照願います。
注意：EWS4800 モデル215 には，VME2 空間は存在しません。
◇ キャッシュのフラッシュ処理について
通常カーネルは，キャッシュを使用してメモリをアクセスし
ます。一方VME バスがメモリをアクセスする場合には，キャッ
シュは使用されません。このため，CPU ( カーネル ) と VME
バス間でメモリを介してデータの受け渡しを行うようなケース
において，このメモリに対し，カーネルが通常の方法で，キャ
ッシュを使用してアクセスする場合には，キャッシュ上のデー
タとメモリ上のデータの内容が異なることがあります。このよ
うなケースは，VME バスがライトしたメモリを，CPU がキャッ
シュを使用してリードする場合に発生します。そこで，CPU が
このような空間のリードを実行する前には，
cache_flush(D3DK) 関数等を使用して，この空間に対応するキ
ャッシュ上のデータをフラッシュする処理が必要となります。
または，nocachealloc(D3DK)関数を用いてキャッシュ無効空間
として CPU と VME バス間のデータ授受に用いるメモリを確保
することにより，CPU からキャッシュを使用しないで直接メモ
リをアクセスすることも可能です。
詳しいことは 、キャッシュ制御関数の項を参照願います。
☆ インタフェース(EWS4800 モデル350/380)
◇ アドレスマップ
EWS4800 モデル350/380 のVME アドレスとCPU アドレスとの
対応を以下に示します。
0x0000 0000 +------------+ +------------+ 0x0000 0000
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
0xF800 0000 +------------+ ------ +------------+ 0xF800 0000
| | | |
| VME 空間 | | VME 空間 |
| ( VME ) | | ( VME ) |
0xFFFF FFFF +------------+ ------ +------------+ 0xFFFF FFFF
CPU 物理アドレス VME アドレス
上図に示した通り，VME アドレスの0xF800 0000～0xFFFF FFFF
までの空間は，CPU物理アドレス上の VME 空間にマッピングし
ています。また，VME 空間は，さらに以下に示すように分類さ
れます。
VME
0xF800 0000+------------------------+
| VME |
| エージェント空間 |
| ( 32 ビットモード ) |
0xFF00 0000+------------------------+
| VME |
| バッファエリア |
| (CPU からはアクセス |
| 禁止 ) |
0xFF80 0000+------------------------+
| VME |
| エージェント空間 |
| ( 24 ビットモード ) |
0xFFFF 0000+------------------------+
| ショート I/O 空間 |
0xFFFF FFFF+------------------------+
VME 空間
次に物理アドレスと仮想アドレスの対応を以下に示します。
+----------+ +----------+ +----------+
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
vme_base; 注意 1 | | | |
| | . | | | |
| | . | | | |
| | . | | | |
| | .0xF800 0000 ....... 0xF800 0000
+----------+ | | | |
| | . | VME 空間 | | VME 空間 |
| | . | (VME) | | (VME) |
| | . | | | |
| | .| | | |
+----------+ +----------+....... +----------+
仮想アドレス 物理アドレス VME アドレス
注意 1:VME空間のマッピングについての項を参照して下さい。
◇ VME 空間のマッピングについて
VME 空間は，仮想空間のksseg 空間とマップしているため，
直接アクセス可能です。なお、VME 空間が実際にマップされて
いる仮想空間の先頭アドレスは、カーネル変数 vme_base の値
により知ることができます。
この変数の形式は以下の通りです。
#include <sys/nec_vme.h>
caddr_t vme_base;
また、VME 空間と vme_base で示される仮想空間は、Uncached
( キャッシュを使用しない )でマップされているため、ここを
アクセスする際には、後述のキャッシュフラッシュ処理は必要
ありません。
◇ キャッシュのフラッシュ処理について
通常カーネルは，キャッシュを使用してメモリをアクセスし
ます。一方 VMEバスがメモリをアクセスする場合には，キャッ
シュは使用されません。このため，CPU( カーネル ) とVME バ
ス間でメモリを介してデータの受け渡しを行うようなケースに
おいて，このメモリに対し，カーネルが通常の方法で，キャッ
シュを使用してアクセスする場合には，キャッシュ上のデータ
とメモリ上のデータの内容が異なることがあります。このよう
なケースは， VME バスがライトしたメモリを， CPU がキャッ
シュを使用してリードする場合に発生します。そこで，CPU が
このような空間のリードを実行する前には，「デバイスドライ
バリファレンス」に記述しているキャッシュ制御関数を使用し
て，この空間に対応するキャッシュ上のデータをフラッシュす
る処理が必要となります。
さらにモデル 350/380 においては、CPU から VME バスに対し
てデータをライトする場合にキャッシュ上のデータをメモリに
反映 ( ライトバック ) してやらなければいけません。この場
合もこれらキャッシュ制御関数を用います。 または，
nocachealloc(D3DK) 関数を用いてキャッシュ無効空間として
CPU とVME バス間のデータ授受に用いるメモリを確保すること
により，CPU からキャッシュを使用しないで直接メモリをアク
セスすることも可能です。
詳しいことは，キャッシュ制御関数の項を参照願います。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment