[ZYBO]DigilentのYocto

こちらが、Xilinxのyocto-manifestsで、ブランチがrel-v2017.2の内容。
https://github.com/Xilinx/yocto-manifests/blob/rel-v2017.2/default.xml
revisionが"rel-v2017.2"になっているので、それぞれのgitからブランチrel-v2017.2を取ってくるようになっている。

そして当面の問題は、meta-xilinxにZYBOの設定ファイルがないのだけどどうしようか、である。
こちらは、rel-v2017.2の設定ファイル一覧。
https://github.com/Xilinx/meta-xilinx/tree/rel-v2017.2/conf/machine
リビジョンが過去になれば存在するかというと、そういうわけでもない。

Yocto 2.1にはまだ入っていない、というQAがあった。
2.1は、krogothというブランチ名のようだ。
How to install Yocto Project 2.1 on ZYBO - FPGA - Digilent Forum

ということは、それより前のバージョンだったらサポートがあるということだろうか？
Digilentのgithubに、repoできるものがあった。
https://github.com/Digilent/meta-manifest

ブランチ名がjethroなので、2.0(2015/11/23)か。
meta-xilinxだと、rel-v2016.2がjethroなのだが、Vivadoなどがv2017.2でもビルドできるのだろうか？
それとも、あまり関係ないのだろうか。。

default.xmlを見ると、かなりシンプルだ。
meta-xilinxもDigilentのもので、こちらもjethroという名前になっていた。

---

では、やっていこう。

$ repo init -u https://github.com/Digilent/meta-manifest.git -b jethro
$ repo sync
$ repo start jethro --all

ここから先は、Digilent Wikiを見ながらやっていく。

$ export layer_root=`pwd`
$ export target_machine="zybo-linux-bd-zynq7"
$ mkdir tmp
$ cd tmp
$ source ${layer_root}/poky/oe-init-build-env ${target_machine}
$ sed -i "/meta-yocto-bsp/a \  ${layer_root}/meta-openembedded/meta-oe \\\ " conf/bblayers.conf
$ sed -i "/meta-yocto-bsp/a \  ${layer_root}/meta-xilinx \\\ " conf/bblayers.conf
$ sed -i "s/MACHINE ??= \"qemux86\"/MACHINE ?= \"${target_machine}\"/" conf/local.conf

conf/local.confの一番下に、これらを追加。
最後の2行は、いるのかどうかわからんが、あった方がよさそうな気がする。

PREFERRED_PROVIDER_virtual/bootloader = "u-boot-digilent"
PREFERRED_PROVIDER_u-boot = "u-boot-digilent"
PREFERRED_PROVIDER_virtual/kernel = "linux-digilent"
PREFERRED_PROVIDER_virtual/boot-bin = "u-boot-digilent"
IMAGE_INSTALL_append = " mtd-utils"
IMAGE_INSTALL_append = " kernel-modules"

そして、menuconfig。
2つ書いてあるが、うーん、digilentと書いてある方が無難な気がする。
でも、今回はpreferred kernelでも同じかもしれん。

$ bitbake linux-digilent-dev -c menuconfig

何やらダウンロードが始まり、いつものmenuconfig画面が出るのに30分くらいかかった。
General setupで、Local versionが「-digilent」になっているのは気付いたが、それ以外はよくわからんな。
System TypeはXilinx Zynq ARM Cortex A9 Platformになっていた。

まあ、今回は何も変更せずによかろう。

---

次はBuildだ。
core-image-minimalとcore-image-satoがあるらしい。
satoは佐藤さんではなく、GTK+をベースにしたUIになっていそうだ。
ZYBOには画面出力もあるので、satoでビルドしよう。

$ bitbake core-image-sato

local.confにxtermを追加するような記載があったけど、ビルドする説明の前に書いてくれよ。。。
もうコマンドを打ってダウンロードなどが始まっているから、このまま進めよう。

買い物から帰ってくると、エラーで止まっていた。。。
どうも、ダウンロードにあれこれ失敗しているためか、xserver-xf86-configのconf.dが無いなどといわれている。

こういうときは、UIをあきらめるのがよいだろう。

$ bitbake core-image-minimal

こちらは、あまり時間がかからずに終わった。
core-image-satoをやっていたおかげかもしれん。

---

次は、build productsだ。

bitbakeした場所から見ると、tmp/deploy/images/zybo-linux-bd-zynq7にできているようだ。

