ESECに出展します【速報】
特殊電子回路㈱は、今年の5月16日(水)~18日(金)に、東京ビックサイトにて行われる組み込みシステム開発技術展(ESEC)に出展します。
http://www.esec.jp/
詳しい続報は後日。
特殊電子回路㈱は、今年の5月16日(水)~18日(金)に、東京ビックサイトにて行われる組み込みシステム開発技術展(ESEC)に出展します。
http://www.esec.jp/
詳しい続報は後日。
玄箱Proで使われているMarvel社製ARM9プロセッサ(88F5182)のJTAGデバッグ仕様は、ARM9の純正のやり方に準拠しているようです。
当方で開発中(というか開発の途中段階で放置していた)の、「ARM9TDMI用JTAGデバッガ」をつないでみたところ、それなりに動作することが確認できました。
それなりに動作というのは、まだこのARM9TDMI用デバッガが中途半端な出来具合なので、あらゆる機能が未完成で不安定なためです。
88F5812がARM9のJTAGデバッグ方法に互換性がないとすれば、ウンともスンとも反応しないはずですが、なんとなくステップ実行できたり、メモリの内容が読み出せたりしています。
近いうちにARM9のJTAGデバッガの開発も再開していきたい所存です。
ところで、この88F8512のJTAGのIDCODEはARM9のものとは異なり、オリジナルなものです。
このプロセッサにバウンダリスキャン機能が隠されていればいいのですが・・
玄箱Proの起動時におけるPCI Expressパケットを解析してみました。
まず驚いたことは、Configレジスタのアクセスがすべて32bit単位で行われてくることです。
たとえば、PCIのコマンドレジスタを読み出す場合は、04番地から2バイトを読み出すわけですが、PCIやPCI Expressは基本的に32bit単位でのアクセスなので、バイトイネーブルという機能を使って目的の2バイトを取り出すのが普通です。
ところが、玄箱Proでは、書き込みも含めて、すべてのコンフィグレジスタアクセスが32bitで送られてくるのです。
読み出しならば32bit単位で読み出してもそれほど問題はありませんが、書き込みを32bit単位でやるのは少々抵抗を感じます。
また、Messageパケットというものが1つも送られてこなかったのも特徴的です。
さて、昨日のブログでは、玄箱Proの起動画面で、
pexBarOverlapDetect: winNum 2 overlap current 0
mvPexInit:Warning :Bar 2 size is illigal
it will be disabled
というメッセージが出ている、と書きましたが、BAR2のレジスタを実装しても、このメッセージは消えませんでした。
ですが、その前後のPCI Expressパケットを解析しても、特に問題になりそうなところは見つかりません。
このエラーっぽいメッセージは、どうやらハード的な問題ではなさそうです。
詳しくはわかりませんが、玄箱Proに入っている「Linux version 2.6.12.6-arm1」が、何か特定のPCI Expressカードを対象にコンパイルされてしまっているのではないかと思われます。
とにかく、PCI Expressは正しく認識されて、すべてが起動したあとに、BAR0空間がアドレス0xE0000000に割り当てられたところまでは確認できました。
あまり役に立つ情報ではありませんが、玄箱ProのPCI Expressパケットを解析した結果を、ここにアップロードしておきます。ご興味のある方は参考にしてください。内容の保証はいたしません。
玄箱Proには、PCI Expresのコネクタがあります。
ここに、作ったばかりの特電IPコアを乗せたPCI Expressボードをさしてみたくなりました。
玄箱Proを早速、分解。
JTAGコネクタにはシルクでTDIやらTCKと、親切に書かれています。ARM互換のピン配置ですね。これは今度試してみることにしましょう。
シリアルのコンソールのコネクタにも、TXDやらRXDなどシルクが印字されています。親切です。
PCI Expressは、どうやら、PCI Expressのカードをさそうとすると基板と筐体がぶつかってしまいます。筐体のプラスチックを完全に外して、金属のフレームの状態にしないとだめなようですね。
で、XILINXのSpartan3 PCI Expressスタータキットを装着。
特電IPコアを書き込んで起動。
ハードディスクがなくても起動するようになったのは、ノーマル玄箱との大きな違いです。
PCI ExpressスタータキットのLEDの動きをみていると、IPコアはちゃんと認識されたっぽいのですが、ブート時にコンソールに表示される文字列を見ても、何もないときとあまり変化がないようです。
いや、よく見ると起動時のメッセージで、
--------------------------
Detected Tclk 166664740 and SysClk 250000000
Marvell USB EHCI Host controller #0: c04e4b00
Marvell USB EHCI Host controller #1: c04e4a40
pexBarOverlapDetect: winNum 2 overlap current 0
mvPexInit:Warning :Bar 2 size is illigal
it will be disabled
please check Pex and CPU windows configuration
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers enabled
SCSI subsystem initialized
usbcore: registered new driver usbfs
--------------------------
たぶんpexというのはPCI Expressのことを意味しているのでしょう。
Bar 2は有効にしていないはずなのにilligalだからdisableだよと言われてしまいました。
このメッセージはPCI Expressのスロットに何もささなくても表示されるので、いったいどういうことでしょうか。
LinuxでPCIのコンフィグ空間をいじるツールがあればいいのですが、ARM用にコンパイルしなければならないし・・うーん。
このメッセージを出なくするには、とりあえずBAR2空間を実装すればいいのでしょうか。
今日はもう遅いので、解析の続きはまた次回にします。
昨年の9月ごろから、少しづつ開発を進めてきたPCI Express IPコアですが、ようやくWindowsXPから認識されることができました。
前回の日記ではWindowsXPが起動中にフリーズすると書きましたが、原因はPCI Expressのフローコントロールがちゃんと設定されていなかっただけでした。
マルチファンクションの要求に対して正しく拒否応答するようにし、フローコントロールの部分を修正してみると、見事にWindowsXPが起動しました。
不明なデバイスとしてちゃんと認識されています。
プロパティを見てみると、「PCI Slot 5(PCIバス1,デバイス 0,機能0)」と表示されています。
そういえば、BIOSがいろいろ初期化している最初の時にはバス番号5番でいろんなリクエストが送られてきましたが、BIOSによる初期化の中盤からバス番号が1番になりました。きっと、PCIバス番号の再割り当てが行われたののだろうという推測が成り立ちます。
次に、プロパティをさらに詳しくみてみると、ベンダIDなどに設定した値などがデバイスインスタンスIDになっています。
そして、WindowsXP対応の、PCIのコンフィグレジスタやI/Oなどを見るツール(福田さんのPCIXP.EXE)を使わせてもらって、コンフィグレジスタを見てみると、見事に見えました!
ちなみに、使っているボードは、XILINXのSpartan3 PCI Expressスタータキットです。
世の中にはVirtex5LXTなんていうPCI Expressコア内蔵のFPGAも登場していますが、やはりSpartan3+外付けPHY用のIPコアを、今作る魅力というものもあるかと思います。
まだXC3S1000のSliceを14%しか使っていないし、BlockRAMは1個も使っていません。
140kゲート相当ですから、コンパクトでしょ?
スイッチのデータシートを見ようとホームページにアクセスしたら、こんな記事が。
「芸能界スイッチ王決定戦 !! at スイッチの日開」
3月23日(金)深夜 24:15~24:45
http://www.nikkai.co.jp/topics.cfm
ぜひともこれは見なければ。
事業化交換会に行ってまいりました。
未踏だけではなく、情報基盤とかIPAが支援した事業がすべて集まっています。
今回の交換会のテーマはmixi社長の笠原さんの公演です。
笠原さんが創業して会社を大きくしていった話で、年数と従業員数と売上の推移の関係がとても参考になりました。それからサイボウズ・ラボの畑さんのパネルディスカッション。
成功している人の話はいろいろと参考になります。
なるほど、謙虚に人の意見を聞く。これ重要ですね。
私もそう心がけていきたいです。
特電は創業3年目くらいですが、まだ同じようなカーブで伸びているのでまだ安心。
これから先、毎年2倍2倍に成長していけるかどうかが勝負ですね。
そして、懇親会。
事業化交換会も、もう7回目ですので、常連の方々の数が減ってまいりました。
あまり最初のころからの付き合いだった未踏の人は来ていないですが、その分、ある方と密度の濃いお話をさせていただきました。
P.S.
今年はESECに出展するかもしれないです。
すごく久しぶりに、IPコアの開発を続けています。
前回はPCI Expressのパケットを、JTAG Logic Analyzerを使って12番目までのパケットを解析しました。
その結果、BIOSが初期化する際に、PCIのコンフィグ空間にある拡張機能ポインタを辿っていって、PCI Express Cababilities Regsterを読み書きする手順が見えていました。
ですが、12番目以降のパケットは、なぜだか違うバス番号で送られてくるので、そこで作業は中断となっていました。
今回は、その12番目以降のパケットを解析してみます。
なぜバス番号が11番目までと12番目以降で違うのか。おそらく、BIOSはPCI初期化の一番最初の手順で、スロットに何もささっていないPCIバスも含めて数えてしまっているのでしょう。そして、何かがあるスロットだけを活かして、何もないスロットの番号をスキップして番号を再割り当てしたのではないかと思われます。
さて、12番目以降のパケットは、同様にPCI コンフィグ空間の0番や、4番、8番、34番などを読み出してきています。
特筆すべきは、33番目からのパケットです。
33 ConfigWr 0x010:F 書き込みデータはFFFFFFFF
34 ConfigRd 0x010:F 返答は00000000
35 ConfigWr 0x010:F 書き込みデータは00000000
36 ConfigWr 0x014:F 書き込みデータはFFFFFFFF
37 ConfigRd 0x014:F 返答は00000000
38 ConfigWr 0x014:F 書き込みデータは00000000
・・・
こんな感じで、BAR0~BAR5、そしてExpansion ROM領域の設定を行ってきています。
まるで解説書にあるようにBARxの設定を変更してきています。
57番目からのパケットは少々謎です。
57 ConfigWr 0x000:F 書き込みデータはFDA00001
58 ConfigRd 0x004:1 返答はxxxxxx00
コンフィグレジスタの0番(ベンダIDとデバイスID)に、変な値を書き込んできています。
書き込めるわけないのですが、何をしているのでしょう。
ちゃんとエラーを返すかどうか試しているのでしょうか。
前回の実験時はBIOSの起動中でフリーズしてしまっていたのですが、今回はコマンドレジスタやステータスレジスタやその他の必須のレジスタをちゃんと実装し、フローコントロールも無限大に設定したところ、ちゃんとBIOSまでは起動して、認識されるようになりました。
ベンダID等は適当な値を設定しています。(1234の5678)
ですが、WindowsXPが起動する段階で固まってしまいます。
どうやら100番目あたりからMultiFunctionの検出などを行ってきているようで、FunctionNumberを0から順番に増やしてVIDやHdrTypeを読み出してきています。
特電PCI Express IPコアは、MultiFunctionではないデバイスではないので、きっとエラー(UA)で応答しなければいけないのでしょう。今のIPコアでは、この処理をちゃんと行っていないのが、Windowsが起動時にフリーズする原因と思われます。
念願のフルICEを購入しました。
もちろん、新品じゃありません。
ジャンクの古ICEです。
フルICEというのを簡単に説明すると、CPUのかわりに挿すデバッグ用のモジュールです。
CPUのふりをして動作するのですが、その動作を自由に解析したりトレースしたり、さらには勝手に操作するということができるのです。
つまり、ユーザが作ったボードのCPUの線を全部引っ張り出して、フルICEという装置につなげば、CPUの動作をエミュレートさせることができて、効率よいデバッグができるというものです。
秋葉原の某ジャンク屋で、NECのCPU用のフルICEが大放出されていました。
どこかのリース・レンタル品だったもののようです。
NECのV850とか書いてあるので、おおっ、と思わずまとめ買いしてしまいました。
ですが、型番が違うので来月のInterfaceのV850用のICEとしては使えなさそうです。
ジャンクで、1台100円でした。
下の写真のフルICE詰め合わせでも、1000円です。
お店のお兄さんは、「ジャンクですがいいですか?」
ええ、もちろんいいです。実際に動かすわけではないですから。
眺めて楽しむものです。これがきっと萌えというものなのでしょう。
上の写真は、左から順にNEC純正の何かで、右側はソフ○アさんのMultiSTAC。
その上に写っているのはY○K○GAWAと書かれているICEで、
さらにその上はNECさんの純正のICEです。
MultiSTACはこれです。
本体だか電源らしき、大きい箱のユニットと、積み重ねていくトレースモジュールがあります。
次は、Y○K○GAWAと書かれた何かのICEらしき基板です。
写真右の実装されていないBGAのソケットにはASICと書かれていて、
写真左の石はXILINXのSpartan2Eでした。
次はNECの純正フルICEの、プローブ基板です。
このプローブ基板にはCPUが載っていて、D703091ARと書かれています。
この基板の裏は、下の写真のように剣山のように足が生えています。
何本かは折れたり曲がったりしています。
昔は、こういう装置を使ってデバッグを行っていたんですね。
おそらく1台100万円くらいの値段はしたでしょう。
今のCPUじゃBGAだしバスも速いので、全部の線を引っ張り出すのは難しいでしょうね。
それに、フルICEはどれも重いし、ごついし、高い。
JTAG-ICEに移行していった歴史が偲ばれます。
私が学生だった時には、大学の厚生課とかに行くと、
紙の掲示板にアルバイト募集のお知らせが貼られていました。
今ではそういうのが電子化されてしまったそうで、
全国の大学が発信するアルバイト情報を
取りまとめる業者というのがいるようです。
つまり、大学の掲示板にアルバイトの求人広告を出したいなら、
そういう業者を通さなければいけないようです。
大学が発信する情報なので、
危険な仕事やいかがわしい仕事を紹介してはいけないということなので、
業者の方が一軒一軒、会社をまわって現場を確認してからの掲示となるようです。
そういうわけで、今日はその業者の方がお見えになりました。
実際に確認に来る理由は、主に勤務地を実際に見るためのようです。
危険な仕事をやらせないかとか、学生に営業活動をやらせないかとか、
派遣に出さないかとか、そういったことを確認していきました。
ゲームのプログラム開発もだめみたいですね。
話を聞いていると、学生に営業をさせるという、ある意味すごい会社もあるみたいです。
広告料金は決して安くはないので、
何月に求人を出すのが最も効果的か聞いたのですが、
一概にはいえないということで、やはり教えてくれないです。
学生には、アルバイトの日程を決めてから授業の時間割を決めるひともいれば、
授業の時間割を決めてから、その合間にアルバイトいれる人もいるとのことです。
要は、優先順位の違いということで。
話を総合すると、3月末にも、4月にも出したほうがいいということらしいです。
--
午後は川崎方面の某社で打ち合わせが2件ありました。
後半は、会社近くの謎の小部屋へ案内されて、そこで打ち合わせ。
とても和気藹々とした雰囲気の会社でした。
今日は、青年技術士支援実行委員会の3月例会がありました。
この例会は、青年技術士支援実行委員会の委員補佐が準備するというものでした。
去年から委員補佐になった私は、この例会の懇親会をセットアップする係となりました。
懇親会の係というのは、いわゆる食べ物や飲みもの、会場の備品を手配する係のことです。
港区虎ノ門の近くで、オードブルやお寿司などを出してくれる業者さんで、安くて量がおおくて、見栄えのよい食事を提供してくれる、いわゆるコストパフォーマンスのよいところを探し、合計5社にわけて発注。
オードブル、寿司、ピザ、サンドイッチ、のみもの、と豪華かつ大量に安く発注することができました。
いざ懇親会。
・・ですが、余ってしまいました。
ちょっと足りなめに設定したつもりだったのですが。
反省。
40人参加のところを40人前で注文してはいけないんですね。
なるほど、人間は年をとるとあまり食べなくなるし、喋るのに夢中になると食べなくなる。
その上、ゆっくり食べると、少ない量でおなかがいっぱいになる。
こういうのって、だいぶん少なめに料理を用意しないといけないんですね。
勉強になりました。
パッケージファイル生成ウィザードを用意しました。
このウィザードを使うと、MITOUJTAG用のパッケージファイルを簡単に作ることができます。
MITOUJTAGは、デフォルトでは比較的良く使われると思われるXILINXやALTERAのデバイスで使用されているパッケージを中心に揃えてきました。
しかしながら、BGAタイプで15×23ピンという形状のデバイスをMITOUJTAGで使いたかったとしても、そのような変則的なパッケージはMITOUJTAGのデフォルトのパッケージファイルの中には含まれていませんでした。
このようなデバイスを使うには、BGA23×23といった具合にちょっと大きめのサイズのデバイスのパッケージファイルを使うか、テクニカルサポートを利用するしかありませんでした。
そこで、今回リリースするパッケージファイル生成ウィザードを使うと、これらのパッケージファイルを簡単に生成することができます。
パッケージ生成ウィザードは、下記のURLにありますので、ダウンロードしてご利用ください。
http://www.nahitech.com/support.html#pkgwiz
まず、ウィザードを起動すると、次のような画面が開きます。
この画面ではそのまま「次へ」を押してください。
次に、使用するデバイスのパッケージの種類を選択するダイアログが開きます。
BGAタイプならBGAを、QFPタイプならQFPを選択してください。
その次に、ピン数を指定するダイアログが開きます。
総ピン数で指定することもできますし、縦横のピンの数で指定することもできます。
次の画面は、2000ピンのデバイス用のパッケージファイルを生成する例です。
例えば、BGAタイプの400ピンのデバイスの場合は、総ピン数400で指定しても良いし、縦横20ピンのデバイスとして指定することもできます。
正方形なデバイスだけではなく、例えば、11×13というように、長方形を指定することもできます。
BGAデバイスを総ピン数で指定した場合は必ず正方形になります。平方根が整数にならない場合や、端が欠けているデバイスはどうなるのか、といった疑問もあるかと思いますが、上手い具合に推測して生成するようになっています。
その次の画面では生成するファイル名を指定します。基本的には自動的に名前がつけられるので、特に設定しなくてもよいでしょう。
もう一度「次へ」を押せば、パッケージファイルがMITOUJTAGのインストールフォルダの中に作られます。
さて、上の例で作った2000ピンのパッケージファイルを読み出してみましょう。
次の画面では、Spartan3が普通に表示されています。
ここで、デバイスを右クリックして、「パッケージの変更」を選択します。
そして、先ほど生成した"bga2000.pkg"を指定します。
すると、
このように、作ったパッケージファイルを読み出すことができます。
676ピンのデバイスに2000ピンのパッケージを割り当てているので余っちゃっていますね。
最後に、IntelのXEONプロセッサのパッケージを生成した例です。
縦25ピン、横31ピンの長方形のBGA(PGA?)パッケージです。
XEONプロセッサは、ほとんどが電源ピンですね。
パッケージ生成ウィザードは、下記のURLにありますので、ダウンロードしてご利用ください。
http://www.nahitech.com/support.html#pkgwiz
最近のコメント