ZYNQ UltraScale+ SOMモジュールを入荷

TrenzElectronic社のZYNQ UltraScale+ SOMモジュールを入荷しました。

XCZU9EG-1FFVC900Cを搭載し、メモリが4GBに増量された更新版です。このFPGA、一体どのくらいの規模なんでしょう、想像がつきません。

https://www.trenz.jp/archives/2441/

パソコンの筐体に入って、電源ONですぐに使えるスタータキットもあります。

ZYNQ&Trenz製品セミナーを開催します

特電のアルバイトさんが、ZYNQのTE0720を拡張したボードで、HDMI表示ができるようにして、デスクトップが表示できるようにしてくれました。

こんな感じで、ZYNQにマウス、キーボード、HDMIをつなぐことができて、しかもUbuntu14が動いてWiFiがつながって、野良のZYNQがパソコンのようになりました。

まるでFPGA付きのRasPiです。

PetaLinuxもYoctoも使わずに、ZYNQのLinuxをプレーンなソースからビルドしています。

特殊電子回路ではこの1か月くらいの間に、ZYNQのLinuxをビルドしては壊し、あらゆるオプションを試して、USBやWiFi、HDMIなどを使えるようにする基本的な方法を身に着けました。

ZedやZybo、Pynqのようにすべて出来上がった環境を使うのではなく、生のZYNQに自分で環境をセットアップしていくやり方がわかりました。

このノウハウをいろいろな人に伝えたいと思い、セミナーを開催することにしました。

12月13日(水)、Trenz社ZYNQボード活用セミナーを開催します。ZynqBerryやGigaZeeをターゲットに、拡張ボード設計方法、U-BootおよびLinuxのカーネルの構築、USB、WiFi、そしてHDMIへのデスクトップ画像を出力する方法などを、手を動かしながら一緒に実践します。

セミナー内容の詳細

• GigaZee(TE0720)のハードウェア
• ZynqBerry(TE0726)のハードウェア
• スクリプトベースのVivado活用法
• FSBLへのパッチ
• U-Bootの構築
• 何もないところからのXILINX Linux Kernelの構築
• デバイスツリーの書き方と各項目の意味
• USBとWiFiを開放する
• Ubuntu Linuxでリッチな環境
• HDMI出力とデスクトップ
• 独自IPのためのドライバ作成

セミナーのメリット

このセミナーを受講すると、ZYNQ Linuxのしくみが理解でき、PetaやYoctoを使わずにLinuxを構築する方法が身に付きます。Trenz社の製品を使用する場合だけではなく自作のZYNQボードにも応用でき、ZYNQでデスクトップPC並みのリッチな環境を実現できるようになります。

場所、参加費用など

参加費は無料。場所は秋葉原の電気街口です。

日時は12月13日(水) 14:00～17:00の予定です。

Trenz製ボード（ZynqBerryまたはGigaZee）をお持ちでない方も参加いただけますが、持っていたほうが楽しめます。

先着10名様限定ですので、お早めにお申し込みください。

お申込みは、こくちーずのページで受け付けております。

http://kokucheese.com/event/index/498206/

さよならトラ技

突然ですが、主に2000年～2010年の10年分くらいのトラ技とInterfaceとDesign Wave Magazineを捨てることにしました。

明日の廃品回収に出します。増えすぎちゃって事務所の床が抜けそうなのと、事務所をすっきりさせたいなどの理由です。とても名残惜しいのですが、仕方がありません。

2000年以降のトラ技はCD-ROM化されているのでいつでも読めるので、比較的容易に決断できましたが、私が高校生大学生だったときに授業そっちのけで読みふけっていた1990年代のは、やはり捨てられませんでした。内容が濃すぎて、得るものが多すぎ、いまだに消化できていないものも多くあります。

2000年台のInterafaceも熱かったですね。いろんなマイコンが出てきて、付録基板とか、ブートコードとか低レベルなところに熱中していた。ここ数年のIF詩はRasPiばかりになってしまったのも、RasPiが強すぎるからでしょう。各社マイコンボードでやってたことが全部できてしまう。