boot.bin@
boot.bin-zybo-linux-bd-zynq7@
boot.bin-zybo-linux-bd-zynq7-v2016.03digilent+gitAUTOINC+4dd0f06c46-u-boot-digilent*
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.cpio
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.cpio.gz.u-boot
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.ext4
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.manifest
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.tar.gz
core-image-minimal-zybo-linux-bd-zynq7-20170708062821.rootfs.xilinx-sdimg
core-image-minimal-zybo-linux-bd-zynq7.cpio@
core-image-minimal-zybo-linux-bd-zynq7.cpio.gz.u-boot@
core-image-minimal-zybo-linux-bd-zynq7.ext4@
core-image-minimal-zybo-linux-bd-zynq7.manifest@
core-image-minimal-zybo-linux-bd-zynq7.tar.gz@
core-image-minimal-zybo-linux-bd-zynq7.xilinx-sdimg@
download.bit@
download.bit-+gitAUTOINC+63ca49fe02-r0-zybo-linux-bd-zynq7.bit
fitImage-1.0-r0-zybo-linux-bd-zynq7
fit.itb@
linux.bin@
modules--4.0-digilent+git0+86b46b6606-r0-zybo-linux-bd-zynq7-20170708062821.tgz
modules-zybo-linux-bd-zynq7.tgz@
README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
sdimg@
sdimg-zybo-linux-bd-zynq7@
sdroot-fitImage@
sdroot-fitImage-zybo-linux-bd-zynq7-1.0-r0
sdroot-uImage-its-1.0-r0-zybo-linux-bd-zynq7.its
sdroot-zybo-linux-bd-zynq7.dtb
system.dtb@
system-top.dtb
u-boot.bin@
u-boot.bin-zybo-linux-bd-zynq7-v2016.03digilent+gitAUTOINC+4dd0f06c46-u-boot-digilent*
u-boot-dtb.bin@
u-boot-dtb.bin-zybo-linux-bd-zynq7-v2016.03digilent+gitAUTOINC+4dd0f06c46-u-boot-digilent*
u-boot-dtb.img@
u-boot-dtb.img-zybo-linux-bd-zynq7-v2016.03digilent+gitAUTOINC+4dd0f06c46-u-boot-digilent*
u-boot-spl.bin@
u-boot-spl.bin-zybo-linux-bd-zynq7-v2016.03digilent+gitAUTOINC+4dd0f06c46-u-boot-digilent*
uImage@
uImage--4.0-digilent+git0+86b46b6606-r0-zybo-linux-bd-zynq7-20170708062821.bin
uImage-its-1.0-r0-zybo-linux-bd-zynq7.its
uImage-its-zybo-linux-bd-zynq7.its@
uImage-linux.bin-4.0-digilent+gitAUTOINC+86b46b6606-r0-zybo-linux-bd-zynq7.bin
uImage-zybo-linux-bd-zynq7.bin@
zybo-linux-bd-zynq7.dtb@

多いね。

wicというツールを使えばブートできるSDカードができるらしいのだが、SDカードの場所はどこで指定するのだろうか？
まあいい、やってみよう。

$ wic create -e core-image-minimal ${layer_root}/meta-xilinx/scripts/lib/image/canned-wks/sdimage-xilinx.wks

SDカードを作るのではなく、SDカードに書き込むimageを作るだけのようだ。

---

SDブートを見ていこう。

boot.bin, fit.itb, download.bit, u-boot-dtb.imgの4ファイルを最初のパーティションにコピーすればよいらしい。
が、注意書きがある。

IMPORTANT Note: User must have u-boot SPL (the FSBL) automatically load the FPGA bitstream or stop at u-boot and load it manually!!! Otherwise the kernel will not boot. The next two sections describe these two methods

内容は、

ユーザはu-boot SPL(FSBL)を持っていなくてはならない！！！　さもなくばkernelはブートしないであろう。

くらいの解釈でよいのかな？
"automatically"以下はFSBLの説明だと考えたのだけど、自信がないのでGoogle翻訳してもらおう。

ユーザーはu-boot SPL（FSBL）を自動的にFPGAビットストリームをロードするか、またはu-bootで停止して手動でロードする必要があります。

うーん、mustはhaveではなくloadにかかっているようだ。

2つ方法が書かれていて、u-bootで読込む方法と、SPLから読込む方法があるそうだ。
FPGAマガジンに書かれているのは、たぶん後者だろう。
"bitstream"というファイル名にしておくと、bit形式かbin形式だったら読込んでくれるそうだ。
ここでは、download.bitファイルがFSBLらしいので、download.bitをbitstreamにリネームするようだ。

ここまでやったあとで、先ほどのwicコマンドで作ったイメージを使ってSDカードを作る方法が書かれていた。
最初からこっちだけ説明すればいいやん。。。
https://github.com/Digilent/meta-manifest/wiki/Quick-start-guide#using-sdimg

ddコマンドでSDカードの先頭から書込むと、パーティションまで分けたSDカードができあがるのだ。
fdiskで見ると2つパーティションがあるのだが、gpartedで見ると4つある。

16GBのSDカードなのだが、wicの時点ではサイズが分からないのでこうなるのだろう。
まあ、このままでよい。

このSDカードをZYBOに挿すと、起動した。

(前略)
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 2.0.3 zybo-linux-bd-zynq7 /dev/ttyPS0

zybo-linux-bd-zynq7 login:

rootでログインもできる。
やれやれ。

---

では、bitstreamを書き換えれば、自分の作ったものが自動的にロードされるのだろうか。
SDSoC 2017.1で作ったとき、拡張子がbitになっているファイルがあったので、それを上書きしてみよう。

・・・ダメだ。
Linuxがちゃんと起動しない。
あれは、SDSoCの例だから、Linux側もセットになっているのかも？

その前に作った、VHDLでLEDを点滅させるbitファイルを上書きした。
これは動いて、LEDが点滅しているのだが、Linuxの方が「Starting kernel ...」で止まってしまった。
確か、このメッセージはkernel側が出していたような気がするんだけど、どうなんだろう？

