前回(6)の続き。
ドライバを作って追加しようとしたが、ビルドに失敗したのだった。
こういうときは、PetaLinuxのリファレンスマニュアルを読もう。
ちゃんと、「Adding Custom Modules」「Building User Modules」という項目がある。
あ・・・そういうことか。。。
誤
$ petalinux-build -c rootfs/led8drv↓
正
$ petalinux-build -c led8drv
なんで私はrootfs/なんてのを付けようと思ったのだろうね。。。
あまりにガックリしたので、今日はここまで。
Bitcoinで、UASFだのなんだのと騒がしかった(これを書いているのは2017/07/24)。
あまり関係ないので放置していたが、まったくわからないのも悔しいので、少しだけ調べることにした。
ビットコインのBIP91シグナル、ロックインへ 分岐か収束か | ビットコインの最新情報 BTCN｜ビットコインニュース
やはりよくわからんが、bit1やbit4という数字が出てくる。
BIP91を見ると、bitが4っぽいことはわかった。
consensus.vDeployments[Consensus::DEPLOYMENT_SEGSIGNAL].bit = 4;
しかし、どのデータを見るのか？
BIP9がその大元らしいが、最初に「'version' field in Bitcoin block」と書いているので、ブロックのversionフィールドなのだろう。
Bitcoinプロトコルの"block"に構成が書かれている。
txと同じで、先頭の符号付きLittle Endianの4byteがversionになっている。
では、どのbitがどういう意味なのかという仕様がいるはずだ。
BIP9には以下のリンクが貼られていた。
bips/assignments.mediawiki at master · bitcoin/bips
見ると、bit0とbit1しかない。
bit1は、segwitだ。BIP148と思われる。
じゃあ、bit4ってのはなんなんだってことになるけど、8月1日にbit4が立ったversionのblockじゃないとノードがはじくようにしようとしていた、ということだろうか(BIP読んでない...)。
bit2と3が空いているが、実は私が知らないだけで、そういう判定のような意味で使おうとして、消え去ったのか。
最初の記事にも書いてあるが、じゃあ、bit4だけ立てて、bit1は立てなかったら、segwitを有効にする閾値を80%にすること自体は賛成するけど、segwitには賛成しないよ、ということか。
結局「なんだかよくわからんね」で終わってしまった。
またどこかで勉強しよう。
そもそも、versionをそういう目的で使うのって、曖昧すぎじゃなかろうか。
それをわかってやってるのかもしれないけど、それにしてもねぇ。。。
BIP91がアクティベート、SegWit支持率は97.9%の高止まり | ビットコインの最新情報 BTCN｜ビットコインニュース
BIP141シグナルと書いてあるので読んでいったら、そっちにもbit1と書かれていた。https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#deployment
あれ、じゃあBIP148ってなんだっけ？ということになった。
P2SHみたいに、と書いているから、これがUASFというやつなのか(読んでなさ過ぎ)。
BIP091 : bit4
BIP141- : bit1
じゃあ、bit4もbit1も立てたノードが多数あるのか。
"SegWit支持率"と書いているから、bit1だけで97.9%あるということなのかね。
bit4が承認されなくても達成できるけど、それがなかったらここまではこなかったのか。
Segwit support - Bitcoin Wiki
これは、DeveloperとBusiness(マイナー？)の意思表明リストらしい。
ページの一番下に更新日が書いてあって、私が見ているのは2017/07/23 09:04になっている。
見たら何か分かるかと思ったが・・・これだけだとわからんな。
グラフになっていたら、
BIP91はSegwit2Xとかいう、segwitもやる、ブロックサイズも倍にする、という話が発端だったと思う。
先にsegwitに対応して、3ヶ月後くらいにブロックサイズを倍にするんだっけ。
UASF・Segwit2x・Bitcoin Unlimited：闘いの果てに | ビットコインの最新情報 BTCN｜ビットコインニュース
でも、そういうのはBIP91には書かれてなさそうだから、そっちはそっちでまたあるのかね。
やっぱりよくわからんが、理解できるように追いかけなかったのは正解だった。。
こんだけ情報が早いと、ちょっとついて行けんねぇ。
メモ。
前回、petalinux-create -t modulesでドライバのテンプレートを追加したが、ビルド時にエラーが出た。
名前にアンダーバーが入ってるとエラーになるって？？
と思ったが、私は「led8drv」にしたから、入ってなかった。
ともかく、PetaLinuxというよりは、Yoctoに由来するエラーのようなので、そこら辺から探していくのがよいだろう。
動かん(4)の続き。
前回は、BOOT.BINやimage.ubを作るところまで。
今回は、ドライバを作るところだ。
Solved: How to write a petalinux device driver - Community Forums
The XDMA Framework For The DMA330 DMA Engine - drivers-sessions1-2-public.pdf
古いのかもしれないが、PDFのp.20にコマンドが書かれていた。
"petalinux-create -t modules -n <名前> --enable"で作るようだ。
このコマンドは、PetaLinuxのプロジェクト内で実行しないとエラーになる。
名前を「led8drv」にしたら、project-spec/meta-user/recipes-modules/led8drv、というところを用意してくれた。
この辺りはPDFと違うところだな。
今回はInterface誌のzybo_gpio.cをそのまま使うことにする。
Makefilとled8drv.bbに載っているファイル名を書き換えた。
あとはビルドなのだが・・・petalinux-buildすることにした。
単体でもできるのかもしれんが、petalinux-buildすればimage.ubに入ってくれるんじゃないの？
入ってくれんかった。
createで作ってくれたテンプレートの中にREADMEもあったので、読もう。
まず、rootfsのbuildがいるようだ。
$ petalinux-build -c rootfs
そうするとmenuconfig画面が出てきて、"modules"を見ると今回作ったドライバが入っていた。
あとは、順番に実行せんといかんのか。
$ petalinux-build -c kernel
$ petalinux-build -c rootfs/led8drv
エラーになる。
ERROR: Nothing PROVIDES 'rootfs/led8drv'
ファイルを置き換えるだけではダメなのかと思ったが、元に戻してもエラーが出る。
既にあるGPIOのドライバと重複したからかもと考えたが、それだったらこういうメッセージにはならんよなぁ。
うーん・・・。
今週はこれでおしまいだ。
動かん(3)の続き。
前回は、Vivadoのブロックに対する警告(同期リセット)を無視することにして、LEDとZyboをつないだところまでだ。
残りをやろう。
環境は、Vivado/XSDK v2017.2だ。
まず、Block Design画面で「LEDs_4Bits」のブロックをダブルクリックして、GPIO Widthを7に変更する。
今回はドットがないので7つでもよいはず。
Interface誌では8になっているので、ダメだったら考えよう。
奇数にするってのは、ちょっとドキドキしますな。
続いて、Sourceタブで「system.bdを右クリックするそうだ。
しかし、ファイルがたくさんあってわからん・・・。
検索しよう。
これが絞り込んだ結果らしい。
ちなみに、検索方法の設定はちょっと怪しかった(Vivado v2017.2)。
まあ、SとIだから、どっちがどっちかは大体分かるけどさ。。。
次はピンアサイン。
zybo_base_systemを使ったので、base.xdcというファイルになっていた。
Interface誌を見ると、こういう感じで修正するように書かれていた。
set_property PACKAGE_PIN V12 [get_ports {leds_4bits_tri_o[0]}]
V12はわかる。
これは、JEコネクタの1番ピンに紐付いているからだ。
では、leds_4bits_tri_o[]はどこから出てきた名前だろうか？
base.xdcに、こういう行があった。
set_property PACKAGE_PIN M14 [get_ports {leds_4bits_tri_o[0]}]
今回は、JE1,2,3,4,7,8,9なので、leds_4bits_tri_o[0～6]までに当てればよいのか？
しかし、Pmodの図はこうなっていた。
あ・・・私まちがえてる。。。
Pin1は右上として、Pin2はその左隣なんだ。
下をPin2だと思ってたけど、一番左にPin6と書いてあるな。
写真ではわからんと思うが、修正しておこう。
base.xdcを直接編集してもよいが、せっかく専用のエディタがあるので、そっちを使おう。
Run Synthesisしておくと、I/O Planning画面が使えるようだ。
しかし、Run Synthesis自体がかなり長い・・・。
PCの性能はそんなに悪くないと思うのだが、10分以上かかったんじゃなかろうか。
ともかく、I/O Planningは選択できるようになった。
GPIOという名前が付いた項目がいくつかあるので、led関連を探すとこうなっていた。
よく考えたら、LEDs_4Bitsってボード上のLEDだろうから、新たにGPIOのブロックを追加すべきだったんじゃなかろうか。
まあいいや。
JEポートの1～9番を使っているので、それぞれ割り当てる。
あとは、Generate Bitstreamするだけ。
これはこれで時間がかかりそうだ・・・そうでもなかった。
3分くらいかな。
Interface誌ではExportするところは書かれていないが、タイトルがそうなっているので、Exportしよう。
たぶん「Include bitstream」にチェックを入れるはず。
と思ったが、bitファイルさえできればよいのならExportしなくてよいのかも。
私のところではプロジェクト名を「led8」にしたが、led8.runs\impl_1\system_wrapper.bitができていた。
Exportしたあとに調べたのではっきり言えないが、タイムスタンプからするとGenerate Bitstreamで生成されているはず。
手順では、ExportしたあとにSDKを起動するようになっていて、SDKからBOOT.BINを生成している。
しかし、このBOOT.BINって、何者だろうか？
XSDK v2017.2だから、PetaLinux v2017.2なのだろうか。
まあいい、書いてあるとおりにやってみよう。
Launch SDKすると、プロジェクトができていた。
led8/led8.sdk/system_wrapper.hdfを読んだようなログも出ているし、間違いなかろう。
自分で作らなくてよかったんだっけ？
あるものは使おう。
手順ではCreate Zynq Boot ImageでBIFファイルを選ぶようになっているが、私のところにはBIFファイルが見当たらない。
「既にoutput.bifファイルがありますので」と書いてあるけど、ない場合は「Create new BIF file」でよいのだろうか。
しかし、これはこれでUDFファイルがいるようなのだ(importの場合もいるみたいだけど)。
どうも、zybo_base_systemにboot.bifがあるらしい。
単なるテキストファイルだ。
the_ROM_image:
{
[bootloader].\fsbl.elf
.\system_wrapper.bit
.\base_demo.elf
}同じフォルダに、ここに書いてあるELFファイルがあるので、これを使ってBOOT.BINやimage.ubを作るということか。
UDFは、ユーザー定義フィールドなのか？
以前のXSDKにはない項目のような気がする。
そもそも、Vivadoはなんとなくわかるとして、XSDKは何をするツールなのだ？
読んでもわからん。。。
PL部は、Vivadoで、ハードウェア開発。
PS部は、XSDKで、ソフトウェア開発。
そういう見方でよいのだろうか。
だいたい、ホモジーニアスとかヘテロジーニアスとか、生物か何かの授業で聞いたような単語の意味がわからん。
ホモジーニアスが同種、ヘテロジーニアスが別種なのだろうけど、それがFPGAとどう関係するのか。
マルチプロセッサで実現したH.264ビデオ・デコーダ ――コンフィギャラブル・プロセッサのユーザ定義命令とオンチップ・バスを活用｜Tech Village （テックビレッジ） ／ CQ出版株式会社
うーん、ARMコアが2つだからホモジーニアス？
それとも、PS部とPL部でヘテロジーニアス？
ともかく、Eclipseだし、DigilentのチュートリアルでZYBOに転送してたので、少なくともARM向けにクロスコンパイルはしてくれそうだし、Program FPGAでbitファイルを焼いてもいるのだろう。
ここからBOOT.BINを作ることができると便利そうだけど、今回は深く考えず、VirtualBox上のXubuntuでビルドしたPetaLinux v2017.2を使おう。
あれなら、hdfファイルとbitファイルがあればよかったはずだ。
led8.sdk\system_wrapper_hw_platform_0をフォルダごとXubuntuにコピーして、
$ petalinux-create -t project -n led8 --template zynq
$ cd led8
$ petalinux-config --get-hw-description=../system_wrapper_hw_platform_0
(変更せず終わらせる)
$ petalinux-build
(時間がかかる)
$ petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --fpga images/linux/system_wrapper.bit --u-boot --force
と手順を書いたが、petalinux-build中にエラーが起きた。
| ERROR: axi_vdma_0: mm2s_introut port is not connected
Solved: AXI DMA in Vivado How should I connect mm2s_introu... - Community Forums
concatというIPを追加して、axi_vdma_0とaxi_vdma_1のmm2s_introutをそれぞれつないだ。
そしてPS7 IRQ_F2Pにつなげばよいそうだが、Zynqにそういうポートがないな。
Zynqをダブルクリックして、Interrupt Portタブを検索すると出てきたのだが、チェックができない。。。
AR# 58942: Vivado IP インテグレーター、Zynq-7000 - PL 割り込みを Zynq-7000 PS に接続する方法
あ、先にFabric Interruptsにチェックして、その後でIRQ_F2Pにチェックするのか。
zybo_base_systemを使わない方が楽だったな。。
そこだけ修正すると、imageの生成までできた。
さて、PetaLinuxを起動するだけであればBOOT.BINとimage.ubをSDカードにコピーするだけでよかったのだが、今回はどうするとよいのか。
などというところも、Interface誌に書いてある。
Linuxのドライバを経由して、作ったものをたたくようだ。
まあ、Linuxだからドライバを作らないとダメよね。
FreeRTOSにも対応しているみたいだから、そっちだともう少し触りやすいかもしれないけど、Zynq使っていてFreeRTOSにするというのももったいない気がする。
もったいないというか、せっかくマイコンの性能をそこまで気にせずにいけるし、リソースもそこそこ広大なのだから、ドライバを作らないかんという面倒があったとしても、そのルールに載った方が楽だと思うのだ。
まずは、ドライバなどをインストールせず、petalinux-buildしたものをそのままSDカードにコピーして立ち上げた。
うん、7セグがフル点灯している。
つまり「8」が見えている。
写真に詳しくないのだが、まだ明るい時間なのに、撮影したらこうなってしまった。
ともかく、カソード側は全部GNDに落ちているということか。
そして、それ以上に大切なのは、GPIOの設定が既に有効になっているということだ。
いや、どうかな・・・。
LED側は電源を突っ込んでるだけなので、GPIOでGNDにつながってさえいれば点灯する。
もしかしたら、Zになっているだけで点灯してしまう可能性がなくもないのではなかろうか(どうだろう？)。
ともあれ、Linuxのドライバがいる。
Interface誌のダウンロードコーナーにあるので、それを使う。
Digilent社もドライバを出しているそうだし、ZynqのドライバやAXIのドライバもありそうだが、まあいいや。
いま、kernelの起動ログでGPIOっぽいものを出しているのは、これくらいだ。
GPIO IRQ not connected
XGpio: /amba_pl/gpio@41200000: registered, base is 902
GPIO IRQ not connected
XGpio: /amba_pl/gpio@41210000: registered, base is 895
GPIO IRQ not connected
XGpio: /amba_pl/gpio@41220000: registered, base is 891
Cソースが1つだけなので、コンパイルすればよいのかな。
$ arm-linux-gnueabihf-gcc -o zybo_gpio.ko zybo_gpio.c
zybo_gpio.c:16:25: fatal error: linux/delay.h: No such file or directory
惜しい。
ドライバのコンパイルは、動作環境のLinuxドライバ用ディレクトリを-Cで指定し、変数Mにカレントディレクトリを、obj-mにビルド後のファイル名(.o)を指定すればよいようだが、はてさて。
長くなってきたので、今回はここまで。
