前回、SDK14.4でコンパイルすることができた ので、ZedBoardをコンフィグレーションしてみた。
VirtualBox4.2.6 上のLinux12.10 にISE14.4 をインストールしてあるため、VirtualBox ウインドウのデバイス -> USBデバイス -> Digilent USB Device [900] を選択して、Windows 7 へのマウントを切り離し、Ubuntu にマウントした。
SDKで、Xilinx Tools メニュー -> Program FPGA を選択して、FPGAをコンフィグレーションしようとしたがエラーになってしまった。
次に、何がおかしいのかを確かめるために、より現象がわかりやすい iMPACT で確かめて見ることにした。
impact コマンドを入力して、iMPACT を起動した。
iMPACT でinitialize Chain を行ったところ、windrv6 がロードされないので、ケーブル・ドライバを再インストールしてくれというメッセージが出た。アンサー・レコードの22648 に書いてあるそうだ。
アンサー・レコードの22648 は、”
10.1 iMPACT - Linux OS/カーネル バージョン 2.4 へのザイリンクス ケーブル ドライバーのインストール ”だった。
アンサー・レコードの22648 によると
詳細は、次の『USB Cable Installation Guide』 (UG344) および install_drivers.tar.gz アーカイブ を参照してください。
のことだった。
早速、『USB Cable Installation Guide』を参照しながら、install_drivers.tar.gz アーカイブをダウンロードして、インストールすることにした。
install_drivers.tar.gz アーカイブを展開すると、install_drivers ディレクトリができた。その中に、readme.txt があってインストール方法が書いてあった。下に引用する。
Note: Root permission is required to perform the steps described in this section. 1) Disconnect all Xilinx USB cables from the host computer. 2) Open a shell or terminal console. 3) Extract the driver script and its support files to a local drive of the machine where the cable will be used by typing: tar xzvf install_drivers.tar.gz The extraction creates a directory named install_drivers in the current directory. 4) Navigate to the install_drivers directory by typing: cd install_drivers 5) Run the script by typing: ./install_drivers 6) When the installation is complete, reconnect the cable. 7. Change permissions on the USB / PC4 driver by typing: chmod 666 /dev/windrvr6.
上のインストール方法に従って、インストールを行った。
cd cd Work/install_drivers sudo ./install_drivesr
エラーが発生してしまった。
そうだ。dash shell から/bin/sh に切り替えてみよう。ということで、
sudo dpkg-reconfigure -plow dash コマンドを入力して、/bin/sh に切り替えてから、もう一度、
sudo ./install_drivesr コマンドを実行した。だが、やはりエラーだった。
ls /dev コマンドで、/dev ディレクトリを見ても、windrv6 は存在しなかった。
よって、この方法は諦めることにした。
次に、Ubuntu にダウンロード・ケーブルをマウントした時のUSBの状況を、
lsusb コマンドで見た。
それによると、ZedBoard のPROGポートをUbuntuにマウントした場合には、FT232H として見えていた。(最初のピンクの四角の中)
次に、Digilent社の
XUP USB-JTAG Programming Cable があったので、これをUbuntuにマウントすると、Xilinx, Inc. として見えた(上の図の2番めのピンクの四角の中)
これで、iMPACT を立ち上げると、zynq が見えた。
iMPACT を終了して、
xsdk コマンドでSDKを立ち上げた。
、Xilinx Tools メニュー -> Program FPGA を選択して、FPGAをコンフィグレーションした。
コンフィグレーション成功した。下にメッセージを示す。
19:16:31 INFO : FPGA configured successfully with bitstream /home/masaaki/HDL/ZedBoard/ZedBoard_CamDisp_wHDMI_144_2/ZedBoard_CamDisp_wHDMI.sdk/SDK/SDK_Export/system_hw_platform/download.bit.
Run Configuration を作成して、Run を実行した。
ソフトウェアが動作して、カメラ画像がディスプレイに出力された。
成功だ。 なお、ZedBoard のPROGポート経由では、アンサー・レコード42728、
”13.x/14.x iMPACT/ChipScope/XMD - Digilent プログラム ケーブルには LibUSB1.0 パッケージをインストールする必要がある ”を参考に、 libusb 1.0 パッケージをインストールしてみたが、やはり、ダウンロード・ケーブルとして認識されなかった。
VirtualBox4.2.6 上のUbuntu12.10 でのZedBoard のコンフィグレーションには、Digilent社の
XUP USB-JTAG Programming Cable か、Xilinx社のダウンロード・ケーブルが必要のようだ。
2013年02月27日 05:11 |
Xilinx ISEについて
| トラックバック:0
| コメント:0
”LinuxのSDK14.4でコンパイルエラー1 ”の続き。
最初に、Xilinx_ISE_DS_Lin_14.4_P.49d.3.0/CodeSourcery/lin ディレクトリの xilinx-2012.03-79-arm-xilinx-linux-gnueabi.bin をインストールする。
sudo sh xilinx-2012.03-79-arm-xilinx-linux-gnueabi.bin コマンドを入れたが、エラーになってしまった。dash shell から/bin/sh に切り替えるのだそうだ。
sudo dpkg-reconfigure -plow dash コマンドを入力した。
dash の設定ウインドウが開いた。<いいえ>を選択した。
もう一度、
sudo sh xilinx-2012.03-79-arm-xilinx-linux-gnueabi.bin コマンドを入力した。
Sourcery CodeBench Lite for Xilinx GNU/Linux ダイアログが開いた。Nextボタンをクリックした。
ライセンスを承認して、Nextボタンをクリックした。
インストールされるツールチェーンが表示された。Nextボタンをクリックした。
Typical が選択されている。Nextボタンをクリックした。
/opt/Xilinx/14.4/ISE_DS/EDK/gnu ディレクトリにarm ディレクトリをmkdir した。
Sourcery CodeBench Lite for Xilinx GNU/Linux ダイアログで、インストール・ディレクトリに/opt/Xilinx/14.4/ISE_DS/EDK/gnu/arm ディレクトリを指定した。Nextボタンをクリックした。
パスの設定画面。デフォルトのまま、Nextボタンをクリックした。
Link Folder を選択する。デフォルトのまま、Nextボタンをクリックした。
インストール前のサマリが表示された。Install ボタンをクリックした。
インストールがスタートした。
インストールが終了した。Nextボタンをクリックした。
Install Complete 画面が出る。Done ボタンをクリックした。(この画像はキャプチャし忘れたので、次にインストールしたxilinx-2012.03-83-arm-xilinx-eabi.bin の画像を示す)
次は、xilinx-2012.03-83-arm-xilinx-eabi.bin をインストールした。
最初に、/opt/Xilinx/14.4/ISE_DS/EDK/gnu ディレクトリにarm-eabi ディレクトリをmkdir した。
xilinx-2012.03-79-arm-xilinx-linux-gnueabi.bin と同様にインストールを進めていった。
なお、インストール・ディレクトリを設定する画面で、インストール・ディレクトリに/opt/Xilinx/14.4/ISE_DS/EDK/gnu/arm-eabi ディレクトリを指定した。
最後に、ツールチェーンへのパスを追加した。.bashrc のパスの設定を下に示す。(環境変数として大域的に使用するためにexport宣言を追加しました。2013/03/04)
PATH=$PATH:/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin:/opt/Xilinx/14.4/ISE_DS/PlanAhead/bin:/opt/Xilinx/Vivado/2012.4/bin:/opt/Xilinx/14.4/ISE_DS/EDK/bin/lin:/opt/Xilinx/14.4/ISE_DS/EDK/eclipse/lin/eclipse:/opt/Xilinx/14.4/ISE_DS/EDK/gnu/arm-eabi/bin:/opt/Xilinx/14.4/ISE_DS/EDK/gnu/arm/bin
export PATH
export CROSS_COMPILE=arm-xilinx-linux-gnueabi-
最後に、dash をデフォルトのシステムシェルとして戻した。
sudo dpkg-reconfigure -plow dash コマンドを再度入力して、dash の設定ウインドウで、<はい>を選択した。
もう一度、ターミナルから、
xsdk を入力して、SDKを立ち上げ、プロジェクトをクリーンしたら、コンパイルが通った。
2013年02月26日 04:34 |
EDK
| トラックバック:0
| コメント:0
”
LinuxでのISEやPlanAheadにXPSプロジェクトを入れた時のエラー ”で、/usr/bin/make を/usr/bin/gmake にリンクして、ISEプロジェクト内のXPSプロジェクトをインプリメントすることができた。
次に、
Linuxは関係なく、独自のソフトウェアで動作するカメラ回路 がPlanAheadプロジェクトなので、それで、PlanAheadプロジェクトでもプロジェクト内のXPSプロジェクトをインプリメントできるかどうか?確かめてみた。
やってみたところ問題なくインプリメントが終了した。
ハードウェアをSDKにエクスポートして、xsdk コマンドをターミナルで実行してSDKを立ち上げた。
Clean を行なって、すべてのプロジェクトをリコンパイルしたところエラーになってしまった。
エラーの内容は、arm-xilinx-eabi-gcc が見つからないというものだった。エラー内容を下に示す。
**** Build of configuration Debug for project cam_disp2 **** make all Building file: ../src/cam_disp2.c Invoking: ARM gcc compiler arm-xilinx-eabi-gcc -Wall -O0 -g3 -c -fmessage-length=0 -I../../cam_disp2_bsp/ps7_cortexa9_0/include -MMD -MP -MF"src/cam_disp2.d" -MT"src/cam_disp2.d" -o"src/cam_disp2.o" "../src/cam_disp2.c" /bin/sh: 1: arm-xilinx-eabi-gcc: not found make: *** [src/cam_disp2.o] エラー 127
検索すると、”
Xilinx-Zynq-Arm-Linuxマニュア ル ”が見つかった。それによると、”
14.1 EDK - パスにスペースが含まれるディレクトリにインストーラーがあると ARM ツールチェーンがインストールされない ”というXilinxアンサーがあるそうだ。
パスにスペースは入っていないのだが、 ARM ツールチェーンがインストールされなかったのだろうか?VirtualBox上のUbuntuということが影響しているのか?確かにISE_DS\EDK\gnu\arm というディレクトリは存在しない。ISE_DS\EDK\gnu の下はmicroblaze とpowerpc-eabi だけだ。ARMのツールチェーンはインストールされていないようだ。
アンサーによると、
/CodeSourcery/lin にインストーラーがあるそうだ。 Xilinx_ISE_DS_Lin_14.4_P.49d.3.0/CodeSourcery/lin ディレクトリに行くと、xilinx-2012.03-79-arm-xilinx-linux-gnueabi.bin とxilinx-2012.03-83-arm-xilinx-eabi.bin の2つのインストーラーがあった。
2013年02月25日 05:51 |
EDK
| トラックバック:0
| コメント:0
現在、Linux上で、
Digilent社のZedBoard のLinuxサンプル、
ZedBoard_OOB_Design.zip をダウンロードして展開し、ISEのプロジェクトを作成して、ZedBoard_OOB_Design\hw\xps_proj ディレクトリのsystem.xmp をISEのプロジェクトに入れてインプリメントを行った。(LinuxはUbuntu12.10、ISE14.4)
そうしたら論理合成時にエラーが発生した。エラー内容を下に示す。
ERROR:EDK - Error while running "gmake -f system.make netlist".
PlanAheadのプロジェクトでも同様にXPSプロジェクトを入れると論理合成時に同様にエラーになってしまう。
早速、Google で検索したところ、”
Synthesis problem of EDK project attached in the ISE 12.4 ”を発見した。それによると、/usr/bin/make を/usr/bin/gmake にリンクすれば良いらしい。
sudo ln /usr/bin/make /usr/bin/gmake
早速、実行したところ、エラーが無くなり、論理合成が進んでいる。
まだ論理合成の途中だ。
2013年02月24日 04:51 |
EDK
| トラックバック:0
| コメント:2
ZedBoard用のLinux カーネルコンパイルのためにVirtualBox上にUbuntu12.10 32ビット版をインストールした。
このUbuntu12.10にせっかくなので、ISE14.4 をインストールしてみようと思う。ARMプロセッサのツールチェインもあるということだ。
VirtualBoxは50GBの固定ディスクをUbuntu用に確保してある。Oracle VM VirtualBox マネージャーの設定をクリックして、
ディスプレイの設定で、拡張機能の3Dアクセラレーションを有効化(3) のチェックボックスにチェックを入れること 。これをチェックしないとUbuntu上でウインドウのドラックなどがとっても遅くなる。
・Xilinxのサイトから Xilinx_ISE_DS_Lin_14.4_P.49d.3.0.tar をUbuntu 上にダウンロードして、展開した。
レグシム ブログ の
ISE WebPack 13.3 インストール(ESXi-Ubuntu 11.10) を参照させてもらって、Ubuntu 上にISE14.4 をインストールしてみようと思う。
結局、最初にWebPACKをインストールして、うまく行ったのですが、ISE14.4のバグでCoreGenがバグってしまいました。再度、System Editon をインストールしようとしたら、50GBの固定ディスクを使いきってしまったので、200GBの固定ディスクを取ってSystem Editon をインストールしました。使用メモリはISEは750MBでも行けましたが、PlanAheadはスワップしまくりでした。1.5GBメモリを与えればインプリメント出来ました。現在は2GBのメモリを仮想マシンに与えています。
・パーミッションの設定を行なって xsetup を起動した。
・ISEのインストーラーが起動した。
・ライセンスを承認して、Edition を選択した。(下の図では、
WebPACKを選択していますが、他のEdition を選択したほうが良いです(ISE14.4はWebPACKにバグがあるから) 。現在はSystem Edition を選択しています)
・インストールオプションを選択する。Install Cable Drivers にはチェックしないほうが良いそうです。
・インストールするディレクトリを選択するダイアログは、そのままとした。
・サマリが表示された。Install ボタンをクリックした。
・インストールが進んで、ライセンス認証のダイアログが出た。Nextボタンをクリックした。
・Windows ではうまく行ったConnect Now ボタンではブラウザでライセンス認証画面に行かなかったので、Save Infomation ボタンをクリックした。
・Xilinx_Connet_Later.html を自分の Home にセーブした。
・Xilinx_Connet_Later.html をダブルクリックして起動した。
・Xilinx社のラインセンス認証サイトに飛んで、認証を行なった。
・Windows 同様、ライセンス・ファイル (Xilinx.lic) をメール添付でもらって、ライセンス認証ダイアログでCopy License を行うとライセンスが認証された。(WebPACKライセンスです)
・ISEのインストールが終了した。
次からは、ダウンロードケーブルのドライバをインストールする。
Xilinx JTAG Linux が参考になるそうだ。
・下のコマンドを実行した。
sudo apt-get install gitk git-gui libusb-dev build-essential libc6-dev fxload
・/opt/Xilinx ディレクトリに移動して、usb-driver をgit からリポジトリをクローンした。
cd /opt/Xilinx sudo git clone git://git.zerfleddert.de/usb-driver
・usb-driver のディレクトリに入って、make した。
cd usb-driver/ sudo make
・home ディレクトリの.bashrc の最後の行に下のPATH 設定を記述した。
PATH=$PATH:/opt/Xilinx/14.4/ISE_DS/ISE/bin/lin:/opt/Xilinx/14.4/ISE_DS/PlanAhead/bin:/opt/Xilinx/Vivado/2012.4/bin
・
source .bashrc コマンドを実行して、.bashrc の内容を反映させた。
・
ise コマンドをターミナルから実行すると、ISEが起動した。サンプルをインプリメントしてみた。問題なくインプリメントができた。
・配置配線後のPlanAhead を起動してみた。問題ない。
・
planAhead コマンドをターミナルから実行して、PlanAhead を起動し、BFTサンプルのインプリメントを行った。こっちも問題無くインプリメントが行えた。
・
vivado コマンドをターミナルから実行して、Vivado を起動し、PlanAhead と同じBFTサンプルのインプリメントを行った。問題無くインプリメントが行えた。PlanAhead とロジック素子の配置の様子の違いを比べてほしい。Vivado の方がロジック素子の配置がまとまっている。
2013年02月21日 05:54 |
Xilinx ISEについて
| トラックバック:0
| コメント:2
現在、今まで使っていたWindows XP からWindows 7 64ビット版に移行中です。
メモリはすでに8GB載っていたので、宝の持ち腐れでした。今度はメモリをフルに使えるようになりました。
XPは、USB接続のパソコン内蔵カードリーダーを入れてあったので、C,D,E,Fドライブがカードリーダーに割り当てられて、HドライブにWindowsがインストールされていました。そうすると、Cドライブを決め打ちで使ってくる”こまったちゃん”的なソフトもあって、だいぶ悩まされました。Win 7 を入れるにあったって、3台目のハードディスクを入れて、そこにインストールしました。そうすると自動的にWn 7 をインストールしたドライブがCドライブになりました。良かったです。
だいたいインストールも終了して、後は、使うときにソフトウェアをインストールすれば良いかな?と思います。
今度は、Virtualbox とPlanAheadが同時に動けるので、とっても快適です。
Xilinx関係では、ZedBoardも使えるようになりました。Cypress のUSBシリアルドライバをインストールするのが面倒というか、
ドライバのダウンロード・サイト が分かりづらかったです。
ZedBoard用CMOSカメラ回路 もPlanAhaed14.4でインプリメント出来ました。SDKでZedBoard にビットストリームをダウンロードまではできたのですが、ソフトウェアをどうしてもRUNできませんでした。結局、\ZedBoard_CamDisp_wHDMI_144_2\ZedBoard_CamDisp_wHDMI.sdk\SDK\SDK_Export フォルダ内のファイルを全て削除してから、PlanAheadでハードウェアをエクスポートし直して、もう一度作りなおしたら、CMOSカメラ回路が動作して、カメラ画像をディスプレイに表示することができました。
まだ、移行できてないソフトウェアもありますが、使うときにインストールしようと思っています。
次は、苦手分野のLinuxカーネル・ビルドです。Digilent 社のLinuxコンフィグレーションから、画像のフレームバッファを固定アドレスで、2面分確保したいと思っています。
2013年02月20日 05:02 |
パソコン関連
| トラックバック:0
| コメント:0
日曜日にハンターマウンテン塩原スキー場に行きました。奥さんと息子、下の娘の4人で行きました。息子の大学合格祝いです。受かってよかった。。。
晴れていたんですが、とっても寒かったです。それだけに雪の状態は最高でした。自分が2段階くらいうまくなった気がしました。
ゴンドラで頂上まで行きました。とっても良い天気で景色が最高でしたが、とっても寒く、風が強かったです。むき出しの顔に風が当たるので、凍傷になりそうでした。死にそうに寒かったです。でも、雪質最高で滑りやすく、アイスバーンも殆どありませんでした。プロペラターンしながら、ガンガン滑って来ました。99.9cmのショートスキーですが、気持よく滑れています。
11時前ころに早くもお昼にしました。ソースカツ丼頼んで食べたんですが、美味しかったです。ゲレ食もレベルが上がりましたね。ただ、1180円もして高かったです。レストハウスからの風景は快晴で飛行機雲ができています。暖かそうに見えますが、ところがどっこい、午前中ほどではないですが、寒かったです。
今度はリフトで頂上まで行ったのですが、頂上はやっぱり寒い。。。顔が寒すぎて、やはり死にそうになりました。午前3時前に犬に起こされたこともあって、お休みモード。奥さんと子どもたちは滑って来ましたが、私はレストハウスでケーキセットでお休みしました。
休んでいたので、帰りの運転も足が余裕でした。
とっても楽しいスキーだったんですが、気温が寒くて向かい風だと顔がとっても寒かったです。
2013年02月19日 04:57 |
ZedBoard
| トラックバック:0
| コメント:0
ブログ休止宣言をした 後でなんですが、ChipScope Pro で前回の波形と比べてみたので、それを書いておきます。
前回、Camera Controller とBitmap Display Controller のレイテンシを測定した のは、Linux が動作していない状態だった。今回は、Linuxが動作して、HDMIにフルHDの画像を表示したり、Linuxが動作していて、DDR3 SDRAMの帯域を使っている状態だ。それで、どのくらい前回からレイテンシが伸びているかを測定する。
まずは、Camera Controller から見ていこう。
Write トランザクションは、0x1A000000番地に、0x00A0845800604C30 をWriteしている。最後のWriteデータ転送が終了してから、MON_AXI_BVALID がアサートされるまでに、54クロック経過していた。
Linuxが動作している状態では、63クロック経過している。
9クロック、9 x 10nsec = 90nsec レイテンシが増加している。
次に、Bitmap Display Controller を見ていこう。
アドレスを発行してからReadデータ転送を始めるまでのレイテンシは63クロックだった。
Linux が動作している状態では、73クロックになっていた。
10クロック、100nsec 増加していた。
アドレスを発行してからReadデータ転送を始めるまでのレイテンシは、69クロックから73クロックまでの間でばらつくようだ。
2013年02月18日 05:11 |
ZedBoard
| トラックバック:0
| コメント:0
前回、カメラ画像を表示するソフトウェアを追加したLinuxイメージをSDカードに追加して、電源ONでLinuxがブートし、カメラ画像を自動的に表示することが出来た。 だが実は、それにはバグが有った。
GPIOの出力を1にして、Camera Controller と Bitmap Display Controller のリセットを解除して動作させたところ、Linuxコンソールの表示がおかしくなってしまった事があった 。この時は、フレームバッファのアドレスを何らかの原因で自作のカメラ表示回路が間違ったのか?と思っていた。でも、”
ZedBoard Linux のフレームバッファにカメラ画像を表示8(カメラ画像表示成功) ”で、ChipScope Pro で解析してみたが、きちんと0x1AXXXXXX 番地をアクセスしていた。本来は動作に問題ないはずがバグってしまった。現在のSDカードでカメラ表示回路を生かしている状態でも、確率的に動作する状態と、Linuxが死んでしまう状態になってしまうことがわかった。10回、電源ON時にLinuxが死んでしまうかどうか?を調査した。それを下に示す。X がLinuxが死んでしまう状態になった時、O が正常な状態の時を示す。
XXOOOXXOOO
上の場合は、2/5 の確率でLinux が死んでしまう。たぶん、Linux のフレームバッファはkmalloc() などでアロケートされるのだと思う。それがたまたま0x1A000000 スタートになっただけなのだと思う。条件が違えば、異なるアドレスになると考えられる。元の回路では、AXI VDMAのフレームバッファのアドレスはソフトウェアで変更ができるので、フレームバッファのアドレスを固定する必要はない。Linuxカーネルでフレームバッファを固定アドレスに割り振っていないと考えられる。
次に、フレームバッファにARMプロセッサから黒のカーソルが書かれているようだ。
HDMI画面を見ると、下のように黒いカーソルが見える。(ピンクの矢印の部分)
これは点滅していて、時々書かれているようなのだ。この影響は、VGA画面に3本の筋となって現れる。
ある一定時間経つと、黒のカーソルがブリンクするのは停止する。VGA画面の3本の線も無くなった。
これらのことから、やはりLinuxカーネルを自分でビルドして、固定アドレスのフレームバッファ領域を確保する必要がありそうだ。
これからLinuxカーネルビルドして、固定アドレスのフレームバッファ領域を確保してみようか?と思っている。何分にもソフトウェアはよくわからないので、だいぶ迷うかもしれない。その際は、よろしくお願いします。
現在使用しているWindows XP 32ビット版にもメモリなどの限界を感じているので、この機会にWindows 7 64ビット版に乗り換える予定です。入れ替え作業をしますので、ブログが書けない可能性が大です。
2013年02月18日 04:01 |
ZedBoard
| トラックバック:0
| コメント:0
前回、SDKのリモートデバック機能を使用して、Windows 上で動作するSDKからZedBoard上に、ELFファイルをSSH接続でアップロードして動作させ、カメラのレジスタ設定を行った 。
今回は、SDカードのイメージにカメラレジスタ設定プログラムを追加して、Linuxのブート時に自動的に起動するように設定する。
まずは、Linuxの起動について勉強した。”
第10回 Linux起動の仕組みを理解しよう[init/inittab編] ”を参考にした。
/etc/inittab に処理が定義してあった。inittab に下に示すようにsysinit が定義されていた。
::sysinit:/etc/init.d/rcS
よって、/etc/init.d/rcS が初期化時に起動することがわかった。rcSの記述に
echo "++ Configure static IP 192.168.1.10" ifconfig eth0 down ifconfig eth0 192.168.1.10 up
があったので、自分のIPアドレスに変更した。
echo "++ Configure static IP 192.168.3.130" ifconfig eth0 down ifconfig eth0 192.168.3.130 netmask 255.255.255.0 up
そして、最後の”rcs Complete"と表示する前に、
/Apps/cam_disp3_linux.elf
を記述した。
これで、rcS の書き換えは終了したが、これをSDカードのramdisk8M.image に書き込む必要がある。そのやり方は、”
Modify your boot image on your ZedBoard ”を真似させて頂いた。
・ルート・ディレクトリに行って、sdcard ディレクトリを作製した。
zynq> cd /zynq> mkdir sdcardzynq> ls Apps etc linuxrc opt sbin tmp bin lib lost+found proc sdcard usr dev licenses mnt root sys var
・/dev/mmcblk0p1 を /sdcard にマウントして、ls コマンドで見ると、SDカードの内容が見えた。
zynq> mount /dev/mmcblk0p1 /sdcardzynq> ls sdcard BOOT.bin README ramdisk8M.image.gz BOOT_org.BINo devicetree_ramdisk.dtb zImage
・/sdcard/ramdisk8M.image.gz を /tmp ディレクトリにコピーして、展開し、/mnt にマウントする。
zynq> cp /sdcard/ramdisk8M.image.gz /tmp/zynq> gunzip /tmp/ramdisk8M.image.gzzynq> mount -o loop /tmp/ramdisk8M.image /mnt/ [22221.420000] EXT4-fs (loop0): couldn't mount as ext3 due to feature incompatibilities [22221.470000] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem [22221.470000] EXT4-fs (loop0): warning: mounting unchecked fs, running e2fsck is recommended [22221.480000] EXT4-fs (loop0): mounted filesystem without journal. Opts: (null)zynq> ls /mnt bin lib lost+found proc sys var dev licenses mnt root tmp etc linuxrc opt sbin usr
・/Apps/cam_disp3_linux.elf と /etc/init.d/rcS を /mnt ディレクトリにコピーする。
zynq> cp -r Apps /mnt/zynq> cp /etc/init.d/rcS /mnt/etc/init.d/rcS
・ramdisk8M.image.gz を生成して、SDカードに書き込んだ。(umount のオプションは、-L(小文字)です)
zynq> umount -l /mntzynq> gzip -9 /tmp/ramdisk8M.imagezynq> mv /tmp/ramdisk8M.image.gz /sdcard/zynq> umount -l /sdcard/
これで、Linuxの初期化時にカメラの設定ソフトウェアを起動することが出来た。
ZedBoard を電源ONして、Linuxが起動した時にカメラ画像がVGAディスプレイに表示された。おまけに、正しいIPアドレスも設定できた。
参照させて頂いた2つのサイトにお礼を申し上げる。
2013年02月16日 12:01 |
ZedBoard
| トラックバック:0
| コメント:0
前回は、GPIOの出力ポートを1に出来て、Camera Controller とBitmap Display Controller のリセットを解除することが出来た 。そこまでは出来たのだが、カメラのレジスタ設定が出来なかった。今回はなぜ、カメラのレジスタ設定が出来ないかとその回避策を探ってみた。
SDKリモートデバックでステップ実行を行うと、カメラ設定用のI2CのステータスレジスタRead でReadしたデータが0で止まっていた。ステータスレジスタのRead はI2Cの動作がすべて完了したことを確認しているので、その代わりにusleep(1000); を入れてみたところ、カメラの設定がうまく行って、画像が表示できた。
なぜRead出来ないかは分からないが、とりあえず、画像が表示できたので、良かった。これで、カメラの画像をLinuxから読める可能性が出てきた。(今のところRead がおかしいと思っているので、控えめな表現にしましたw)
ソフトウェアのコードは、”
RPi Low-level peripherals ”の void setup_io(); を使わせていただいていた。
前回、ZC702ボードでLinuxからaxi_gpio やMIO のGPIO をアクセスした際 にも、 void setup_io(); はブログに載せていなかったが、、”
RPi Low-level peripherals ”の void setup_io(); のコードが変わっていたので、以前のコードを参照させていただいたことにして、全ソースコードを載せておこうと思う。free() や munmap() もしていない。(
注:バグ有りコードです。Readできません) #define XPAR_AXI_GPIO_0_BASEADDR 0x44000000 #define XPAR_AXI_IIC_MT9D111_BASEADDR 0x45000000 #include <stdio.h> #include <string.h> #include <stdlib.h> #include <dirent.h> #include <fcntl.h> #include <assert.h> #include <sys/mman.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #define PAGE_SIZE (4*1024) #define BLOCK_SIZE (4*1024) volatile unsigned *setup_io(off_t addr);volatile unsigned *cam_i2c_control_reg;volatile unsigned *cam_i2c_status_reg;volatile unsigned *cam_i2c_tx_fifo;volatile unsigned *cam_i2c_rx_fifo;void cam_i2c_init(void ) { *cam_i2c_control_reg = 0x2 ; *cam_i2c_control_reg = 0x1 ; }void cam_i2x_write_sync(void ) { usleep(1000 ); }void cam_i2c_write(unsigned int device_addr, unsigned int write_addr, unsigned int write_data){ *cam_i2c_tx_fifo = 0x100 | (device_addr & 0xf e); *cam_i2c_tx_fifo = write_addr; *cam_i2c_tx_fifo = (write_data >> 8 )|0xf f; *cam_i2c_tx_fifo = 0x200 | (write_data & 0xf f); cam_i2x_write_sync(); }int main() { volatile unsigned *cam_i2c, *axi_gpio; volatile unsigned *axi_gpio_tri; cam_i2c = setup_io((off_t)XPAR_AXI_IIC_MT9D111_BASEADDR); axi_gpio = setup_io((off_t)XPAR_AXI_GPIO_0_BASEADDR); cam_i2c_control_reg = cam_i2c + 0x40 ; cam_i2c_status_reg = cam_i2c + 0x41 ; cam_i2c_tx_fifo = cam_i2c + 0x42 ; cam_i2c_rx_fifo = cam_i2c + 0x43 ; axi_gpio_tri = axi_gpio + 0x1 ; *axi_gpio_tri = 0 ; *axi_gpio = 0x1 ; cam_i2c_init(); cam_i2c_write(0x ba, 0xf0 , 0x1 ); cam_i2c_write(0x ba, 0x97 , 0x20 ); return (0 ); }volatile unsigned *setup_io(off_t mapped_addr) { int mem_fd; char *gpio_mem, *gpio_map; if ((mem_fd = open("/dev/mem" , O_RDWR|O_SYNC) ) < 0 ) { printf("can't open /dev/mem \n" ); exit (-1 ); } if ((gpio_mem = malloc (BLOCK_SIZE + (PAGE_SIZE-1 ))) == NULL) { printf("allocation error \n" ); exit (-1 ); } if ((unsigned long )gpio_mem % PAGE_SIZE) gpio_mem += PAGE_SIZE - ((unsigned long )gpio_mem % PAGE_SIZE); gpio_map = (unsigned char *)mmap( (caddr_t)gpio_mem, BLOCK_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, mem_fd, mapped_addr ); if ((long )gpio_map < 0 ) { printf("mmap error %d\n" , (int )gpio_map); exit (-1 ); } return ((volatile unsigned *)gpio_map); }
東北学院大学の熊谷先生の”
デバイスドライバに頼らないハードウェア操作 ”は、とってもためになるページなので、この辺を参照しながら、0x1A000000 からのフレームバッファをARMプロセッサから読んでみたい。
(おまけです)
2頭のペンギンが写っていたHDMI画面は、800 x 600 ピクセルのカメラ画像のフレームバッファとして使用しているので、下の写真の様な画面が表示されています。HDMIの画面は、1920 x 1080 のフルHDです。後ろから日の光が差しているので、私の姿が写っています。
(2013/02/18:追記) Linuxが死なないで、正常動作するのはフレームバッファが0x1A000000 スタートに割り当てられる場合と考えられます。確率的にLinuxが死んだりします。詳しくは、
”ZedBoard Linux のフレームバッファにカメラ画像を表示13(未完成) ”を御覧ください。
2013年02月16日 05:12 |
ZedBoard
| トラックバック:0
| コメント:0
”
ZedBoard Linux のフレームバッファにカメラ画像を表示9(SDKリモートデバック) ”の続き。
前回は、ARMプロセッサから供給されているFCLK_CLK3 のクロックがSVGAのピクセルクロックから変更されていることが考えられた。そこで、FCLK_CLK3 をSVGAのピクセルクロックに使用するのを中止して、XPSプロジェクト内のclock_generator_0 からSVGAのピクセルクロックを生成することにした。
clock_generator_0 の入力はFCLK_CLK1 だったが、このクロックは167MHzで、clock_generator_0 の入力クロックの設定の200MHzと合わない。200MHzのクロックは、FCLK_CLK2 なので、clock_generator_0 の入力クロックを FCLK_CLK2 に変更した。
次に、CLKOUT1 を40MHzに設定して、mt9d111_inf_axi_master_0 (Camera Controller) とbitmap_disp_cntrler_axi_master_0 (Bitmap Display Controller) のピクセルクロックに接続した。
この設定で、論理合成、インプリメントを行い、SDKを立ち上げてデバックを行った。
Debug Configuration を作成してある場合のデバック方法は、
”
Zynq-7000(ZC702)のLinuxチュートリアル4(リモートデバック2) ”
を参照のこと。デバックするファイル名は、cam_disp3_linux.elf に変更した。
GPIOの出力を1にして、Camera Controller と Bitmap Display Controller のリセットを解除して動作させたところ、Linuxコンソールの表示がおかしくなってしまった。
SDKリモートデバックもおかしくなってしまった。
カメラ画像の表示はされているが、画像がおかしい。たぶんYCbCr で行われていると考えられる。GPIOを1にした時点でおかしくなっているので、カメラにRGB565モードを設定できていない。
つまり、GPIOから1を出力すると、Camera Controller と Bitmap Display Controller のリセットが解除されるので、そこで書き込んだメモリがLinuxで使われていたんだと思う。
以前、2頭のペンギンをHDMIで表示しているフレームバッファのアドレスを0x1A000000 と調べて、そのアドレスをCamera Controller と Bitmap Display Controller で使っているはずだった。しかし、ペンギンは正常に表示されていたので、アドレスを0x1A000000 に指定しきれていなかったのか?今はダイアログでアドレスを入力しているので、HDLで直接書いて調べてみることにした。
(2013/02/18:追記) Linux が死んだのは、カメラ表示回路がおかしい訳ではなく、Linixカーネルのフレームバッファのアドレスか0x1A000000 から変更されたのではないか?と考えられます。詳しくは、
”ZedBoard Linux のフレームバッファにカメラ画像を表示13(未完成) ”を御覧ください。
2013年02月15日 05:13 |
ZedBoard
| トラックバック:0
| コメント:0
前回は、Linuxを起動しない状態で、カメラ表示回路でカメラ(MT9D111)のレジスタを設定して、VGA出力にカメラ画像を表示することが出来た 。
今回は、SDK14.4を使用して、パソコンのWindows 上のSDK14.4から、ZedBoardのLinuxにリモートデバックを行う。
参考文献は、”
Zynq-7000 EPP コンセプト、ツール、テ クニック ガイド 効率的なエンベデッド システム構築をサポートするハンディガイド UG873 (v14.2) 2012 年 7 月 27 日 ”の44ページ、”5.2.4 テストドライブ : SDK リモートデバッグを使用して Linux アプリケーションをデバッグする”。
それと、ZC702ボードのリモートデバック方法を参照のこと。
Zynq-7000(ZC702)のLinuxチュートリアル3(リモートデバック) Zynq-7000(ZC702)のLinuxチュートリアル4(リモートデバック2) Zynq-7000(ZC702)のLinuxでMIOに接続されているLEDを制御 Zynq-7000(ZC702)のLinuxでMIOに接続されているLEDを制御2 すでにSDカードには、カメラ表示回路の入ったビットストリームをBOOT.bin に入れてある。BOOT.bin の作り方は、”
カメラの表示回路及びソフトウェアをSDカードからブートする ”を参照のこと。cam_disp2.elf の代わりに、ZedBoard_OOB_Design\boot_image\u-boot.elf を入れて、BOOT.bin を作製した。
・ZedBoardにSDカードを入れて、電源を入れてLinuxをブートした。
・ ifconfig eth0 192.168.3.130 netmask 255.255.255.0 を入力して、ZedBoardのIPアドレスを設定した。(家のプライベートIPです)
・SDKのFileメニューから New -> Application Project を選択した。
・New Project ダイアログで、Project Name に cam_disp3_linux と入力し、Target Software の OS Platform のプルダウンメニューから linux を選択した。Next -> をクリックした。
・Linux Empty Application を選択して、Finish ボタンをクリックした。
・cam_disp3_linux プロジェクトが出来たので、予め作ってあった cam_disp3_linux.c をcam_disp3_linux -> src フォルダにドラックアンドドロップした。
・cam_disp3_linux プロジェクトを右クリックして、右クリックメニューからDebug as -> Debug Configurations を選択した。
・Debug Configurationウイザードで、Remote ARM Linux Application を右クリックして右クリックメニューからNew を選択した。
・Debug Configurationウイザードで、Connection のNew ボタンをクリックした。
・New Connection ウイザードが開く。SSH Only をクリックした。Next -> ボタンをクリックした。
・Host Name にZedBoard のIPを入力した。(192.168.3.130)
・Description には、cam_disp3_linux_test と入力した。
・Finishボタンをクリックした。
・ Remote Absolute File Path for C/C++ Application のBrows... ボタンをクリックした。
・ウイザードでroot を展開する。
・Enter Passwordウイザードで、ID (root) とパスワード (root) を入力する。
・Save User ID と Save Password のチェックボックスにチェックを入れる。
・OKボタンをクリックした。Warning ダイアログが出た。Yesボタンをクリックした。
・Select Remote C/C++ Application File ダイアログで、ツリー状のマークを展開した。
・Rootの下にフォルダを作る。右クリックメニューからNew -> Folder をクリックした。
・New folder name: にApps と入力した。Apps フォルダを作成する。
・Apps フォルダの右クリックメニューからNew -> File を選択した。
・New file name: に cam_disp3_linux.elf と入力して、ファイルを作成した。
・Apps フォルダの下にcam_disp3_linux.elf が作成された。OKボタンをクリックした。
・TeraTerm で確認するとルートの下にApps ディレクトリの下に cam_disp3_linux.elf が作成されているのが見えた。
・Debug Configuration に戻って、Apply ボタンをクリックした。
・Debug ボタンをクリックして、Debug を開始した。
・パースペクティブをデバックにスイッチするダイアログが出るので、Yes ボタンをクリックした。
・Eclipse がデバックモードになって main() の最初の行で停止している。
・こんな感じでリモートデバックしている。
(2013/02/15:追加) リモートデバックはうまく出来ているのだが、カメラ画像が映らない。デバック中。
(2013/02/14:追加) ソフトウェアでGPIOを制御して、VGAの出力は出ているようなのですが、出力周波数がディスプレイのロック範囲を超えてしまっているようです。FCLK_CLK3を40MHzに設定して、ピクセルクロックに使っているので、そこが書き換えられたんでしょうか?
2013年02月13日 05:45 |
ZedBoard
| トラックバック:0
| コメント:2
前回、画面表示できないバグがわかってVHDLコードを修正した ので、今回はインプリメントして確かめてみた。
インプリメント後に、ZedBoardにコンフィグレーション、ソフトウェア起動後、画像が表示できました(Linux は起動していない状態)。
(昼間なので、日の光でディスプレイ画面が光ってしまった)
ChipScope Pro Analyzer で波形を見てみた。
最初に、Camera Controller (mt9d111_inf_axi_master_0) のタイミング波形を示す。
アドレスも0x1Axxxxxx に入っていて、転送も正しく出来ていることが分かる。
最初のトランザクションを拡大してみた。
このWrite トランザクションは、0x1A000000番地に、0x00A0845800604C30 をWriteしている。最後のWriteデータ転送が終了してから、MON_AXI_BVALID がアサートされるまでに、54クロック経過している。
次に、Bitmap Display Controller (bitmap_disp_cntrler_axi_master_0) の波形を観察した。下にタイミング波形を示す。
1つのReadトランザクションを拡大した。
アドレスを発行してからReadデータ転送を始めるまでのレイテンシが長い。63クロック、クロック周波数は100MHzなので、630nsec 経過している。また、MON_AXI_RVALID が1と0を交互に行ったり来たりしている。バースト転送のスループットを計算してみよう。バーストデータ転送数はMON_AXI_ARLEN が0x3Fなので、64個となる。64個の転送に105クロック必要としていたので、スループットを計算する式は以下のようになる。
(1回の転送バイト数)8 バイト x 100(MHz) x 64/105 ≒ 488(MBytes/sec)
最大転送スループットは、800MBytes/sec なので、半分近くにまで落ちている。
下に、現在使用しているCMOSカメラ制御用ソフトウェアを貼っておく。今回、自分のIPでHDMIは使用していないので、設定はしていない。
#include "xparameters.h" #include "xgpio.h" void cam_iic_init(void ) { Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x100 ), 0x002 ); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x100 ), 0x001 ); }void cam_iic_write(u32 device_addr, u32 write_addr, u32 write_data) { Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), (0x100 | (device_addr & 0xf e))); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), write_addr); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), ((write_data >> 8 )|0xf f)); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), (0x200 | (write_data & 0xf f))); cam_iic_write_sync(); }void cam_iic_write_sync(void ) { while ((Xil_In32(XPAR_AXI_IIC_MT9D111_BASEADDR + 0x104 ) & 0x84 ) != 0x80 ) ; } u32 cam_iic_read(u32 device_addr, u32 read_addr) { u32 read_data; Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), (0x100 | (device_addr & 0xf e))); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), read_addr); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), (0x101 | device_addr)); Xil_Out32((XPAR_AXI_IIC_MT9D111_BASEADDR + 0x108 ), 0x202 ); while ((Xil_In32(XPAR_AXI_IIC_MT9D111_BASEADDR + 0x104 ) & 0x40 ) == 0x40 ) ; read_data = Xil_In32(XPAR_AXI_IIC_MT9D111_BASEADDR + 0x10 c) & 0xf f; read_data = read_data<<8 | (Xil_In32(XPAR_AXI_IIC_MT9D111_BASEADDR + 0x10 c) & 0xf f); return (read_data); }int main() { static XGpio GPIOInstance_Ptr; int xStatus; xStatus = XGpio_Initialize(&GPIOInstance_Ptr,XPAR_AXI_GPIO_0_DEVICE_ID); if (XST_SUCCESS != xStatus) print("GPIO INIT FAILED\n\r" ); XGpio_SetDataDirection(&GPIOInstance_Ptr, 1 , 0 ); XGpio_DiscreteWrite(&GPIOInstance_Ptr, 1 , 1 ); cam_iic_init(); cam_iic_write(0x ba, 0xf0 , 0x1 ); cam_iic_write(0x ba, 0x97 , 0x20 ); cam_iic_write_sync(); return 0 ; }
上記のソフトウェアを動作させないとVGAにカメラ画像を表示できないので、Linuxを起動した時にカメラ画像を表示できていない。次回はLinux上で同様の動作をするソフトウェアを作成して、Linux上でカメラ画像を表示してみたい。
2013年02月10日 05:21 |
ZedBoard
| トラックバック:0
| コメント:0
前回、
カメラ画像のディスプレイ表示がおかしかった ので、AXI4バスにChipScope AXI Monitor を入れてAXI4バスの波形を観察することにした。
XPSプロジェクトで、Bitmap Display Controller (bitmap_disp_cntrler_axi_master_0) とCamera Controller (mt9d111_inf_axi_master_0) に chipscope_axi_monitor を挿入した。chipscope_icon_0 も追加した。
Portsタブの接続を下に示す。
ISEでインプリメント後、ハードウェアをSDKにエクスポートして、ZedBoardをコンフィグして、ソフトウェアを起動した。
Chipscope Pro Analyzer を立ちあげて、AXI4バスの波形を観測した。
まずは、Bitmap Display Controller から下に示す。
波形的には問題ない。
次に、Camera Controller の波形を示す。
バースト長が長すぎる。アドレス転送部分を拡大してみた。
アドレスが0x2FB03AD0 で上限値を超えてしまっている。明らかにおかしい。もう一度トリガを掛けてみた。
アドレスは0xE028B550 だった。ぐるっとアドレスが回ってしまっている。
このアドレスはおかしい。アドレスを生成する部分は、mt9d111_cam_cont.v の124行目辺りにある。それを下に示す。
// addressの生成 always @(posedge aclk) begin if (areset) begin if (UPSIDE_DOWN==0) // 正常、それ以外は上下反転 paddr_reg <= DISPLAY_START_ADDRESS; else // 上下反転 paddr_reg <= DISPLAY_END_ADDRESS; end else begin if (pfifo_rd_en) begin if (UPSIDE_DOWN==0) // 正常 paddr_reg <= paddr_reg + 32'd8; else // 上下反転 paddr_reg <= paddr_reg - 32'd8; end else if (addr_rst_cs==ADDR_RST) begin // frame_valid が0になって、pfifoにデータが無くなった時にアドレスをクリア if (UPSIDE_DOWN==0) // 正常、それ以外は上下反転 paddr_reg <= DISPLAY_START_ADDRESS; else // 上下反転 paddr_reg <= DISPLAY_END_ADDRESS; end end end assign paddr = paddr_reg;
上のリストで、pfifo_rd_en が1の時にアドレスをインクリメントしている。pfifo_rd_en は、上のモジュールの mt9d111_inf_axi_master.vhd で M_AXI_WREADY が入っていた。
mt9d111_cam_cont_i : mt9d111_cam_cont generic map( DISPLAY_START_ADDRESS => C_DISPLAY_START_ADDRESS, UPSIDE_DOWN => C_UPSIDE_DOWN )port map( aclk => ACLK, areset => reset, pclk => pclk, preset => preset, pclk_from_pll => pclk_from_pll, xclk => xck, line_valid => href, frame_valid => vsync, cam_data => cam_data, standby => standby, paddr => M_AXI_AWADDR, pfifo_rd_en => M_AXI_WREADY, pfifo_dout => M_AXI_WDATA, pfifo_empty => pfifo_empty, pfifo_almost_empty => pfifo_almost_empty, pfifo_rd_data_count => pfifo_rd_data_count, pfifo_overflow => pfifo_overflow, pfifo_underflow => pfifo_underflow );
M_AXI_WREADY はいつも1なので、これではバグってしまう。ZedBoard用CMOSカメラ回路で正常動作していたのが不思議だ。たぶん、M_AXI_WREADY がアサートされるのが、M_AXI_WVALIDが1の時だけだったのだろうか?
mt9d111_inf_axi_master.vhd のmt9d111_cam_cont.v のインスタンス部分の記述を下のように変更した。
pfifo_rd_en <= M_AXI_WREADY and wvalid; mt9d111_cam_cont_i : mt9d111_cam_cont generic map( DISPLAY_START_ADDRESS => C_DISPLAY_START_ADDRESS, UPSIDE_DOWN => C_UPSIDE_DOWN )port map( aclk => ACLK, areset => reset, pclk => pclk, preset => preset, pclk_from_pll => pclk_from_pll, xclk => xck, line_valid => href, frame_valid => vsync, cam_data => cam_data, standby => standby, paddr => M_AXI_AWADDR, pfifo_rd_en => pfifo_rd_en, pfifo_dout => M_AXI_WDATA, pfifo_empty => pfifo_empty, pfifo_almost_empty => pfifo_almost_empty, pfifo_rd_data_count => pfifo_rd_data_count, pfifo_overflow => pfifo_overflow, pfifo_underflow => pfifo_underflow );
2013年02月09日 05:51 |
ZedBoard
| トラックバック:0
| コメント:0
前回は、ZedBoard Linux回路を使用して、Linuxを起動しない状態でカメラ回路が動作するかどうかを確かめてみたがカメラ画像を表示できなかった 。
フレームバッファのスタート・アドレス0x1A000000 にピクセルデータを格納することに問題はないかどうか?確かめてみることにした。
Linuxを動作させない通常のカメラ回路 のフレームバッファのスタート・アドレスを0x1A000000 にしてやってみた。
今回、フレームバッファのスタート・アドレスを変更するにあたって、mt9d111_inf_axi_master (Camera Controlller) は、XPSプロジェクト上のダイアログで変更できるが、bitmap_disp_cntrler_axi_master (Display Controller) はHDLを変更する必要があった。bitmap_disp_cntrler_axi_master を変更して、ダイアログでフレームバッファのスタート・アドレスを変更できるようにした。ダイアログを下の図に示す。
次に、mt9d111_inf_axi_master のダイアログを示す。
両方のC_DISPLAY_START_ADDRESS を0x1A000000 として、インプリメントしてみた。
ところが、SDKにハードウェアをエクスポートして、SDKでビットストリームをダウンロードしてから、ソフトウェアを起動してもどうしても、こちらの回路もディスプレイに表示することができなくなってしまった。だいぶ悩んでいたが、
PlanAhead14.4 からハードウェアをエクスポートする際に、エクスポートするフォルダが違っていた。それで動作しなかった。 PlanAhead14.4 からハードウェアをエクスポートする際には、
1.Fileメニューから Export -> Export Hardware for SDK... を選択する。 2.Export Hardware for SDK ダイアログで、Export to: とWorkspace: に<Local to Project> を選択した状態でOKボタンをくりっくする。
そうすると、PlanAhead だと、ZedBoard_CamDisp_wHDMI.sdk\SDK\SDK_Export フォルダにハードウェアがエクスポートされるはずだ。ところが、今回は、Export Hardware for SDK ダイアログで、<Local to Project> をクリックしてChoose Location... を選択すると、前のLinux用の回路のエクスポート・フォルダが指定されていた。
そのダイアログで、ZedBoard_CamDisp_wHDMI.sdk\SDK\SDK_Export フォルダを選択した。
これでインプリメントしたところ、ディスプレイにカメラ画像が表示できた。
もう一度、ZedBoard Linux回路に修正したbitmap_disp_cntrler_axi_master IPを入れて、もう一度、カメラ画像がが映るかどうか?を確かめてみようと思う。
2013年02月08日 04:36 |
ZedBoard
| トラックバック:0
| コメント:0
”
ZedBoard Linux のフレームバッファにカメラ画像を表示5(BitGen Error) ”の続き。
前回はDigilent社のLinux に自作のカメラ制御回路IPとビットマップ・ディスプレイ・コントローラIPを挿入して、PlanAheadプロジェクトでインプリメントを行ったところ、BitGenでエラーになってしまって解消することが出来なかった。
今回最初にトライしたのは、PlanAheadプロジェクトにChipScope Pro が入っていたのと、-g オプションを入れろと書いてあったのが、PlanAheadのChipScope のチュートリアルだったので、一旦、ChipScope AXI monitor を抜いてやってみたが、現象は同じだった。
次に、ISEプロジェクトを作成して、今までのXPSプロジェクトを入れて、インプリメントを行ったところ成功した。
前回、ビットストリームが生成できないという問題 は、PlanAhead14.4 特有の問題のようだ?
インプリメント後に、SDKにハードウェアをエクスポートして、SDKを立ちあげ、ビットストリームをダウンロードして、カメラのレジスタを設定するソフトウェアを走らせてみたところ、カメラ画像が正常に表示されなかった。
動作しない理由がよくわからない。ChipAcope Proを入れてみるのが良いと思うのだが、とりあえず、
動作しているカメラ回路 で、今回のフレームバッファ・アドレス 0x1A000000 にしてカメラ画像が表示されるかを見てみようと思う。
2013年02月07日 04:18 |
ZedBoard
| トラックバック:0
| コメント:0
2月3日にカメラボード改2がFusionPCBから届いた ので、部品を実装してみた。
下の写真にカメラボード改2と従来のカメラボードを示す。カメラボード改2が左側だ。
反対側の写真を示す。同様にカメラボード改2が左側だ。
ZedBoardに取り付けた時の写真を示す。カメラモジュールとカメラボード改2の間の黒く丸いものはカメラのフタが写ってしまった。
カメラを反対にしたので、mt9d111_inf_axi_master IPの設定を変更する必要がある。XPSプロジェクトでmt9d111_inf_axi_master をダブルクリックして、XPS Core Config ダイアログを立ちあげ、C_UPSIDE_DOWN を TRUE から FALSE に変更する。
これで、論理合成、インプリメント、ビットストリームの生成を行い、SDKにハードウェアをエクスポートしてから、SDKを立ちあげて、コンフィグ後に制御ソフトウェアを走らせたら、カメラ画像を表示できた。
これで、正常にAXIバスのトランザクションはバースト転送できるようになった。DDR3 SDRAMコントローラもWriteデータのアドレスが昇順になったので、バス帯域の圧迫が無くなったはずだ。(DDR3 SDRAMコントローラがとても賢くて、データの順序を並べ替えていたりすると、あまり改善が見込めないかもしれない)
これで正常な状態です。
2013年02月05日 04:24 |
ZedBoard
| トラックバック:0
| コメント:0
前回、
XPSプロジェクトが完成したし、ビットストリームの生成を開始した 。完了したように見え、ビットストリームの生成まで終了したと思っていた。(使用しているバージョンは14.4)
UCFで、processing_system7_0_GPIOが、Pmod JAとPmod JBにも設定されていて、そこが邪魔だったので、processing_system7_0_GPIOを全部コメントアウトした。もう一度、復活するとprocessing_system7_0_GPIOがないというエラーになってしまう。このへんは謎だ?
ビットストリームまで生成できたと思っていたのだが、どうもsystem.bit ファイルが生成されない。PARは通っているんだが。どうにもよくわからないので、PlanAheadプロジェクトを作って、その下にXPSプロジェクトを入れることにした。
PlanAheadプロジェクトを作成して、XPSプロジェクトをインポートし、トップHDLファイルを作成してインプリメントを行った。
BitGenでエラー発生。エラー内容を下に示す。
[Bitgen 342] This design contains pins which have locations (LOC) that are not user-assigned or I/O Standards (IOSTANDARD) that are not user-assigned. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To prevent this error, it is highly suggested to specify all pin locations and I/O standards to avoid potential contention or conflicts and allow proper bitstream creation. To demote this error to a warning and allow bitstream creation with unspecified I/O location or standards, you may apply the following bitgen switch: -g UnconstrainedPins:Allow
Console では、このエラーが出たIOピンは、mt9d111_pclk だそうだ。カメラ回路が表示に成功した時のUCFファイルの内容をそのままコピーしたのだが、何で今度はエラーが出てしまうのだろうか?
早速、Xilinxアンサーをサーチすると、”
7 シリーズ、BitGen (13.2 以降) - 「ERROR:Bitgen:342 - This design contains pins which are not constrained (LOC) to a specific location or have an undefined I/O Standard (IOSTANDARD)」というエラー メッセージが表示される ”
-g UnconstrainedPins:Allow スイッチを設定すれば良いみたいだ。設定することにする。
PlanAheadのFlow Navigator -> Program and Debug -> Bitstream Settings をクリックするとProject Settings -> Bitstream ダイアログが立ち上がる。
More Options に”-g UnconstrainedPins:Allow”を入力する。
PlanAheadのFlow Navigator -> Program and Debug -> Generate Bitstream をクリックして、ビットストリームを再生成する。
やはり、同様のエラーです。
再度、Project Settings -> Bitstream ダイアログを見ると、
”-g UnconstrainedPins:Allow”が入っていません 。
オプションが保存されていないとは?さすがに呆れました。(これだからツールがイマイチと言われちゃうんですね。。。)
(ちなみに、
PlanAhead Tutorial Debugging with ChipScope UG677 (v14.3) October 16, 2013 の11ページの Implementing the Design and Generating the Bitstream に ”3. For all 7 series devices, select Bitstream Settings, select More Options, and type -g UnconstrainedPins:Allow. Click OK.”と書いてあるので、やり方は正しいようです)
しょうがないので、Project Navigator のプロジェクトを作って見ることにします。
2013年02月04日 04:33 |
ZedBoard
| トラックバック:0
| コメント:0
カメラボードはCMOSカメラの上下を反対に取り付けてしまった ので、カメラのデータを受けた時に最上位アドレスから最上位アドレスに向かってデータ転送するようになってしまった。これでは、DDR3 SDRAMでのバースト転送も望めないということで、カメラボードを作りなおして、カメラボード改を作製した。更に、データバスの参照面(GND)がないことから、GND面が参照面として入るようにして作り直した(カメラボード改2)。その2枚のボードが届いた。
2枚ともFusinPCBで作成した。FusionPCBでは10ドルクーポンをくれるということで10ドルクーポンを2枚くれるかな?と思って期待していたが、10ドルクーポン一枚のみだった。その代わりに、カメラボード改2は、E-Testが5枚だけはずだったのが、10枚分やってあった。更に、おまけに葉っぱのアクセサリ基板つけてくれたみたいだ。
クーポンパッケージの表
クーポンパッケージの中身
カメラボード改 表
カメラボード改 裏
カメラボード改2 表
カメラボード改2 裏
とりあえず、カメラボード改2に部品を実装して、動作を見てみようと思う。
2013年02月03日 18:08 |
ZedBoard
| トラックバック:0
| コメント:0
前回、Digilent社のLinuxのHDMIフレームバッファのアドレスがわかったので、そのアドレス (0x1A000000~0x1A7E9000) にカメラ画像を表示しようと思う。
まずは、ZedBoard_OOB_Design に mt9d111_inf_axi_master_v1_00_a と bitmap_disp_cntrler_axi_master_v1_00_a を追加した。mt9d111_inf_axi_master_v1_00_a は、CMOSカメラモジュールMT9D111 用のIPで、bitmap_disp_cntrler_axi_master_v1_00_a は、ピクセルデータをディスプレイに表示するIPだ。それらのスタートアドレスを0x1A000000に変更した。
mt9d111_inf_axi_master_v1_00_a は、IPの設定ダイアログで設定できるようにしてある。下に設定ダイアログを示す。
C_DISPLAY_START_ADDRESS が0x1A000000になっているのがわかると思う。
mt9d111_inf_axi_master_v1_00_a には、そのような仕掛けは用意してなかったので、bitmap_disp_engine.v のparameter を以下のように変更した。
parameter DDR2_SDRAM_START_ADDRESS = 32'h1A00_0000; // DDR2 SDRAMのスタートアドレス(ZedBoardのDDR3 SDRAMアドレスは0x00000000~0x1FFFFFFFなので、中間に設定した) //parameter DDR2_SDRAM_START_ADDRESS = 32'h1000_0000; // DDR2 SDRAMのスタートアドレス(ZedBoardのDDR3 SDRAMアドレスは0x00000000~0x1FFFFFFFなので、中間に設定した)
次に、MT9D111 用のI2C IP、axi_iic_mt9d111 を追加した。更に、axi_gpio_0 を追加した。
XPSのBus_Interface タブの画面を下に示す。
上の図の様に、mt9d111_inf_axi_master_v1_00_a と bitmap_disp_cntrler_axi_master_v1_00_a はAXI_HP1 をイネーブルして、そこに接続した。
次に、Ports タブの外部出力端子の画面を下に示す。
40MHzのSVGAのピクセルクロックを作るために、PS部分のClock Generator のFCLK_CLK3 を40MHzに 設定した。
(2012/02/06:修正) Ports タブの追加したIPのポートの接続を示す。
(2012/02/06:修正) これでDRCが通ったので、ビットストリームの生成を行なっている。
2013年02月01日 05:28 |
ZedBoard
| トラックバック:0
| コメント:0