kernelが動いていたときのbitstreamを上書きするとちゃんと起動したので、bitstreamファイルに関係があるのは間違いない。
コンソールログとLED点滅を見比べていくと、かなり早い段階でLED点滅が始まっている。
PL部が何かやっていないためにkernelが待ち状態になっているのだろうか？

http://qiita.com/ikwzm/items/1614c35233e1836c7a26
「FSBLをVivado SDKで作った場合」と書いてあるので、何かしてやらんといかん気がする。

ここを見ると、SDKでアプリを作るとき、FSBLを選択してfsbl_hooks.cだけ変更すればよいらしい。
5. Zynq SDKでFSBLを作る – yuki-sato.com
「zybo_base_system」から持ってくるそうだが、これだろうか？
fsbl_hooks.cファイルは、これと同じようだ。
ZYBO/fsbl_hooks.c at master · Digilent/ZYBO

置き換えてビルドしたのだが、xiicps.hがないということでエラーになった。
SDKのtarget/aarch32-none/includeにあったので、Eclipseの設定でパスを追加。
ビルドすると、今度は「XPAR_PS7_I2C_0_DEVICE_ID」が未定義だと。。。
I2Cは今回使わないからコメントアウトすると、その一帯がエラーになるようなので、もうエラーになるところは全部コメントアウト。

ここまでやって、ようやくFSBLがビルドできた。
あれ、ELF ?
メニューから「Create Image」で作っていくようだけど、これでできるのはBOOT.binだ。
説明では、ここにu-bootのELFファイルを追加するようなのだが、Yoctoで作ったimagesの中にはELFファイルはないように見える。

深みにはまりそうなので、ここは、一時撤退だ。
FPGAマガジンにはU-bootのSPLはFSBLの代わりになるような書き方をしてあったので、FSBLは作らなくてよいと思うのだ。
しかし、bitstreamを上書きして動かないというのも事実なので、何かしないといけないはずだ。
次はそこを調べよう。

[勉]Yocto (2)

前回は、Yoctoではレイヤーというものがあり、meta-xxxという名前ルールになっているというところまで読んだ。

ここがYocto Projectの大きなインデックスになるのだろうか。
http://git.yoctoproject.org/cgit/cgit.cgi/

名前にmetaが付かないものもたくさんあるが、グループが「Yocto Metadata Layers」になっているものはmetaから始まっているようだ。
Interface誌2015年12月号では、「meta」「meta-yocto」「meta-yocto-bsp」が最低限必要と書いてあるのだが、このインデックスに載っているのはmeta-yoctoだけで、meta-yoct-bsp-oldというものがあるくらいだ。

時代が変わったのかと思ったが、Interface誌を見るとgit cloneしているのは「poky」だった。
そちらのtreeを見ると、この中にmetaやmeta-yocto-bspも入っていた。
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/

取りあえず最新版を使っておけばよいのだろう、と思ったが、こちらを見るとそうでもないようだった。
YoctoをつかったDistroの作り方とハマり方
各レイヤーごとに管理が別々なので、同期がとれているわけではないとのこと。
ではどうやるのがよいか調べた結果、repoを使うのがよさそうだ、ということだった。
ああ、だからYocto Xilinxのところでもrepoを使うようになっていたのか。

なんとなく分かった気がするので、そろそろZYBO用のビルドをしてみよう。

[zybo]SDx 2017.1でチュートリアルを試す

SDSocの開発環境だと思われるSDxが2017.1になっていたので、インストールしてZYBOチュートリアルの以前ダメだったところが動くかどうか確認した。
リンク先は最新のものが出てくるようなので、これを書いているときの最新版が2017.1だったと思っておくれ。

ダウンロード

前回ダメだったのは、VivadoからLaunch SDKで起動するところ。
今回はうまくいった！
・・・のだけど、ライセンス認証のダイアログが毎回出てくる。
どうも、xdlmcheckというスクリプトを使っているようだけど、それがPATHで見つからないためのように見える。
SDSoCのライセンスを持っているからかもしれんが、キャンセルしたらとりあえず回避できた。

ツールバーにFPGA関連のアイコンが出てこないのも、前回と同じだった。
パースペクティブの設定でチェックボックスをONにすれば出てきたけど、普通はうまくいくんだろうなぁ。。。

気になったのは、Vivadoの方だ。
プログレスダイアログが、あまり正確じゃないような気がする。
画面の右上に出ていたくるくるも出てこないし、いつ作業が終わったのかがよくわからんのだ。

---

それ以外は、前回と同じように動いた。
だから、前回との違いは、VivadoのメニューからSDxを起動できた、というところだけになってしまう。
xdlmcheckは、OSを再起動しないとわからないと思う(うちはWindows10だ)。

情報はたくさんあるのだけど、移り変わりが激しくて、どのルートをたどるのがよいか悩みまくりだ。

[c/c++]同じidでmsgsnd()してmsgrcv()しても、msgtypeを指定すればOK

以前、こんな記事を書いた。
http://hiro99ma.blogspot.com/2017/06/ccidmsgsndmsgrecv.html

