ZYBO30 (linaro linuxにnfsをインストール）

現在 ZYBOで動かしている linaro-jessie-alip-20160913-31 には nfs 関係のbinaryが含まれていない。 sound系も動作するようなり、music playerも普通に動くので母艦PCのHDDに置いてあるmp3を再生させたくなった。それらを一々ZYBO側にコピーするのは面倒なので nfs を使えるようにして母艦PCのdirectoryをnfs mount出来るようにした。 nfs を使えるようにするためには、rpcbind と nfs-utils をbuild & installする必要がある。 programのsource fileはLFS (linux from scratch)のサイト(http://www.linuxfromscratch.org/blfs/view/7.6/basicnet/nfs-utils.html  )から入手した。 buildは躓くこともなく容易に出来た。

以下はnfs mountした母艦PC上のdirectoryにあるmp3を再生している様子


ZYBOの環境にはffmpegもinstallしてある。
ffmpegで画面を動画grabしfileをnfs越しに母艦PCのHDDに出力させたらどうなるかを見てみた。 encoderはffv1 (FFmpeg video codec #1)を選択した。これ以外のflvやh263やh264等も試しては見たのだが、ffv1が最も画質が良かったのでffv1にした。 grabは以下のような引数で行った。

ffmpeg -f x11grab -i :0.0+640,544 -s vga -r 25 -vcodec ffv1 nfs_fps25.avi

-r XXはframe rateで、秒15枚と秒25枚でgrabしてみた。

・秒15枚

・秒25枚

grab中にmouse cursorを素早く動かして、これがどんな感じで録画されるかも見てみた。fileはそれぞれのframe rateでのdataとなっているが、再生してみるとcursorの移動が断続的になっているので、もしかしたらフレーム落ち等が発生しているかも知れないが、この見方だとよく判らないのでcameraの映像をencodeして見たいと思う。

ということで、OV7670のcamera boardを作った。

OV7670 moduleは夏頃にAmazonで購入しておいた物だが、ようやく使う時が来た。このmoduleはSCCB(I2C)の信号上にプルアップ抵抗が無いので以下のようにして追加している。

ZYBO29 (linaro linuxでsound関係を動かす）

linaroでX windowも動いたので、今度は音関係を動かしてみたくなった。
zybo_base_systemのデザインにはADIのI2S IPが入っており、Digilentのlinuxのソースツリーにもそれ用のドライバのソースが入っている。configやdevice-treeの書き方で色々試行錯誤したが、最終的にpetalinuxのdevicetreeを参考にして成功した。

devicetreeのsound関連部分


xilinx_zynq_defconfigのsound関連部分


linuxのboot log (dmesg)
ZYBO-Sound-Cardが検出されている。


mp3を再生している様子。
今使用しているlinaroのdistributionにはmusic playerとmixerアプリも含まれており、それで問題無く再生・操作出来た。


今度は自作のI2S IPを使えるようにしたいものだ。

便利さは品質を上回るか？

久々にAmazonで買い物をした。購入したのは2.5インチIDE-HDDをUSB経由で使えるようにするUSBハードディスクケースという製品で、2つ購入した。この製品はベア・ボーンキットでHDD自体は付属していない。手持ちに何個か使っていない2.5インチHDDがあるのでHDDはそれを使おうと考えた。

Amazonで検索したところ候補となる商品が幾つか表示されたのだが、あまり安すぎるやつを買って外れだったら嫌だしな−−、と思って一応名前は聞いたことのある国内企業の製品を選んだ。。。が、これが失敗だった。ユーザーレビューを確認すれば良かった。商品が到着したので中身を確認したら、なんと2台共コネクタが実装不良でケーブルが刺さらない。下の写真はその内の１台で、コネクタが写真の水平方向に斜めっている。もう１台は写真の前後方向に斜めって実装されていた。

上記写真の基板側を見ると以下のようにコネクタの片側が浮いていた。

この製品はベア・ボーンキットという性質上、製品内部の基板は否応なくユーザーの目に触れてしまう。基板の他の箇所やもう１台の基板を見てあまりの品質の酷さに愕然としてしまった。

ハンダの仕上がりが手付でハンダ付けしたと伺わせる仕上がりで、半田の量が多すぎたり、逆に少なすぎたり、フラックスが洗浄されていなかったり、半田ボール等の半田クズがこびり付いていたりといった箇所が散見された。

右側のIDEコネクタの上から２ピン目は半田が足りず写真で見える方はピンが浮いているように見える。その左側の３ピンの部品は逆に半田を盛りすぎ。また、その部品付近には半田クズがこびり付いているのが見える。フラックスの洗浄もされていないので白い粉のようになっている。

もう１台の方は、半田が玉になってこびり付いている箇所もあった。


その他の箇所




以下は３端子レギュレータだが、２台で半田の仕上がりが違う。


こちらは水晶振動子の実装、１台の方は部品が浮いている。


その水晶振動子の端子のハンダの仕上がりも、まるでボールのようだ。

あまりに酷いのでユーザーレビューを投稿しようと思って、Amazonのこの商品のレビューを確認したら、コネクタのズレは他のユーザーからも多数指摘されていた。書込がされたのは２０１１年のものもある。・・・という事はメーカーは５年たっても改善や対策もしないでこの商品の販売を続けているということなのだろうか？私が購入できているのだから恐らくそうなんだろう。普通なら販売停止するレベルの品質だと思うのだが。。

Amazonへの返品も考えたのだが、面倒くさいので自分で手直しすることにした。
斜めっているコネクタを付け直し、半田が足りないところはハンダをやり直し、足が長すぎる部品は短くし、こびり付いた半田クズやフラックスは無水エタノールで洗浄・除去した。




エタノールで拭いたらだいぶ綺麗になった。
うわー、新品みたーい。。。って新品を購入したのだが、ジャンク品を購入したような気分だ。ジャンク品でもここまで酷いのはなかなか見た覚えが無いが。


コネクタの位置もばっちり！


で、ようやく使えるようになった。


しかし、ユーザーレビューにあんなに沢山コネクタの不具合が書かれているのにも関わらず、なんの対策もせずに販売を続けているメーカーやAmazonには大いに疑問が残る。どういう神経をしているのか？と。確かにAmazonは便利ではあるが、便利さは商品の品質や性能を上回るとの考えなんだろうか？

ZYBO28 (linaroでicarus verilogとgtkwaveを動かしてみる）

linaroのX Windowの壁紙を以下のような写真にしてみた。


ターミナルの背景を透過モードにしてみた。

ターミナルウィンドウをドラッグして移動するともっさりした感じで移動するが、ターミナル内の文字のスクロール等は速度的にも十分で問題ない。普通のPCを使っているような感覚だ。

ZYBO上のLinuxでX Windowが動くようになったことに気を良くし、Icarus verilogとGtkwaveをインストールして動かしてみたくなった。結果的には動いたのだが、今回インストールしたlinaroのdistributionにはX11,glib,gtk等の開発用ライブラリやヘッダファイル等が含まれておらず、また、linaroのサイトでも公開されていないため、自分で必要なライブラリのコンパイル＆インストールから行わなければならなかった。その作業にえらく時間がかかってしまった。

以前開発したCAN IPのsimulationを実行してみている様子。



ライブラリ等の環境構築に非常に時間がかかってしまったが、これで開発用ライブラリを揃えられたので良しとしよう。ここまでZYBOで作業してきて感じることは、上にも書いたが通常のPCを使うのと何ら変わらないという事。　昔は、PC98やPC-ATの拡張バスにI/O拡張基板を実装して実験系を組んだり制御装置を組み上げたりといったことが行われていた（と思う）が、それと同等のことがZYBOで実現できてしまう。最近はラズベリーパイを少量多品種な開発で使うケースがあるらしいが、このZYBOもそういう案件で活用できるんじゃないか？と感じた。

ZYBO27 (Linux + simple framebuffer でX Windowを動かすまで 2)

linaroのreleases storage serverにはubuntuの他にdebianのバイナリも置いてある。

そこで、debianのバイナリだとどうなるかダウンロードして試してみた。ダウンロードしたのはalip-armhfのlatestのバイナリだ。
https://releases.linaro.org/debian/images/alip-armhf/latest/
linaro-jessie-alip-20160913-31.tar.gz

SDカードに展開すると時間がかかるので、ここからデバイスツリーのbootargsを変更してROOTFSとしてHDDを使うことにした。


起動後に確認すると、このバイナリではwindow managerにlightdmが使われていた。

HDMI出力を確認したら正常に表示されていた。
ネットワークへの接続も問題ない。以下は付属のブラウザでこのブログを表示した様子だ。
マウスでウィンドウをドラッグして移動させてみたが動作としては重かった。

ZYBO26 (Linux + simple framebuffer でX Windowを動かすまで)

ZYBOでLinuxを動かし、その上で X Windowを立ち上げ X アプリを動作させることが出来た。
以下はgnome-terminalとgnome-system-monitorを起動しgnome-screenshotで撮ったscreenshotだ。


これまでDFT IPのスペクトル表示等、ZYBOのHDMIを使うデザインを作成してきたが、これらはフレームバッファを使わずデータをリアルタイムに波形化してビデオ出力していた。　しかし今後カメラ等を接続して映像を表示したり、波形にグリッドや文字等も重ねて表示したりもしたいので、フレームバッファ方式のディスプレイコントローラを作成しようと思う。が、その前にZYBO（で動くLinux）でビットマップを表示する方法について知る必要がある。　ということで、X Windowを動かせるかやってみた。

ZYBOでLinuxを動かすということについては、以前 DigilentのEmbedded Linux Hands-on Tutorial for the ZYBOで学習した（ZYBO 7 (DigilentのEmbedded Linux Hands-on Tutorial for the ZYBOを試してみる））が、この時のユーザーランド側のバイナリはramdiskに入る程の規模のものでX Window関連のバイナリは含まれていない。 　ネットを検索したらEmbedded Linux Hands-on Tutorial for the ZYBOとほぼ同じ内容だが、ユーザーランドのバイナリとしてLinaroを使うTutorialのサイトが見つかった。（ZYBO Zync-7000 Development Board Work Booting Linux on the ZYBO）  そこで、今回はそのサイトの記述を参考にしてユーザーランドのバイナリとしてLinaroを使うことにした。

・ framebufferについて、
LinuxのmenuconfigでLinuxがサポートしているframebuffer deviceを調べたところ、simple framebufferというのがあることが判り、簡単そうだったのでこれを試してみることにした。この方式の場合、framebufferのアドレスとサイズ、画素数等の情報をデバイスツリーに記述するだけで良いらしい。

ZynqのPL側にはframebufferとして使えるだけのメモリは無いので、SDRAMの一部をframebufferとして使う必要がある。また、デバイスツリーにアドレス等を記述するのでデバイスドライバ内部で領域をアロケートしてそれをframebufferとして使うといった方法は、多分使えない。 カーネル起動時には既にアドレス等は決定している必要がある。そこで、ZYBOのSDRAMサイズは512MBだが、その内の496MBをLinux用とし残りの16MB（0x1F000000〜0x1FFFFFFF）をframebuffer用として使うことにした。そのため、u-boot-Digilent-Dev/include/configs/zynq_zybo.h内のSDRAM SIZEの定義と、デバイスツリーソース（Linux-Digilent-Dev/arch/arm/boot/dts/zynq-zybo.dts）のbootargsの部分を以下のように記述した。



また、simple framebufferに関するデバイスツリーソースの記述は以下のようにした。


・PS部の変更
今回使用するZynqのデザインはDigilentのzybo_base_systemを使うが、USB HOST機能関連で１箇所Zynqの設定を変更する必要がある。 ZYBOではUSB HOST機能用にUSB OTG LSIのUSB3320というデバイスを使っており、そのデバイスへのリセットはZynqのMIO46に接続されていて、GPIO経由で制御してやる必要があるのだが、zybo_base_systemではその設定がされていない。

USB HOST機能はframbufferでビットマップ表示をする事とは直接の関係は無いが、コンソール用のキーボードやマウスを使用するためにはUSB HOST機能が必要だ。

以下のようにGPIOの設定を変更した。
変更前

変更後


・ デバイスドライバの修正
このリセット制御については、デバイスドライバの修正も必要なようだ。このサイト（ZYBOのUSB修正）が参考になった。


・Display controllerとVDMAの起動
simple framebuffer用のdevice driverは下記のドキュメントにあるとおり、Display controllerやVDMA等のハードウェアの制御は行わず、それは起動時に既にセットアップが完了し動作しているという前提になっているので、セットアップはシステムの起動時に自分でやる必要がある。

今回は、FSBLのfsbl_hook.cのFsblHookBeforeHandoff 関数内でそれを行うことにした。
display controllerを設定するコードはzynq_base_systemのbase_demoの関連部分を流用した。

今回の実験では画面サイズは1024x768にすることにしたのだが、base_demoのvga_modes.hには1024x768用のパラメータが定義されていなかったため以下のように追加した。

また、display_ctl.cのDisplayInitialize関数のVMODE設定部も以下のように変更した。


・カーネルビルド
simple framebufferを使うためには、arch/arm/configs/にあるxilinx_zynq_defconfig.hにCONFIG_FB_SIMPLE=y という記述を追加する必要がある。

追加したら、make xilinx_zynq_defconfig し、次にカーネルをビルドしてuImageを作成する。

ビルドの作業は先述のサイト（ZYBO Zync-7000 Development Board Work Booting Linux on the ZYBO）のTutorialに従って行うが、その中で変更が必要な部分のみを上述した。また、ユーザーランドに使うLinaroのバイナリは以下を使用した。
https://releases.linaro.org/ubuntu/images/gnome/latest/
linaro-vivid-gnome-20151215-714.tar.gz


ここまででバイナリは準備できたので、micro sdカードに書いてZYBOにセットし起動した。

起動時のログ
simple framebufferが認識されている。

/dev/下にfb0も作られている。

メモリサイズも設定通りの496MBとなっている。

HDMI出力を見てみたら、真っ黒でたま〜にlogin画面が表示される。何か変だ。

この時点ではOSのrunlevelは5で、psコマンドで動作しているプロセスを確認したら、Xの他にgdm等も動作していた。

そこで、runlevelを3にしてX関連のプログラムを全て止めてみた。

HDMI出力を見たらlogin画面が安定して表示されるようになっていた。

そこで今度は手動でXのみを起動し、次にgnome-terminalを起動してみたところ成功した。

gdmを起動すると以下のようなエラーが表示されHDMI出力は症状が再現したので、gdmに何かあるようだ。

gdmを動かさない状態ではgnome-terminalやgnome-calculator等のアプリは正常に動作した。USB HOSTに接続したキーボードやマウス等も機能している。

動かしている様子
キーボードとマウスはUSB-HUBを介して接続している。

冒頭のスクリーンショットの再掲だが、gnome-screenshotでスクリーンショットも撮れた。

ということで、simple framebufferを使いX Windowを動かすことは出来た。
gdmは旨く動かなかったがdisplay managerにlightdm等を使うと動くかも知れないので今度試してみようと思う。