DesignWaveもすごい雑誌でした。「お前ら、理解できるものなら理解してみろ」という記事ばかりで、読者で居続けることが試される雑誌でした。開く前に深呼吸してから戦うつもりで読んだ覚えがあります。私が執筆した原稿が何のチェックもなくそのまま載ったので驚きました。

これが残った雑誌たちです。これからもよろしく

TrenzElectronics社のEDDPモータコントロールキットを入荷

TrenzElectronics社のEDDPモータコントロールキットを入荷しました！

お客様から依頼されて仕入れたものなので、何をする装置なのかはよくわかっていないのですが、

付属品にArtyとモータとACアダプタとSDカードがついています。

Arty-Z7とつないでモータをコントロールする装置のようです。

出荷しようと思って検品していたら、なんと、ACアダプタに＜PSE＞マークがない！

PSEマークには、〇囲みのPSEと、菱型のPSEマークがありますが、ACアダプタに必要なのは菱型のようです。しかし、このACアダプタにはどちらもない。

PSEなんて所詮絶縁検査しかしないから安全性には全く関係ないと思うけど、悪法も法なり。従わざるを得ません。輸入業者も楽じゃないことがわかりました。

この製品を日曜日中に出荷して、月曜日にお客様のところに届けたかったけど、ちょっと無理そうです。秋月に行ってPSE付のACアダプタを買ってきます。

秋葉原にお店を出したい！

突然ですが、2018年には秋葉原にリアル店舗を出したいと思います。

といっても、私がいつもお店にいるわけではなく、誰か信頼できる人に任せたい。FPGAとかそういう類のものなら、何を仕入れても、何を売っても構いません。

コンセプトとしては、特電のFPGAボードや、Trenz社のFPGAボードといった工業用のFPGA製品がずらっと並んだお店。自社のだけではなく、いろんなメーカーのFPGAボードを並べたい。

そこに、FPGAがわかる店長と店員がいて、お客様が気軽に問い合わせることができる。もちろんサポートは有料だけど、質問したら答えてくれる。そんなお店。

「古き良き秋葉原を取り戻す」っていうとラジオと電子工作とパソコンになってしまうから、あえてそうは言わない。

「新しい電気の秋葉原」を目指す。

場所は「千石秋月通り」か「駅ナカ」以外にはありえないでしょう。3331だと遠すぎます。

鈴商の跡地か、千石の移転前の跡地か、そのあたりの小さなテナントの1階を気長に探します。

駅ナカにお店を出せるなら総武線の踊り場も出せるなら検討したいですね。

ZYNQでLinuxカーネルからビルドして、WLAN接続に成功

ZYNQ XC7Z020で、Linuxをカーネルからビルドして、WLAN接続に成功しました。

アルバイトさんがやってくれました。

使用したWiFiはUSB接続のもので、BuffaloのWLI-UC-GNM2Sです。

このとおり、ちゃんとwlan0が見えるようになりました。

彼曰く、カーネルに入れるモジュールが足りなかったとのことです。必要なモジュールを入れて再度ビルドしたらうまくいくようになりました。

速度は28.9Mb/sと表示されています。ただ、使っていると20分ほどで触れないほど熱くなるそうで、無線接続が切れてしまうそうです。

次はフレームバッファを導入してHDMIにデスクトップ画面を表示させるのが目標です。

生のLinuxからビルドしてここまでできたので、もうPetaLinuxは不要ですね。

ZYNQがUSBを認識した

ZYNQでUSBを使う方法を調べています。TrenzElectronic製のTE0720を使っているので、ボード上にUSB3320というUSB OTGコントローラが乗っています。

そして、拡張ボード上にはLAN9514が乗っています。

普通に起動すると、こんな感じ↓です。

USBのデバイスドライバは組み込まれますが、LAN3320が認識されたとは出てきません。

そこで、ドライバのソースにprintkをいろいろ仕掛けて、ULPIドライバが組み込まれたかどうかを見てみたのですが・・やはりドライバが組み込まれてはいなかったようです。