まだこれに悩まされていたので、そろそろidを分けようとしていた。
面倒だが、いちいちsleepを入れないとエラーになるくらいだったら、分けてしまった方が楽だろう。

その前に、メッセージキューのやり方を忘れてしまったので、本を読み返すことにした。
msgrcv()のところを読んでいると、気になる記述に突き当たった。

int msgrcv(msgid, msg_ptr, msg_sz, msgtype, msgflg)

• 送信された順序でメッセージを受信したい場合には、msgtypeに0を設定する
• 特定のメッセージ型のメッセージだけを受信したい場合には、等しい値をmsgtypeに設定する

あの引数って、そんな意味があったの？？

念のためJMのほうも見てみたが、上記を理解していれば、そのように書いてあるのがわかった。
Man page of MSGOP

びっくりしたような、自分にがっかりしたような、そんな気分だが、無駄な実装をせずに済んだことを喜ぼう。

[xilinx]SDSoC 2017.1リリース

Yoctoの勉強が止まっているが、本業が、本業が。。。

というところに、手頃な情報がやってきた。
XilinxのSDSoCで、2017.1がリリースされたとのこと。
今回はすんなりインストールできるかしら？
SDSoC - 2017.1 フル製品インストール - 2017.1 Full Product Installation

reVISIONサポートというものが売りになってる。
どうやら、機械学習関係のようだ。
それ以上深く話すことができる知識がないので、このくらいでやめておこう。。。
reVISION ゾーン | 機械学習 | コンピュータ ビジョン

MiniZedというボードが出る(出た？)そうで、このくらいの大きさだったら私にも理解しやすいかも、と思ったけど、これでもCortex-Aなのか。。。
Avnet 社製 MiniZed

検索していたら、Interface誌でCortex-M3+FPGAの連載をしていたようなので、読んでおこう。

[勉]Yocto (1)

数回で飽きると思うが、Yoctoの勉強をしよう。

今日は、Interface誌に載っていた情報を読もう。
2015年12月号 目次｜Interface
ちょっと古いが、基本的な内容は変わらんだろう。

ただ、大幅に変わることもしばしばあるので、ここで読んでいる情報は2015年10月よりも前くらい、ということを念頭に置いてほしい。

---

まず、Yoctoはディストリビューションやカーネルそのものというよりは、動く環境を構築するしくみ、というところのようだ。

bitbakeというビルドツールを使う。
リファレンスビルドシステムはOE componentsと書いてあるが、こっちはよくわからんな。
そして、よく聞くPokyは、このリファレンスビルドシステムの名前だったり、生成したディストリビューションの名前だったりするそうだ。
変更もできるそうだが、デフォルトがPokyなのだろう。
心の中では「ぽっきー」と呼んでいたのだが、あれはkがもう1ついるな。。
「ぽーきー」くらいか？

「レシピ(recipe)」というものがポイントらしい。
雑誌では「レシピの集合体」とか「レシピをグループ分けしたレイヤの集合体」などと書かれているが。。。
例としてRaspberry Piのレイヤが表になっているが「レシピ群」と書いてある。
レシピの集合体がレイヤらしい。

なら、レシピよりレイヤの方が大切そうな気がするが、レイヤは集合以上のものではなさそうだ。
/usr/binディレクトリは大切だけど、実際に使うのはその中に入っている実行ファイルたちだ、みたいな関係か。

レイヤには「meta-xxx」という名前を付けるルールになっているらしい。
だから、meta-xilinx、という名前だったのか。
他にも、meta-petalinux、meta-xilinx-toolsなどがあるようだ。

githubにもあるけど、yoctoprojectにもmeta-xilinxがある。
一番上にあるcommit messageは同じだったが、同じものなのだろうか？
そして、メッセージにzybo-linux-bd-zynq7と書いてあるのだけど、最新版が安定したらZYBOも何も考えずにbitbakeで作ることができるようになるのだろうか。。。

ここまででInterface誌の2ページ分くらいだ。
レシピの作り方などが続いていくが、そこは流して読んでいくことにしよう。
ともかく、今日はここまで。

[zybo]ZYBO向けのLinux (4)

考えてもわかりそうな気がしないので、まずはYoctoが提供しているシステムで環境を作ることにした。
ZYBO用confファイルのどこかがよくなかったせいじゃないかと考えたのだ。

build$ MACHINE=zcu102-zynqmp bitbake petalinux-image-minimal

初回はいつも時間がかかるのだな。。。
昼寝して起きたら、エラーが発生していた。

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: fsbl-2017.2+gitAUTOINC+122565ec40-r0 do_deploy: Function failed: do_deploy (log file is located at /xxx/yocto/build/tmp/work/zcu102_zynqmp-xilinx-linux/fsbl/2017.2+gitAUTOINC+122565ec40-r0/temp/log.do_deploy.15315)
ERROR: Logfile of failure stored in: /xxx/yocto/build/tmp/work/zcu102_zynqmp-xilinx-linux/fsbl/2017.2+gitAUTOINC+122565ec40-r0/temp/log.do_deploy.15315
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing shell function do_deploy
| install: cannot stat '/xxx/yocto/build/tmp/work/zcu102_zynqmp-xilinx-linux/fsbl/2017.2+gitAUTOINC+122565ec40-r0/build/fsbl/Release/fsbl.elf': No such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_deploy (log file is located at /xxx/yocto/build/tmp/work/zcu102_zynqmp-xilinx-linux/fsbl/2017.2+gitAUTOINC+122565ec40-r0/temp/log.do_deploy.15315)
ERROR: Task (/xxx/yocto/sources/core/../meta-xilinx-tools/recipes-bsp/fsbl/fsbl_git.bb:do_deploy) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2047 tasks of which 824 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
   /xxx/yocto/sources/core/../meta-xilinx-tools/recipes-bsp/fsbl/fsbl_git.bb:do_deploy
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

