APC8750にNetBSD/evbarmを移植するための記録 9/26
シリアルコンソールのドライバを書くにあたって、まずはRPIをお手本にするということでsys/arch/evbarm/dev/plcom.cだけど、comドライバに似ているつくり、というコメントがある。16550Aを意識しているってことかなぁ。ひとまず避けるか。
シリアルコンソールドライバのサイズを比較してみる。
短くてわかりやすい。
が、fcomcons_bs_tagの扱いがほかと比べると違う。ほかというのはepcom.c, ixp12x0_com.cなど。
単独でbus_space_tag, handleを定義しているが、そうではなく、softcを定義して構造体でアクセスしている。_io.cというのがついている。なんかこれだけ。ふしぎ。
footbridgeってnetwinderなのか。evbarmかと思ったら、NetBSD/netwinderなのね。だから風情が違うって感じ。
epcom, ixp12x0あたりが似ていて、footbridgeが違うのはそこらへんが由来か。
シンプルなのはいいけど... 参考にするならevbarmあたりのほうがよさげって感じ?
とりあえず、sys/arch/evbarm/ixp12x0/ixp12x0_com.cをベースにスケルトンを作成。
ザックリソースを読んでわかったこと。
dev_type_open(xxx)はシステムコールなのかな。関数ポインタで該当するAPIを呼び出すのが主な仕事。
割り込みルーチンは、下準備をした後ソフトウェア割込みを発生させている模様。
ハードウェア割込みでそれぞれの割り込み処理をやらないのはなぜなんだろう。
ハードウェア割込みからはできるだけ早く復帰しましょう、っていうことなのか?
先ほどのリスト、
clpsはepoc32だったり。
sscomはevbarm/smdk2xx0, MINI2440、
sacomはhpcarmのJORNADAだったり。
imxはわれらがnetwalkerだったり。
ixp12x0とepcomはそっくりさん。どっちが先に作られたのかを見てみたら、ixp12x0が祖先の模様。
matchとattachはevbarmがわで定義しているみたいですね。
CFATTACH_DECL_NEWがarm/evbarmのどっちに所属するかはそこらへんが違い。
とりあえず、ixp12x0, epcomをベースに進めていくことにしよう。
wm8750というのを頭につけてこれまでやってきたけど、いかにも冗長だなと。
wmtぐらいでよさそうな気がする。どうせwmtなシリアルは似たようなもんだろうし、割り込みあたりは結構違うかもしれないけど、wm8xxxぐらいには同じなんじゃないかな。
そもそもドライバがuart, icu, tmrぐらいしかないので。ていうか、現時点で理解して(したつもりで)作っているのってicuぐらいしかない気がする。
この調子だと、いつになったらインタラクティブな入出力ができるかわからんなぁ。
やっぱり、新しいCPUは無謀だったか。後悔先に立たず。小さな目標を立ててクリアしていこう。
まずはcnシリーズぐらいは動かしたい。すでにputcは動いているのだから、現状ぐらいまでは戻そう。当然TXBUSYはCOMドライバじゃないから面倒見れるわけだし。うむ。
まとめると、
Linux久々に調べてみるか。UBOOTのコンフィグはここらしいな。
https://github.com/apc-io/apc-8750/blob/master/u-boot/include/configs/wmt.h
なんとここにwmtのソースがいっぱい。
https://github.com/apc-io/apc-8750/tree/master/u-boot/cpu/arm920t/wmt
シリアルコンソールドライバのサイズを比較してみる。
25,419 arm/clps711x/clpscom.c 26,322 arm/ep93xx/epcom.c 18,175 arm/footbridge/footbridge_com.c 26,658 arm/ixp12x0/ixp12x0_com.c 48,257 arm/s3c2xx0/sscom.c 34,717 arm/sa11x0/sa11x0_com.c 58,808 arm/imx/imxuart.c一番ちいさいfootbridge_com.cを見てみるか。
短くてわかりやすい。
が、fcomcons_bs_tagの扱いがほかと比べると違う。ほかというのはepcom.c, ixp12x0_com.cなど。
単独でbus_space_tag, handleを定義しているが、そうではなく、softcを定義して構造体でアクセスしている。_io.cというのがついている。なんかこれだけ。ふしぎ。
footbridgeってnetwinderなのか。evbarmかと思ったら、NetBSD/netwinderなのね。だから風情が違うって感じ。
epcom, ixp12x0あたりが似ていて、footbridgeが違うのはそこらへんが由来か。
シンプルなのはいいけど... 参考にするならevbarmあたりのほうがよさげって感じ?
とりあえず、sys/arch/evbarm/ixp12x0/ixp12x0_com.cをベースにスケルトンを作成。
ザックリソースを読んでわかったこと。
dev_type_open(xxx)はシステムコールなのかな。関数ポインタで該当するAPIを呼び出すのが主な仕事。
割り込みルーチンは、下準備をした後ソフトウェア割込みを発生させている模様。
1173 /* Wake up the poller. */ 1174 softint_schedule(sc->sc_si);ソフトウェア割り込みルーチンは、割り込みの種別(送信・受信)を判断して、それぞれの割り込みルーチンに飛ばしている。
ハードウェア割込みでそれぞれの割り込み処理をやらないのはなぜなんだろう。
ハードウェア割込みからはできるだけ早く復帰しましょう、っていうことなのか?
先ほどのリスト、
25,419 arm/clps711x/clpscom.c 26,322 arm/ep93xx/epcom.c 18,175 arm/footbridge/footbridge_com.c 26,658 arm/ixp12x0/ixp12x0_com.c 48,257 arm/s3c2xx0/sscom.c 34,717 arm/sa11x0/sa11x0_com.c 58,808 arm/imx/imxuart.cの素性を調べてみる。footbridgeはさっきのとおりnetwinder。
clpsはepoc32だったり。
sscomはevbarm/smdk2xx0, MINI2440、
sacomはhpcarmのJORNADAだったり。
imxはわれらがnetwalkerだったり。
ixp12x0とepcomはそっくりさん。どっちが先に作られたのかを見てみたら、ixp12x0が祖先の模様。
matchとattachはevbarmがわで定義しているみたいですね。
CFATTACH_DECL_NEWがarm/evbarmのどっちに所属するかはそこらへんが違い。
とりあえず、ixp12x0, epcomをベースに進めていくことにしよう。
wm8750というのを頭につけてこれまでやってきたけど、いかにも冗長だなと。
wmtぐらいでよさそうな気がする。どうせwmtなシリアルは似たようなもんだろうし、割り込みあたりは結構違うかもしれないけど、wm8xxxぐらいには同じなんじゃないかな。
そもそもドライバがuart, icu, tmrぐらいしかないので。ていうか、現時点で理解して(したつもりで)作っているのってicuぐらいしかない気がする。
この調子だと、いつになったらインタラクティブな入出力ができるかわからんなぁ。
やっぱり、新しいCPUは無謀だったか。後悔先に立たず。小さな目標を立ててクリアしていこう。
まずはcnシリーズぐらいは動かしたい。すでにputcは動いているのだから、現状ぐらいまでは戻そう。当然TXBUSYはCOMドライバじゃないから面倒見れるわけだし。うむ。
まとめると、
- evbarmがわにcomドライバを用意する(apccomとか?)
- dev_type_xxxシリーズは簡単そうなので実装
- cnシリーズを除くその他の関数は、#ifdefあたりで逃げる
- cnシリーズを実装
Linux久々に調べてみるか。UBOOTのコンフィグはここらしいな。
https://github.com/apc-io/apc-8750/blob/master/u-boot/include/configs/wmt.h
なんとここにwmtのソースがいっぱい。
https://github.com/apc-io/apc-8750/tree/master/u-boot/cpu/arm920t/wmt
コメント(0件)
- TB-URL http://www.tokuda.net/diary/0835/tb/