どうやら、デバイスツリーの書き方が足りなかったようで、ulpiドライバを組み込むように追記したら、うまくいきました。

Found SMSC USB3320 ULPI transceiver.

と表示されています。

USB3320が認識されると↓のように、LAN9514までは認識されます。

ただ、LAN9514までは見えているものの、その先にあるUSBメモリや無線LANドングルは見えていません。

LAN9514のネットワークPHYとしての機能は、smsc95xxというドライバとして組み込まれたようです。

そのため、TE0720にLAN9514をつないだシステムでは、eth0とeth1の2つのネットワークが見えるようになりました。

apt-get updateとかも動くようになったので、有線LANでの通信はできているようです。

それから、LAN9514の先につないたUSBが認識しなかったのは、基板上のUSB電流スイッチのGNDがつながっていなかったためでした。 これをつないだら、ちゃんと無線LANドングルが認識されました。↓

これで、USB接続の無線LANまでは認識できたのですが、どうしてもwlan0が有効になりません。

まだ、何か足りないことがあるのでしょう。

ET2017ご来場ありがとうございました

特殊電子回路はET2017に出展しました。

今年の出展は、入り口に近いためもあったのでしょうか、初日から大盛況でした。

おそらく200～300人くらいは来ていただけたのではないでしょうか？

ずっと、こんな感じでした↓

出展していたものは、Cosmo-Z Miniという小型のADC/DAC装置と、Cosmo-Zのデモなのですが、ノベルティに選んだ光るハンドスピナーが大人気だったというのも大きかったと思います。

ハンドスピナーを配っているブースは他にもあったと思いますが、光るハンドスピナーは特電だけだったと思います。

2日目以降は電子部品ガチャも復活し、大当たりを出したお客様には「ZynqBerry」「ArduZynq」「特電Spartan-6ボード」などのFPGAボードを景品としてお配りしました。

今回は開催1か月前くらいの本当に直前での出展決定だったため、ブースの「向き」は入り口にもメインステージにも向いていない、あまり良くない場所しか取れなかったのですが、かつてないほどの盛況でした。

それも、今まで特電のことを知っていたという方だけではなく、展示会場でたまたま見かけてきてくださったというお客様が多かったのが印象的です。

頭がてんぱって動かなくなっていた私の代わりに、ブースの設計から出展物の選定、そしてノウハウを調べてくれたスタッフさんに圧倒的感謝です。

ET2017 1日目

ET2017が始まりました！

特電のブースは「FPGA×高速ADC=ワイヤレス？」と題して、ZYNQ搭載のWifi対応ADC/DAC装置の「Cosmo-Z」Miniを展示しています。

これが、Cosmo-Z Miniです。

また、ノベルティの「光るハンドスピナー」もご好評をいただいているようです。

新たなコラボレーションを期待させるような出会いもありました。

今年は入り口に近いこともあってか、12時前にすでに10人以上に達するなど、例年よりも多いペースでお客様にご来場いただいております。

皆様のご来場をお待ちしております。

U-BootがUSBに対応していた

U-BootがUSBに対応していたようです。

Trenz製のTE0720用にビルドしたU-Bootで、usb startコマンドとusb infoコマンドでUSBの情報が見えることを確認しました。

ただし、TE0720はボード上のCPLDがUSB PHYのリセットを行っているようで、FSBLにパッチを当ててI2CでCPLDと通信して、PHYのリセットを解除しなければならないようです。

時間がないので、とりあえず画像とログだけ記録します。

起動時のログ

Last login: Thu Jan  1 00:00:15 UTC 1970 on tty1

 Device IDCODE ->        23727093
 Revision ->     2
 Device ->       7 (7z020)

SoM: TE0720-01-2E  F SC REV:02
MAC: 00 ** ** ** ** **


U-Boot 2017.01-00013-g3290b10-dirty (Nov 14 2017 - 23:06:05 +0900)