fsbl.elfができていないので終わったようだ。
しかし、fsbl.elfができていないことについてのエラーメッセージが出ていない。
ZYBOも同じようにできていないからエラーになったのかと思ったが、こちらにはfsbl.elfができていた。

うーん、参考にならん。。。

---

初心に帰って、Yoctoの環境を作るところからやっておこう。
repoだけしかやってなかったのだ。

Yocto Project Quick Start
ここのUbuntuをみてapt installした(今回は、Xubuntu 16.04を使っている)。

そして、repo initからやり直そう。
前のは消した方が良いのかもしれんが、めんどうなのでそのままやる。
だめだったら、全部消そう。

$ repo init -u git://github.com/Xilinx/yocto-manifests.git -b rel-v2017.2
$ repo sync
$ repo start rel-v2017.2 --all
$ source setupsdk
$ MACHINE=zybo-zynq7 bitbake petalinux-minimal

なんか、特に処理が行われた感じがしないから、cleanみたいなことをしたい。

bitbake の clean
-c cleanしてからやり直すそうだ。
やってみたが、やはりFITファイルはできなかった。

---

Yocto BSP · socnix-lab/PetaLinux_BSPs Wiki

こちらは1年くらい前の更新だが、FITファイルができているようだ。
MACHINEは"zybo-linux-bd-zynq7"だし、branchは"jethro"だ。
"jethro"は表を見ると、rel-v2016.2くらいのようだ。

ああ、meta-xilinxのrel-v2017.2にZYBOのconfファイルがないのが
https://github.com/Xilinx/meta-xilinx/tree/rel-v2017.2/conf/machine

jethroのような名前が付いたブランチにはZYBOのconfファイルが入っているけど、relのついた名前の方には入っていないようだ。
relじゃない方の名前は、XilinxではなくYoctoの名前らしい。

私がrel-v2017.2を使ったのは、インストールしたVivadoが2017.2だからというだけだ。
そして、ここまでビルドしてきて、Vivadoのバージョンに依存しそうなところが見えていないので、気にしなくてよいのだろうか？

そう思って、mortyくらいをrepo initしようとしたが失敗した。
そういえば、meta-xilinxではなく、yocto-manifestsだった。
こっちはrelのついたブランチしかない。

どうも、やり方が変わったようだ。
rel-v2016.4まではmeta-petalinux.xmlのような名前だが、rel-v2017.1からはdefault.xmlになっているし、XMLファイルの中身も少し変わっている。
ビルドのやりかたも、rel-v2017.1以降とそれ以前で分かれていたな。

---

そういえば、最初にビルドしたとき、エラーが出てconfファイルを適当に変更したのを思い出した。
そもそも、そこで出るエラーを何とかしないといけなかったんじゃなかろうか？

confファイルのこの行をコメントアウトして逃げたのだ。

EXTRA_IMAGEDEPENDS += "u-boot-zynq-uenv"

これで検索すると、どうもmeta-xilinxのmasterには入っているが、ブランチにはないようだった。
じゃあ、このファイルをコピーしてやればよいかと思ったが、他にもファイルがいりそうだった。
では、meta-xilinxだけmasterにしてしまえばよいか。

yocto-manifest.gitをforkして書き換えてpushしたものを用意したのだが、id_rsaのpassphraseを入力すると止まってしまう。
わからんので、yocto-manifest.gitでrepo initして、.repo/manifest.xmlを書き換えることにした。

$ repo init -u git://github.com/Xilinx/yocto-manifests.git -b rel-v2017.2
$ vi .repo/manifest.xml
  (meta-xilinxのrevisionだけmasterにする)
$ repo sync
$ repo start rel-v2017.2-zybo --all
$ source setupsdk
$ MACHINE=zybo-zynq7 bitbake petalinux-minimal

だめか。。。

ExpansionError during parsing /xxx/meta-xilinx/recipes-devtools/qemu/qemu-xilinx-helper-native_1.0.bb

bb.data_smart.ExpansionError: Failure expanding variable FILESEXTRAPATHS_prepend[:=], expression was ${@get_filespath_extra(d, 'recipes-devtools/qemu/qemu-helper')} which triggered exception TypeError: getVar() missing 1 required positional argument: 'expand'

masterって、ダメなこと多いよね。。

---

こういうときは、1つ前のバージョンだ！
ただ、relがついたブランチにZYBOのconfファイルはないので、そこはコピーして、"u-boot-zynq-uenv"の行をコメントアウトした。
そして今回は、MACHINEをなんとなくzybo-linux-bd-zynq7にしてみた。
はあ、なんで私はこういう変更をいっぺんでやってしまうんだろうねぇ。。。

