鈴木(康)です。
<200002180356.MAA13642@newsa.net.arch.sony.co.jp>の記事において
kei@arch.sony.co.jpさんは書きました。
| 川島です。
|
| Suzuki-san:
| > | E55 の PCMCIA は、普通の PCIC デバイスではない(普通の
|ノートブックなどに
| > | 搭載されているのと同じではないという意味で)と聞いたような気がします。
| > | とするとかなりコードを書かないと無理かもしれません。
| > | (http://www.netbsd.org/Ports/hpcmips/ を参照。)
| >
| > linuxce で何か進捗があることを期待していたんですが、
| > 状況は変わっていないのですね。
| ええと...
| 正確に言うと作業している人はいて、途中まではやっているはずなのですが
| 最近忙しいらしくて CVS にコミットされていないという状況だと理解
| しています。
| (どうも US は PCMCIA 周りの作業プライオリティが低いような気がします。)
linuxce は、ramdisk 使うのが普通みたいですから、PCMCIA なしでも先に
行くんですね。
私みたいに 8MB の カシオペア for DoCoMo とか買っちゃうと PCMCIA は避けては
通れないという感じです。
| > 昨日調べてみたんですが、0x14008000 からなにかあるみたいです。
進捗あったんで報告します。
デバイスの知識ないんで、私のできることはこれぐらいかも...
--- ここから
0x1400000 から 0x15000000 まで 0x1000 おきに頭をダンプすると
0x10000 おきに同じパターンがあらわれます。
ということで、0x1400000 から 0x10000 までが I/O 空間と思ってよさそうです。
これぐらいのサイズならと思って全部ダンプしました。
で判ったこと 以下アドレスは、0x14000000 からのオフセット
0x0000 - 0x8000 よくわからない 不定値 が読めるときもある。
0x8000 - 0x87ff デバイスＡ ( 0x9ffff まで 同じパターン4回)
中にパターンのくりかえしを含む
(デバイスＡ1,Ａ2,Ａ3 にわけて考えた方が良い？)
0xa000 - 0xa7ff デバイスＢ ( 0xbffff まで 同じバターン4回)
0xc000 - 0xc3ff デバイスＣ ( 0xdffff まで 同じパターン8回)
# PCIC と サウンド と パワー関係ぐらいしかデバイスないと思うので、
# これで全部ではないだろうか。
# ひょっとしたら、0x0000 - 0x8000 に埋もれているのかも知れないけれど
# 一番複雑そうなデバイスＡが PCIC だと思う。
# write したら飛んだという傍証もあるし...
デバイスＡのダンプ
+0 +2 +4 +6 +8 +a +c +e :バイトアクセス (0-7)
00008000: 1f00 0100 0006 0000 0000 0000 0000 0000 :00000000 06000000
00008400: 0000 0000 0101 819f ffff ffff ffff 0000 :00000000 01019f81
00008410: 0000 ffff ffff ffff ffff ffff ffff ffff :0000ffff ffffffff
(84ff まで 8 回くりかえし)
00008500: 004c 0000 0007 0000 0000 0102 090a 0000 :4c000000 07000000
デバイスＢのダンプ
0000a000: 000b 0000 02f9 0001 0000 0000 0000 0000 :0b000000 f9000100
0000a010: 0000 0002 0006 0005 0000 0000 0000 0000 :00000200 06000500
デバイスＣのダンプ
0000c170: 0000 9e00 0000 50e0 0000 0000 0000 0000 :0000009e 0000e050
0000c370: 0000 0000 0000 7f50 0000 0000 0000 0000 :00000000 0000507f
--
鈴木 康司 ＠ＮＥＣ
suz@hpc.bs1.fc.nec.co.jp
TEL 0423-33-5381