Model: Zynq Cosmo-Z Mini Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e0100000: 0 (SD)
SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0000000
Out:   serial@e0000000
Err:   serial@e0000000
Model: Zynq Cosmo-Z Mini Development Board
Board: Xilinx Zynq
Net:   ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
eth0: ethernet@e000b000
reading uEnv.txt
115 bytes read in 37 ms (2.9 KiB/s)
Importing environment from SD ...
Hit any key to stop autoboot:  0
Zynq> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Zynq> usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0x9514 Version 2.0
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Vendor specific,  USB Revision 2.0
 - Class: Vendor specific
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0xec00 Version 2.0
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 3
     - Class Vendor specific
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512
     - Endpoint 3 In Interrupt MaxPacket 16 Interval 4ms

Zynq>

なお、MITOUJTAGのバウンダリスキャンで見てみると、U-Bootでusb startとやったときにはMIO35番付近が動き出してUSBのPHYにアクセスしていたのですが、Linuxが起動し始めるとMIOが停止してしまいます。

まだ何かやらねばならないことがあるのでしょう。

ET/IoT2017に出展します！

いまさらですが、特殊電子回路は、展示会ET/IoT2017に出展します。

日時　2017年11月15日(水)～17日(金)

開催時間　10:00～17:00

ブース場所 A-15 特殊電子回路株式会社

詳しくは下記のページをご覧ください。

http://www.tokudenkairo.co.jp/et2017.html

今年はETだけではなくIoTにも絡めていきたいと思い、IoT2017のほうに申し込んでしまいました。そのため、いつもの左側のほうではなく、入り口に近い右側のほうにいます。

今年はIoTに絡め、「高速ADCもIoTの時代に突入」をテーマに、ワイヤレス高速ADCを出展します。

これはオシロのような単純なデジタイザではなく、高速ADCのデータをZYNQで処理して、無線で飛ばせるようにデータ量を削減したり有意なデータを抽出して送信する装置です。

また、電子回路無料コンサルティングを実施します 。

特電ってボードを売っていたり、JTAGツールを売っていたり、研究機関向けにカスタム装置を作っていたり・・いったい何の会社なのかな、って考えることがよくあるのです。

自分で言うのもなんですが、特電のボードは他社のFPGAボードと比べても、分かりやすくて使い勝手がいい。デバイスドライバやサンプルアプリもちゃんとついている。これならFPGAに詳しくない人でも最新のデバイスが使えるようになるはずです。

あと、物理学の実験にFPGAを使いたいという先生方の話を聴いて、それをFPGAの回路に落とし込む。そういうことをここ数年やってきたわけです。

それから、お客様が独自に作ったFPGAボードが動かないから、ということで特電を頼りにしてきてくれることもあります。

結局のところ「お客様がFPGAを使って何かすごい計測や実験をすることをサポートしている」わけです。

それなら、特電の社会的使命は、最先端の何かのため、電子回路を使いやすくする、ということなんじゃないでしょうか。

そう思ったので、ET2017の会場で無料コンサルティングを行うことにしました。

• FPGAの基板を作ったけどうまく動かない。デバッグしてほしい。
• 想定していた性能が出ない。原因を探ってほしい。
• 新製品を考えたけど、どうやって作ればいい？
• FPGAで起業したい！うまくいくか一緒に考えてほしい！
• うちの会社って、業界の平均より儲かっているか知りたい！

回路設計の疑問から中小企業の経営まで、どのようなご相談でもなひたふが皆様のお悩みを解決します！

なお、コンサルティングは通常は有料ですが、ET/IoTの会場に限り、15分間無料、ただし先着10名様でお答えさせていただきます。

詳しくは下記のページをご覧ください。

http://www.tokudenkairo.co.jp/et2017.html

会場で、皆様にお会いできることを楽しみにしています。

ZYNQ搭載ADC/DAC基板が届いた

本日、ZYNQ(可能な)ADC/DAC基板と、タカチのカスタム加工ケースが届きました。

さっそく組み立ててみると、あれ！？、穴がひっかかって入らない、という事態になりました。