$ repo init -u git://github.com/Xilinx/yocto-manifests.git -b rel-v2017.1
$ repo sync
$ repo start rel-v2017.1-zybo --all
$ source setupsdk
$ MACHINE=zybo-linux-bd-zynq7 bitbake petalinux-minimal

だめね。　

ERROR: Nothing RPROVIDES 'device-tree' (以下略)

では、zybo-zynq7に戻してみよう。
さっきよりは進んでいるので、rel-v2017.1ではなくzybo-linux-bd-zynq7のconfファイルによるものか。

TARGETとしてpetalinux-minimalを使っているが、ここも見直した方が良いのかもしれない。
こちらの人はcore-image-minimalやcore-image-satoでやっているようだ。

これでダメだったら、単にFITファイルができればよいだけなので、自分でそこだけつくる方向がよいのかもしれん。
あるいは、Yocto Projectについてちゃんと調べるか。

---

2017/07/02 23:46

ダメだった。
meta-xilinxではなく、meta-xilinx-toolsの方で、HDFファイルがないとか何とか。

ZYBOもそんなに新しいボードではないので、Xilinxでサポートするのを止めたのだろうか。
Xilinxにおんぶされるのではなく、使わないといけないところだけXilinxのものを使い、あとは他のところから持ってきた方が良いのかもしれん。

ここなんかは、core-image-minimalを少ない手順で構築している。
そういうのを真似した方がよいかもしれん。
Build An Embeded Linux using Yocto project for Zybo | CharlieShao's Blog

[zybo]ZYBO向けのLinux (3)

前回はXilinx wikiを見ながらビルドしたまでだった。
wikiも読んでいたが、FPGAマガジンNo.12も読んでいたので、実はクロス開発環境の構築も済ませている。

本の方はXilinxとAlteraの両方で動く環境を作ろうとしていたので、初心者の私はカスタマイズせずにXilinx用の環境だけを作ろうとしている。

クロス開発環境はbuild/tmp/deploy/sdk/petalinux-glibc-x86_64-petalinux-minimal-cortexa9hf-neon-toolchain-2017.2.shというファイルがインストーラらしく、そのまま走らせると/opt/petalinux/2017.2にインストールされた。
そこに環境変数を設定するスクリプトがあるので、sourceなどで読込むようになっているようだ。

x86_64-petalinux-linuxとcortexa9hf-neon-xilinx-linux-gnueabiが入っている。
prefixはarm-xilinx-linux-みたい。
なんか、yoctoのコンパイラといえばpokyという名前のような印象を受けていたのだが、Xilinxの提供している設定だからこういう名前なのだろうか。
そもそも、SDKがいるのかどうかすらわかってない。

まあいい。

---

次はブートローダをビルドするようだ。
U-bootだ。
http://git.denx.de/?p=u-boot.git;a=summary

本では、Xilinx用の場合"hsi"コマンドを使って初期化ファイルを生成しているのだが、yoctoのbuild/tmp/deploy/images/zybo-zynq7を見ると、中にu-boot.elfがあるし、u-boot-dtb.binやu-boot-zybo-zynq7.binなんかもある。
一緒に作ってくれたのだろうか？
作ってくれたものとして話を進めよう。

これをSDカードにコピーすればよいのだろうが、さて、どれをコピーするのだろうか。

---

Xilinx Wiki - Getting Started

Yoctoだけしか見ていなかったが、Linux環境の作り方がちゃんと書かれていた。
回り道しすぎだ。。。

ここの説明はYoctoを使っておらず、menuconfigなどで地道にビルドしているようだ。

Xilinx Wiki - Prepare Boot Medium
この順番にSDカードの準備をしていった。
コピーするのはboot.binだけなのだけど、カーネルなんかはいらないのだろうか？
よくわからんので、このままZyboに挿して、DIPスイッチをSDに変更して起動してみた。

U-Boot SPL 2016.03 (Jun 26 2017 - 09:07:42)
mmc boot
Trying to boot from MMC
reading system.dtb
spl_load_image_fat_os: error reading image system.dtb, err - -1
reading u-boot-dtb.img
spl_load_image_fat: error reading image u-boot-dtb.img, err - -1
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

system.dtbもないし、u-boot-dtb.imgもない。
まあ、何もコピーしてないしね・・・。
一番近そうなファイル名はu-boot-dtb.binなのだけど、リネームすればよいのだろうか。

*** Warning - bad CRC, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Zynq ZYBO Development Board
Board: Xilinx Zynq
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id

Warning: ethernet@e000b000 (eth0) using random MAC address - xx:xx:xx:xx:xx:xx
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0
Copying FIT from SD to RAM...
reading fit.itb
** Unable to read file fit.itb **
Zynq> version

U-Boot 2016.03 (Jun 26 2017 - 09:07:42 +0900)
arm-xilinx-linux-gnueabi-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
GNU ld (GNU Binutils) 2.27.0.20160806

USBシリアル変換だから、もしかしたら電源ON直後は切れてるかもしれんが、それっぽい出力だ。
Yoctoのビルドをしたのが数日前だから、versionで出てきている日付も自分でビルドした時間になっているようだ。