おそらくSMAの同軸コネクタや、USBなどのコネクタの穴の大きさを公差0で設計したのではないかと思います。月曜日に会社にいったらヤスリで削ってみます。

基板にもいくつか問題がありました。まず、電源回路がなぜか動かないのです。1.8Vと2.5Vを出すはずなのに、何も出てきません。なぜなんでしょう。

そして、このTE0720というモジュールはVIOがすべてそろっていないとTE0720上のCPLDがFPGAにリセットをかけ続けるようで、FPGAがリセットされたままになってしまいました。

とりえあえず、すべてのVIOに何らかの電圧を与えることで、FPGAは起動しました。

それから、回路設計をちょっと間違えていて、FSBLの出力はUART1、つまりMIO14とMIO15に出てくるようなのですが、UARTの端子をFPGAのPLにつないでいたので、EMIOを使ってUART1をEMIOに出すことで何とか回避しました。

しかし、TE0720を使っていて困るのは、このモジュール上のCPLDが何をやっているかわからないことと、ほとんどの部品がBGAかつ多層基板なのでオシロで信号が見れないことです。

この拡張ボードを作ったことで、MITOUJTAGからTE0720が見えるようになったことで、デバッグの効率が飛躍的に高まりました。

MITOUJTAGを使えば、FSBLやU-BOOTが起動中であっても、UARTのポートが間違っていても、端子の波形が見えるので何をやっているかがだいたいわかります。

下の図は、FSBLとU-Bootが起動してLinuxのカーネルを読み込んでいる際のSDカードのようすです。

次の図は、同じ期間のDDR3メモリのようすです。SDカードから読み込んでDDR3メモリに展開しているのがわかります。

なお、LinuxのDeviceTreeでギガビットイーサを使わないようにしたら、Ether用のクロックが途中で止まることが確認できました。

このLinuxでは、QSPIを使いたいのにどうしてか動いてくれません。バウンダリスキャンで波形を見てみると、途中から線が赤くなって、何らかの状態変化があって止まっていることがわかります。

このように、BGAだらけの基板でも、JTAGを使えば、SDカードを読みにいっているな、とか、DDR3メモリにイメージを展開しているな、とか、QSPIメモリを読んでいるとか、USBのチップにアクセスしている、とかそういうのが見えるようになります。

さんざん苦労して、なんとかFSBLとU-Boot、それからLinuxのカーネル起動まではできるようになりました。

U-BootとLinuxが起動したときのメッセージを忘れないように書いておきます。

U-Boot 2017.01-00013-g3290b10-dirty (Nov 12 2017 - 16:33:25 +0900)

Model: Zynq Cosmo-Z Mini Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB
MMC:   sdhci@e0100000: 0 (SD)
SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Zynq Cosmo-Z Mini Development Board
Board: Xilinx Zynq
Net:   ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0
Device: sdhci@e0100000
Manufacturer ID: 3
OEM: 5054
Name: SL16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.5 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading uEnv.txt
** Unable to read file uEnv.txt **
Copying Linux from SD to RAM...
reading uImage
3777296 bytes read in 231 ms (15.6 MiB/s)
reading devicetree.dtb
9351 bytes read in 18 ms (506.8 KiB/s)
reading uramdisk.image.gz
5310062 bytes read in 312 ms (16.2 MiB/s)
## Booting kernel from Legacy Image at 02080000 ...
   Image Name:   Linux-4.9.0-xilinx-00050-gbd8f87
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3777232 Bytes = 3.6 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 04000000 ...
   Image Name:
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5309998 Bytes = 5.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Kernel Image ... OK
   Loading Ramdisk to 1faef000, end 1ffff62e ... OK
   Loading Device Tree to 1fae9000, end 1faee486 ... OK
Unable to update property /amba/ethernet@e000b000:mac-address, err=FDT_ERR_NOTFOUND
Unable to update property /amba/ethernet@e000b000:local-mac-address, err=FDT_ERR_NOTFOUND

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.9.0-xilinx-00050-gbd8f87c (naitou@ubuntu) (gcc version 4.9.2 (Sourcery CodeBench Lite 2015.05-17) ) #3 SMP PREEMPT Sun Nov 12 17:54:19 JST 2017
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: xlnx,zynq-7000
cma: Reserved 16 MiB at 0x3f000000
Memory policy: Data cache writealloc
percpu: Embedded 14 pages/cpu @ef7d4000 s25984 r8192 d23168 u57344
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260608
Kernel command line: console=ttyPS1,115200 root=/dev/ram rw earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1007684K/1048576K available (6144K kernel code, 200K rwdata, 1460K rodata, 1024K init, 230K bss, 24508K reserved, 16384K cma-reserved, 245760K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0700000   (7136 kB)
      .init : 0xc0900000 - 0xc0a00000   (1024 kB)
      .data : 0xc0a00000 - 0xc0a32140   ( 201 kB)
       .bss : 0xc0a32140 - 0xc0a6bbdc   ( 231 kB)
Preemptible hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 32.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
efuse mapped to f0800000
slcr mapped to f0802000
L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
L2C-310 erratum 769419 enabled
L2C-310 enabling early BRESP for Cortex-A9
L2C-310 full line of zeros enabled for Cortex-A9
L2C-310 ID prefetch enabled, offset 1 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 8 ways, 512 kB
L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
zynq_clock_init: clkc starts at f0802100
Zynq clock init
sched_clock: 64 bits at 333MHz, resolution 3ns, wraps every 4398046511103ns
clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x4ce07af025, max_idle_ns: 440795209040 ns
Switching to timer-based delay loop, resolution 3ns
clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 537538477 ns
timer #0 at f080a000, irq=17
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 666.66 BogoMIPS (lpj=3333333)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x100000 - 0x100058
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated (1333.33 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB @ 0xf0880000
zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
e0000000.serial: ttyPS0 at MMIO 0xe0000000 (irq = 27, base_baud = 6249999) is a xuartps
e0001000.serial: ttyPS1 at MMIO 0xe0001000 (irq = 28, base_baud = 6249999) is a xuartps
console [ttyPS1] enabled
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
media: Linux media interface: v0.10
Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti 

PTP clock support registered
EDAC MC: Ver: 3.0.0
FPGA manager framework
fpga-region fpga-full: FPGA Region probed
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 5188K (dfaef000 - e0000000)
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
futex hash table entries: 512 (order: 3, 32768 bytes)
workingset: timestamp_bits=30 max_order=18 bucket_order=0
jffs2: version 2.2. (NAND) (SUMMARY)  c 2001-2006 Red Hat, Inc.
bounce: pool size: 64 pages
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
dma-pl330 f8003000.dmac: Loaded driver for PL330 DMAC-241330
dma-pl330 f8003000.dmac:        DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[drm] Initialized
brd: module loaded
loop: module loaded
libphy: Fixed MDIO Bus: probed
CAN device driver interface
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
usbcore: registered new interface driver cdc_wdm
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 23
cdns-i2c e0005000.i2c: 400 kHz mmio e0005000 irq 24
cdns-wdt f8005000.watchdog: Xilinx Watchdog Timer at f098d000 with timeout 10s
EDAC MC: ECC not enabled
Xilinx Zynq CpuIdle Driver started
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on e0100000.sdhci [e0100000.sdhci] using ADMA
mmc0: new high speed SDHC card at address 0007
mmc1: SDHCI controller on e0101000.sdhci [e0101000.sdhci] using ADMA
ledtrig-cpu: registered to indicate activity on CPUs
mmcblk0: mmc0:0007 SL16G 14.5 GiB
 mmcblk0: p1 p2
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
fpga_manager fpga0: Xilinx Zynq FPGA Manager registered
NET: Registered protocol family 10
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20161123 t)
can: netlink gateway (rev 20130117) max_hops=1
Registering SWP/SWPB emulation handler
hctosys: unable to open rtc device (rtc0)
of_cfs_init
of_cfs_init: OK
ALSA device list:
  No soundcards found.
RAMDISK: gzip image found at block 0
mmc1: new high speed MMC card at address 0001
mmcblk1: mmc1:0001 MMC04G 3.52 GiB
mmcblk1boot0: mmc1:0001 MMC04G partition 1 16.0 MiB
mmcblk1boot1: mmc1:0001 MMC04G partition 2 16.0 MiB
mmcblk1rpmb: mmc1:0001 MMC04G partition 3 128 KiB
EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ram0): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 1024K (c0900000 - c0a00000)
Starting rcS...
++ Mounting filesystem
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
++ Setting up mdev
++ Starting telnet daemon
++ Starting http daemon
++ Starting ftp daemon
++ Starting ssh daemon
random: sshd: uninitialized urandom read (32 bytes read)
rcS Complete