fit.itbというファイルがない。
これはFPGAマガジンNo.12に書いてあったのだが、FITというのはLinuxカーネルとInitRam, Device Treeなどをパックしたもので、最近のU-bootはそれを使うのがデフォルトになっているらしい。
本では、uImageとDevice Treeを別々にして起動させるようにしているのだが、Yoctoが作ってくれたものはデフォルトで動いているということだろう。
そげなことせんでよかとに。。。
まあ、ファイルが少ない方が起動なんかは速くできそうだし、サイズも小さくしやすいのかも。

だが、ビルドしてくれたものにFITなどの名前が入ったファイルがない。
リリースページを見ると image.ubがFITファイルらしいが、そういうのもない。
ITSファイルをコンパイルしてITBファイルを作るみたいだから、DTSとDTBの関係みたいなものか？
しかし、itcというコンパイラはなさそうだし、そもそもITSファイルを持っていないからコンパイラだけあっても困る。

https://github.com/Xilinx/u-boot-xlnx/blob/master/doc/uImage.FIT/source_file_format.txt#L70
mkimage + dtcでFITファイルを作るようだ。
ramdiskって何だろうか？　initramfsみたいなものか？

ここは、考え方を変えてみよう。
fit.itbが無いというのは、autobootが出しているメッセージのようだから、手動だったらuImageでもよいのではなかろうか。
uImageをコピーして試してみよう。

Zynq> fatls
fatls - list files in a directory (default /)

Usage:
fatls <interface> [<dev[:part]>] [directory]
     - list files from 'dev' on 'interface' in a 'directory'
Zynq> fatls mmc 0:1
     63732   boot.bin
    439322   u-boot-dtb.img
   3741112   uimage

3 file(s), 0 dir(s)

Zynq> fatload mmc 0:1 0x00008000 uimage
reading uimage
3741112 bytes read in 360 ms (9.9 MiB/s)
Zynq> fatload mmc 0:1 0x00000100 uimage-zynq-zybo.dtb
reading uimage-zynq-zybo.dtb
9235 bytes read in 17 ms (530.3 KiB/s)
Zynq> bootm 0x00008000
## Booting kernel from Legacy Image at 00008000 ...
    Image Name:   Linux-4.9.0-xilinx-v2017.2
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    3741048 Bytes = 3.6 MiB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###

FPGAマガジンNo.12を真似して、uimage-zynq-zybo.dtbを0x1000に、uimageを0x8000に読込んだ。
あっちはbootzでfdtaddrを指定しているのだけど、うちのはhelpを見てもbootzがないのよねぇ。。。
FITを使うから不要だろう、ということか？

bootzを使えるように改造しているサイトもあるが、今回はそこら辺をやらずに進めたいのだ。
となると、FITファイルを作るしかないか。。。

[zybo]L16のクロックをロジアナで見よう

ソフトでタイマを使うときは、だいたいカウントダウンするレジスタに初期値を突っ込んでGO!というくらいだと思う。
まあ、分周とかそんなのはあるかもしれないが、基本的にはカウンタと同じイメージだ。

マイコンだとタイマユニットの数が決まっているので、違う分周で動かしたり、さらにカウンタを用意してソフト的に分周させたりさせるけど、FPGAだったら実はそこまで考えずに使えるものかもしれない。

まあ、そういう考察はさておき、自分が期待通りに操作できているかを確認するために、クロックをVHDLでカウントして、どっかのGPIOをパタパタさせたものをロジアナで計測してみるのは悪くないと思う。

50MHz・・・ってことよね？
PS_CLKにはそのまま入っているのに、L16にはPHYが挟まっているので、あまり自信がない。
RMIIは50MHzだったような気がするので、妥当なのかなぁ。

50M = 0x2FAF080ということで、32bitに収まる。
おっと待て、最上位が2だから、26bitでよいのか。。。と思ったが、28bitほしいといわれた。

これで計測すると、100KHzサンプリングでほぼ400msecになった。

architecture Behavioral of blink_led is
    signal counter : std_logic_vector(27 downto 0) := x"2FAF080";
    signal flag : std_logic := '0';
begin
    ld0 <= flag;
    
    process(clk)
    begin
        if clk'event and clk = '1' then
            counter <= counter - 1;
            if counter = x"0000000" then
                flag <= not flag;
                counter <= x"2FAF080";
            end if;
        end if;
    end process;

end Behavioral;

ええっと？
50,000,000回カウントして400msecということは・・・2.5倍の速度？

0x7735940にすると、だいたい1秒くらいになっているようだけど、うちのロジアナだとそんなに長いスパンは精度が保てないので、あきらめて10分の1にしよう。

値を0xBEBC20にして、400KHzで計測して、だいたい100msecと言ってよいだろう。

10進数だと、12,500,000。
12.5x10⁶回カウントして100msecだから、Hzに換算すると10倍して125MHzか。

ZYBOのマニュアルにも、125MHzという数字は出ていた。
めんどうがらずに、訳そう。

Zynq-Z7010のPL部は、2つのMMCMと2つのPLLを持っている。
4つのPS部のクロックも、125MHzの外部参照クロックも、MMCMやPLLの入力として使うことができる。