なお、このrcS Completeで止まってしまうので、まだ何か足りないところがあるのでしょう。

PythonのXMLRPCが遅くなった原因

ZYNQ+ADC+FPGAボード「Cosmo-Z」のUbuntu LinuxでPythonが動くようにして、ホストPCから操作する実験を行ってしました。

久しぶりにホストPCからリモートプロシージャコールでアクセスしてみたところ、すごく遅くて我慢できないほどでした。

作ったコードはこんな感じです。

# encoding:utf-8
# Cosmo-ZをTCP/IPでリモート操作するよ！
　
import sys
　
server="cosmoz3"
import xmlrpc.client as xmlrpc_client# XMP-RPCを使用する

# サーバに接続
print "Connect serer.."
cosmoz = xmlrpc_client.ServerProxy('http://' + server + ':21068')
　
# Cosmo-Zの操作
cosmoz.open() # Cosmo-Zをオープンする
cosmoz.adc_reset() # ADCをリセット
　
print "xadc=" + str(cosmoz.xadc()) # FPGAの電圧と温度を表示
　
adc_vrange = cosmoz.adc_vrange() # ADCの電圧範囲の取得
adc_info = cosmoz.adc_info() # ADCの情報を取得
maxch = cosmoz.maxch() # ADCのチャネル数を取得
cosmoz.adc_setfreq(freq) # サンプリング周波数の設定
　
cosmoz.trig_set(8,"fall",2000) # トリガの設定
cosmoz.trig_ortrig("or") # グローバルトリガの設定
・・・

実際にやってみると、cosmoz.***()の関数を1つ呼ぶたびに1秒くらいの時間がかかります。

前はこんなに遅くなかったはずなのですが、いったい、どこに間違いがあるのでしょうか？

WireSharkでパケットを取ってみました。

ホストPC→Cosmo-Zへリクエストを出して、Cosmo-Z→ホストPCへレスポンスを返すという図式なのですが、Cosmo-Z上で動いているPythonの反応は数ms～数十msで、それほど遅くはありませんでした。

パケットをよく見てみると、192.168.2.9(Cosmo-Z)が192.168.2.87(ホストPC)へ応答を返したあと、ホストPCが次のパケットを出すまでに300msくらいかかっています。（↑の図の赤い線の部分）

このとき、ホストPCはマルチキャストのアドレスにLLMNRというのを4回投げています。

LLMNRというのは、DNSやNetBIOS over TCPに変わる新しい名前解決の仕組みのようで、比較的最近のWindowsで導入されているようです。LLMNRのリクエストを出したのに、応答がないからホストPCがそこで待ってしまっているということのようです。

ためしに、Pythonのスクリプトの

server="cosmoz3"

というのを

server="192.168.2.9"

に変えてみたところ、LLMNRが出なくなって見違えるように速くなりました。

↑IPアドレスを直接指定したら、確かにLLMNRが出なくなりました。

ホスト名を利用した通信でLLMNRを出さないようにする方法は、まだわかりません。ホスト名.localでもLLMNRは出てしまいます。ホスト名を使うと遅くなるというのは、ちょっと面倒ですね。

あと、以前実験したときは、ZYNQ Linuxの上でavahi-daemonという名前解決が動いていて、これがTCP/IPの通信をするたびにマルチキャストのパケットを出すので、遅くなってしました。それが下の図です。

 