あ、もう少し続きがあった。

Figure 13(上の方に載せた図)はZYBOのクロック概略を示している。
Ethernet PHY空のクロック出力は125MHzの参照クロックとしてPL部が使う。

ああ、書いてあるとおりなんだ。。。

---

大したことはやらなかったけれども、計算した値で動かして、計算した結果を出すというのは、私の中では意味があることだった。
(計算結果は後付けだけどね)

わからんところは、ちょっとずつ潰していけばよいのだ。

[zybo]ibufの謎

Verilogでやろうかと思っていたけど、知ってる人がVHDL派だったので、私もVHDLでやることにした。
0を代入するのですらビット幅を合わせないといけないのだけど、そのくらい厳密な方がいいんじゃなかろうかね。

さて、まだまだ悩んでいるibufについてだ。

あらすじ

VerilogでLEDをチカチカさせるサンプルを真似して、それは動いた。
では、クロックを数えてチカチカさせるのではなく、ボタンを押した回数でチカチカさせようとした。
XDCファイルでbtnを有効にしているのだが、なぜかbtn_IBUFがどうのこうのといわれてしまう。

VHDL版のLEDチカチカも動かして、それを同じように変更すると、同じようにエラーが出た。
ただ、こっちはCLOCK_DEDICATED_ROUTEをfalseにしてやると、ボタンを押した回数でちゃんと動いた。
まあ、Verilogで書いたのがどこか間違っていたのだろうが、もうそちらは追うまい。

気にしているのは、CLOCK_DEDICATED_ROUTEをfalseにするだけが解決法なのか、他にもっとよい解決方法があるのか、だ。

---

https://www.xilinx.com/support/documentation/sw_manuals_j/xilinx2012_2/ug901-vivado-synthesis.pdf

このPDFを読むと、「デフォルトでは入力にIBUFが使用されます」と書かれている。
だから、誰も書いていないのに btn_IBUF というものができたのだろう。

これはBUFFER_TYPEというもののようで、文字通りバッファーのタイプを指定するものとのこと。
"ibuf"か"none"が指定できて、"none"の場合はバッファーを使用しないようにできるらしい。
じゃあ、そうしよう。

・・・エラーだ。

[DRC RPBF-1] IO port is missing a buffer: Device port btn should be connected to an IO cell such as an [IO]BUF*.

DRCというものがエラーを出している。
Design Rule Checkの略のようだから、ルールに反しているのか。
I/Oポートがバッファを見失ったようだが、「should be connnected」といっているので、バッファは必須なのだろう。
ちっ。

Vivadoで[Place 30-574]エラーが発生した時の対処法 | 彩の国・さきたま研究所

ほう。
専用のクロック配線が用意されているピンに変更すればよいのか。
・・・専用の？
PL部にはL16へクロックが供給されているからOK、という話ではないということか。

ZYBOのマニュアルでクロック部を見直すと「7 Series FPGAs Clocking Resources User Guideを読め」となっていた。
7 Series? と思ってマニュアルの先頭を読むと、PL部はArtix-7と同等品らしい。
FPGA初心者なのでよく知らんが、Xilinxといえば7 Seriesなのかもしれん。

---

https://japan.xilinx.com/support/documentation/user_guides/j_ug472_7Series_Clocking.pdf

うーん、用語がさっぱりわからん。。。

7 Seriesは4ファミリあって、Artix-7は「GTPトランシーバーからCMTおよびBUFMRへの直接接続はありません。GTPトランシーバーからCMTへの接続には、BUFHまたはBUFGが必要です」らしい。
さっぱりわからん。

IBUFで検索するか。
DCLK(ダイナミックリコンフィギュレーション基準クロック)、PSCLK(位相シフトクロック)に載っていたが、よくわからん。

https://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx13_3/7series_scm.pdf

これがIBUFなの？
なんか、よくあるバッファー、じゃないか。
これにクロックを挿すところがあるのかと思ったけど、これしか載っていない。

---

Vivadoでボタンに使っているY16を見てみると、こういう情報が出てきた。

Clock regionはX1Y0らしい。
このX1Y0にclkを突っ込めばよいのか？
でも、なんかそういう話でもない気がする。

---

vhdl - How to solve routing issues in Artix7? - Electrical Engineering Stack Exchange

単純に、clkが変化したタイミングでボタンの状態を見るようにすれば良いだけ？

やってみると、確かにエラーが出なくなった。
が、

process(clk, btn)
begin
     if clk'event and clk = '1' and btn = '1' then
        ...

という書き方になったので、ボタンを押している間もclkはパタパタしているからTRUEになってしまうのだった。

btnが一度LOになるのをチェックすればよいのだけど、それならCLOCK_DEDICATED_ROUTEをfalseにした方がまだシンプルだ。
あー、でもチャタリングの処理を書くのだったら、そういうイメージで実装する方が普通なのかな。
ソフトで書くときは、エッジ割込みのタイミングでタイマを動かしてポーリングしているのだけど、タイマの代わりにクロックが使えるから単に数えればよいだけか。

まだお作法がわかっていないのが、自分でも腹立たしい。
何を勉強するとよいのだろうねぇ。