この実験を行ったときに、クライアント(ZYNQ Linux)の上ではavahi-daemonを止めるようにしたのですが、それが今回遅くなった原因かと思ったのですが、Avahi(mDNS)とLLMNRは違うプロトコルなので、そうではないようです。

結局のところ、

• クライアント(ZYNQ Linux)ではAvahiを止める
• ホスト(Windows)ではLLMNRが出ないように名前を使わない

としたところスピードは上がったのですが、何か間違っている気がします。

ZYNQで計測した波形をXML-RPCを通じてPythonで取得してnumpyでグラフにするということが結構な快適さでできるようになりました。

あとは、最新の名前解決を勉強して両方ともスマートに解決できる方法を探したいと思います。

■追記

• Windowsがavahiに応答するようにするには、Bonjourをインストールすればよい

光るLチカハンドスピナー、できました

このハンドスピナー、一見すると、何の変哲もないのですが、

よくみるとスイッチがついています。

このスイッチをONにすると・・

なんと！光ります。

LED内蔵で、チカチカ光るのです。

こんなハンドスピナーを200個くらい作りました。

今、中国から輸送されているようなのですが、通関などで間に合うようであれば、今月15日から行われる展示会ET/IoT2017の特殊電子回路ブース「A-15」でノベルティとして配布する予定です。

ET/IoT2017では、特殊電子回路ブースへどうぞお越しください。

GigaZeeを使った拡張基板を出図

今年のET/IoT2017に出展するための高速ADC/DAC基板は、3週間程度で素早く設計しなければならなかったので、Trenz Electronics社の既存のモジュール「Gigazee」を使いました。

GigaZeeというのは、ZYNQの0720を搭載したこのようなモジュールで、1GBのDDR3 SDRAMのほか様々なコンポーネントを搭載しています。

この基板はSAMTEC社の高密度コネクタ「LSHM-150-04.0-L-DV-A-S-K-TR」と「LSHM-130-04.0-L-DV-A-S-K-TR」で拡張するようになっています。

出来上がった基板のイメージ図を載せます。

中央の部分にGigaZeeを載せるのですが、苦労したのは「LSHM-150-04.0-L-DV-A-S-K-TR」と「LSHM-130-04.0-L-DV-A-S-K-TR」のFootPrintと向きです。

SAMTEC社のWebサイトにはFootPrintの図がありますが、

それぞれの位置が相対的に書かれていないので分かりにくいです。特に固定用の4つの穴と信号用の端子の関係がわからない。

私が解釈したFootprintは下記のようになりました。

これをのせたベースボードを作るわけですが、3つのコネクタの1番ピンの位置は回路図やその他の図面を見てもわかりにくく、しかも、TE0720とベースボードでは逆になるので、図示しました。

これらのコネクタにはJB1～JB3の名前がついていますが、I/Oポートばかりだと見分けがつきません。幸い、JB2はJTAGが、JB3にはUSBが、JB1にはGbEがあるので見分けがつくでしょう。

なお、MIO40～45にはSDカードをつなぎますが、1.8VのI/Oなのでそのままではインタフェースできないので注意してください。TXS02612RTWRというバッファICを使って3.3Vに直して使うのがおすすめです。

こうして基板の設計が出来上がりました。11/2の金曜日に業者さんに出図して、11/7の火曜日に発送、11/8から実装開始で11/10に実装完了の予定です。

ZYNQを搭載しADC/DACなIoT(2)

だいたい配線が引けた。あとはZYNQモジュールのコネクタのみ。

USB&LANのチップの位置を直した。このチップはUSBコネクタの直近に置くといい感じの配線になる。

電源層が分割されまくってすごいことになっている。

この筐体はCAD上で見るとすごくかっこいい。

タカチのカスタム加工に出すことにしたのだが、「シートではなくモデルのほうに書いてほしい」と言われて、よくわからなかった。

結局、PDFの寸法図から手作業で寸法データを入力してもらうことになった。

CAD入稿への道のりはながい。

はやく実物が見たい。