2017/07/25

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (7)

前回(6)の続き。

ドライバを作って追加しようとしたが、ビルドに失敗したのだった。
こういうときは、PetaLinuxのリファレンスマニュアルを読もう。

ちゃんと、「Adding Custom Modules」「Building User Modules」という項目がある。
あ・・・そういうことか。。。



$ petalinux-build -c rootfs/led8drv

  ↓


$ petalinux-build -c led8drv


なんで私はrootfs/なんてのを付けようと思ったのだろうね。。。
あまりにガックリしたので、今日はここまで。

2017/07/24

[btc]ブロックのversion bits

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をそういう目的で使うのって、曖昧すぎじゃなかろうか。
それをわかってやってるのかもしれないけど、それにしてもねぇ。。。


2017/07/24 12:38追加

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には書かれてなさそうだから、そっちはそっちでまたあるのかね。


やっぱりよくわからんが、理解できるように追いかけなかったのは正解だった。。
こんだけ情報が早いと、ちょっとついて行けんねぇ。

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (6)

メモ。

前回、petalinux-create -t modulesでドライバのテンプレートを追加したが、ビルド時にエラーが出た。



AR# 68502: 2016.4 PetaLinux: Creating template module using underscores in naming convention causes build failures

名前にアンダーバーが入ってるとエラーになるって??
と思ったが、私は「led8drv」にしたから、入ってなかった。

ともかく、PetaLinuxというよりは、Yoctoに由来するエラーのようなので、そこら辺から探していくのがよいだろう。

2017/07/23

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (5)

動かん(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"を見ると今回作ったドライバが入っていた。

image

あとは、順番に実行せんといかんのか。

$ petalinux-build -c kernel
$ petalinux-build -c rootfs/led8drv

エラーになる。

ERROR: Nothing PROVIDES 'rootfs/led8drv'

ファイルを置き換えるだけではダメなのかと思ったが、元に戻してもエラーが出る。
既にあるGPIOのドライバと重複したからかもと考えたが、それだったらこういうメッセージにはならんよなぁ。


うーん・・・。
今週はこれでおしまいだ。

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (4)

動かん(3)の続き。

前回は、Vivadoのブロックに対する警告(同期リセット)を無視することにして、LEDとZyboをつないだところまでだ。
残りをやろう。
環境は、Vivado/XSDK v2017.2だ。


まず、Block Design画面で「LEDs_4Bits」のブロックをダブルクリックして、GPIO Widthを7に変更する。
今回はドットがないので7つでもよいはず。
Interface誌では8になっているので、ダメだったら考えよう。
奇数にするってのは、ちょっとドキドキしますな。


続いて、Sourceタブで「system.bdを右クリックするそうだ。
しかし、ファイルがたくさんあってわからん・・・。
検索しよう。

image

これが絞り込んだ結果らしい。
ちなみに、検索方法の設定はちょっと怪しかった(Vivado v2017.2)。
まあ、SとIだから、どっちがどっちかは大体分かるけどさ。。。

image


次はピンアサイン。
zybo_base_systemを使ったので、base.xdcというファイルになっていた。
Interface誌を見ると、こういう感じで修正するように書かれていた。

set_property PACKAGE_PIN V12 [get_ports {leds_4bits_tri_o[0]}]

V12はわかる。
これは、JEコネクタの1番ピンに紐付いているからだ。

image

では、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の図はこうなっていた。

image

あ・・・私まちがえてる。。。
Pin1は右上として、Pin2はその左隣なんだ。
下をPin2だと思ってたけど、一番左にPin6と書いてあるな。
写真ではわからんと思うが、修正しておこう。

image


base.xdcを直接編集してもよいが、せっかく専用のエディタがあるので、そっちを使おう。
Run Synthesisしておくと、I/O Planning画面が使えるようだ。
しかし、Run Synthesis自体がかなり長い・・・。
PCの性能はそんなに悪くないと思うのだが、10分以上かかったんじゃなかろうか。

ともかく、I/O Planningは選択できるようになった。

image

GPIOという名前が付いた項目がいくつかあるので、led関連を探すとこうなっていた。

image

よく考えたら、LEDs_4Bitsってボード上のLEDだろうから、新たにGPIOのブロックを追加すべきだったんじゃなかろうか。
まあいいや。

JEポートの1~9番を使っているので、それぞれ割り当てる。

image


あとは、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を読んだようなログも出ているし、間違いなかろう。
自分で作らなくてよかったんだっけ?

image


あるものは使おう。
手順ではCreate Zynq Boot ImageでBIFファイルを選ぶようになっているが、私のところにはBIFファイルが見当たらない。
「既にoutput.bifファイルがありますので」と書いてあるけど、ない場合は「Create new BIF file」でよいのだろうか。
しかし、これはこれでUDFファイルがいるようなのだ(importの場合もいるみたいだけど)。

image


どうも、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は何をするツールなのだ?


ザイリンクス ソフトウェア開発キット (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タブを検索すると出てきたのだが、チェックができない。。。

image

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」が見えている。

image

写真に詳しくないのだが、まだ明るい時間なのに、撮影したらこうなってしまった。
ともかく、カソード側は全部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)を指定すればよいようだが、はてさて。

長くなってきたので、今回はここまで。

2017/07/22

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (3)

動かん(2)の続き。


Zybo_base_systemを読込んだのだが、リセットが非同期だのどうのこうのと言われたのが前回。
いろいろ考えたが、考えても仕方ないということに気付いた。
まあ、リセットくらい大丈夫なんじゃないのか、ということにして、先に進めよう。


zybo_base_systemを読込むと、こういうブロックが既に入っている。
縮小しているので何があるかは見えないと思うが、ブロックがたくさんあるのは分かるだろう。
Ethernet0もMIOになっているので、気にするものはなさそうだ。

image

次は、GPIOを8ビットにして、LEDをつなぐ。
うちに7セグ2桁版があったのでそれを使おう。

7セグメントLED表示器 高輝度赤2文字 アノードコモン ボディ色グレー A-552SR: LED(発光ダイオード) 秋月電子通商 電子部品 ネット通販

よく考えたら、7セグを使うのは初めてだ。

image  image

え、こんだけ??

image

この並びで見て、左下から右が1~9ピン、上に上がって、右上から左が10ピンから18ピン。
まあ、普通のICと同じ配置ではあるけど、書いてくれないと心配になるじゃないか。。。

なんとなく、LEDを直接挿すのはよくないというのは覚えている。
電流が大きすぎるんだったっけ。
いや、直列だから電流は同じなので、かかる電圧を下げるためか?

電流だった。
hiro99ma blog: [arduino]なんでLEDにつける抵抗が220Ωなのか
[LED] LEDと抵抗の計算2/流したい電流と最適な抵抗 - mathrax2010-led
ああ、LEDに流れる電流を制御するんじゃなくて、全体の電流を制御するために抵抗値で調整しているだけだった。

光ればよいので何でもいいんだけど、たまには計算してみよう。
順電圧と流したい電流値がわかれば計算できるそうだ。
A-552SRは、VF(Forward Voltage)のtypが1.8Vで、IFは20mA。

ということは、20mA流すように調整して、そのときのLEDは1.8Vくらいになっているということか。
電源が3.3Vだと、LEDに1.8V、抵抗に1.5Vかかるから、1.5Vで20mAになる抵抗値にすれば良いことになる。

R = 1.5 / (20x10-3) = 1500 / 20 = 75 ohm

まあ、そんなのないから、75Ωより大きくて、大きすぎない抵抗を使うしか無い。
これを7本も用意せんといかんのか・・・。

image

抵抗器が新品だったこともあり、ちょっとした生け花みたいになってしまった。

image


あとは、これとZYBOをジャンパケーブルでつなげてやると、もう何が何だか。
ショートするのは嫌だから、マスキングテープで軽く留めることにした。

image


さて、外側はこれで終わりなので、次は中身ですね。

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (2)

チュートリアルが動かん(1)の続き。

あらすじ

Zyboのチュートリアルは、書いてあるとおりにやれば動いた。
最後にCで書いて、Eclipse(XSDK)で動かしているからLinuxで動いている感じはするのだが、ちょっと違う気もする。
せっかくだから、PetaLinux v2017.2で動かしたい。

このチュートリアルは、Zyboのページに貼ってあったものだ。
よく見ると、他にもたくさんリンクが貼ってあった。

Zynq BookのTutorialはPDF版を無料でダウンロードできるので、それを見るのもよいかもしれん。
The Zynq Book: Download The Zynq Book Tutorials

が、今日は気力が無いので、Interface誌2016年4月号の連載(PDF)を読むことにした。
Zyboもそんなに新しくないので、Digilent社は最新のVivadoに対応していないから、過去の情報だと動かないような気がするのだよ。


内容は、7セグを操作する、というLチカの発展系みたいなものだ。
4ページに収まっているので、気力が無くても読める。
ちなみに、1つ前の3月号では、Vivado HL WebPACK EditionでC言語喜寿ルから回路を合成する説明をしている。


まず、リファレンス・デザインというものをプロジェクトテンプレートのようにして使っている。
base_system_designと書いてあるので、これ(zip)か?
展開するとファイルがいくつもあるが、source\vivado\hw\zybo_bsd\zybo_bsd.xprか?
今回はVivado 2017.2を使うのだが、大丈夫だろうか。。。

開くと、古いプロジェクトということでアップデートしてくれた。
最後にこういうダイアログが出てきたが、気にしなくてよいのかな。

image

OKすると、もう1つダイアログが出てきた。

image

「Report IP Status」をクリックして、設定項目がなくなったものに関する推奨する操作を見せてもらおう。
全部、バージョンが古いだけのようだ。

image

どうしたらよいのか困っていたら、一番下に「Upgrade Selected」というボタンが表示されていた。
進めると、勝手にアップデートしてくれている。

critical messageのダイアログが出てきたが、その上にGenerate Output Productsダイアログが出てきた。
何か知らんが、生成しておこう。

critical messageはたくさん出ているが、こういう内容だ。

[BD 41-1348] Reset pin /axi_dispctrl_0/s_axi_aresetn (associated clock /axi_dispctrl_0/s_axi_aclk) is connected to asynchronous reset source /processing_system7_0/FCLK_RESET1_N.
This may prevent design from meeting timing. Please add Processor System Reset module to create a reset that is synchronous to the associated clock source /processing_system7_0/FCLK_CLK0.

よくわからんが、System Reset moduleを追加せよ、と書いてある。
+アイコンを押して検索すると「Processor System Reset」が見つかったので、追加して、Auto Connectionした。
メッセージをクリアして、Validate Designを行ったが、まだ残っている。

[BD 41-1347] Reset pin /axi_dispctrl_0/s_axi_aresetn (associated clock /axi_dispctrl_0/s_axi_aclk) is connected to asynchronous reset source /processing_system7_0/FCLK_RESET1_N.
This may prevent design from meeting timing. Instead it should be connected to reset source /proc_sys_reset_0/peripheral_aresetn.

追加してくれ、が消えただけか。
接続はAutoではやってくれんのか。。。

/axi_dispctrl_0/s_axi_aresetnにつながっているのは橙色の線だから、これに左側のperipheral_aresetnをつなげばよいのか?
「今は/processing_system7_0/FCLK_RESET1_Nにつながってるけど、そっちは非同期リセットだから、/proc_sys_reset_0/peripheral_aresetnにつなぐとよいよ」といっているのかしら。

image

processing_system7_0/FCLK_RESET0_Nと1_Nとの接続を外して、その線にperipheral_aresetnをつなぐだけでよいかと思ったのだが、FCLK_RESETx_Nを消すと全部の線が消えてしまった。。。
仕方なく、1つ1つポートを選んで接続し直した。
もっと他の方法がありそうだけど、どうなんだろう。
(あとで、コンテキストメニューからピン単位の切断があることを知った。)


つないでチェックし直したが、別のが出てきた。

[BD 41-759] The input pins (listed below) are either not connected or do not have a source port, and they don't have a tie-off specified. These pins are tied-off to all 0's to avoid error in Implementation flow.
Please check your design and connect them as needed:
/axi_dispctrl_0/s_axis_mm2s_aresetn
/axi_dispctrl_1/s_axis_mm2s_aresetn
/axi_i2s_adi_1/DMA_REQ_TX_RSTN
/axi_i2s_adi_1/DMA_REQ_RX_RSTN
/axi_mem_intercon/ARESETN
/axi_mem_intercon/S00_ARESETN
/axi_mem_intercon/S01_ARESETN
/axi_mem_intercon/M00_ARESETN

つなぎ足りなかったのか?
全部つないだが、まだなんか出てくる。

[BD 41-1343] Reset pin /axi_dispctrl_0/s_axis_mm2s_aresetn (associated clock /axi_dispctrl_0/s_axis_mm2s_aclk) is connected to reset source /proc_sys_reset_0/peripheral_aresetn (synchronous to clock source /processing_system7_0/FCLK_CLK0).
This may prevent design from meeting timing. Please add Processor System Reset module to create a reset that is synchronous to the associated clock source /axi_dispctrl_0/PXL_CLK_O.

PXL_CLK_0につなげ?
さっきはperipheral_aresetnにつなげって言ってたじゃないか!

さすがに何か間違っている気がするので、やり直そう。


ここは、誰かもアップグレードによって同じ目にあっているはずだから、検索してみるべきだ。


2. Zynq Digilentからプロジェクトをもらってくる – yuki-sato.com

Processor System Reset というIPを追加して配線すれば良いのですが、大変ですし今回はこれでも動くのでここまま進みます。

えー。。。

もしかしたら、先にprocessorのリセット接続を消してからSystem Resetを追加したらAutoでやってくれるんじゃなかろうかと思ったが、そうはいかんかった。。


ちゃんと警告内容を読もう。
FCLK_CLK0をソースにしたリセットになっているから、PXL_CLK_0をソースにしたリセットにしなさい、ということかな?
そしたら、それぞれのクロックをソースにしたSystem Resetを追加せんといかんの??

うーん、さすがにそこまではしなくてよいのではないか、という気がしている。
そもそも、Zynqを中心にしたシステムだから、Zynqのリセットにあわせてしまってもよいんじゃないのかい?
それだと回路的によろしくないのだろうか。
わからん。。。。

2017/07/20

[c/c++]エンディアン変換

よく行う処理に、エンディアン変換がある。
バイトの順番を入れ替えるだけではあるが、しょっちゅう出てくると気になってくる。

機械語で何か用意されていないだろうか、ということだ。
エンディアンの変換はかなり地味な作業だが、それなりに発生するので、1命令で実行できるようになっていたりせんだろうか。
あるいは、コンパイラが組込みライブラリで用意してくれているとか。


この辺りを読むと、GCCにbuilt-inの関数がありそうだ。
c++ - Fast conversion of 16-bit big-endian to little-endian in ARM - Stack Overflow
swap - convert big endian to little endian in C [without using provided func] - Stack Overflow


一番下に、3つAPIがあった。
Using the GNU Compiler Collection (GCC): Other Builtins

  • __builtin_bswap16()
  • __builtin_bswap32()
  • __builtin_bswap64()

アンダーバーが2つついているので、GCC専用というのをありありとうたっている。
ものすごく速度を要求されるようなことがあれば、こっちを使った方が良いのかもしれん。
ARM命令だったかThumb命令だったか忘れたけど、直値のビットシフトがあまり得意じゃなかった記憶があったのだが、他のなにかと間違って覚えてしまっていたのかも。


バイトの順番を入れ替える処理って、C/C++の標準ライブラリにはないし、見た目も普通に計算しているだけだから、コンパイラが最適化してうまいことやってくれるのを期待するのが難しい気がするのだ。
C11なんかで追加されているのを期待したが、Cクイックリファレンスにはなさそうだった。
やるんだったら、#pragmaなんかで「ここはエンディアン変換しています」みたいな目印を書くとか、そういう方向になるんだろうか。

2017/07/19

[勉]ECDHのshared secret

FPGAのことばかりやっているように見えるが、実はほとんどやっていない。
やりかけの作業があると、あまり集中できなくてね。


そのやりかけの作業が、ECDHだ。
楕円曲線ディフィー・ヘルマン鍵共有 - Wikipedia
なんか、字面だけで威圧感を与えられるし、説明文も読んでいて訳がわからんごとなってくる。

が、実装だけで言えば、秘密鍵を作り、楕円曲線の公開鍵を作り、その公開鍵をお互いが交換して、自分の秘密鍵ともらった公開鍵を乗算したものを共有鍵とする、というだけのことだ。


ネットで見ても、本で読んでも、そこまでは説明してある。
が、だ。
秘密鍵は、値だ。
公開鍵は、楕円曲線上の座標だ。
両者を乗算すると、楕円曲線空間での乗算ルールに従って計算される。
その結果は、楕円曲線上の座標になる。


それでは困るのだ。
秘密鍵は、単なる鍵なので、座標なんかで表されると計算に使えない。
なんらかの数値に変換して欲しいのだ。

Wikipediaでは、

ECDHを元にしたほとんどの規格化プロトコルでは、この秘密を元に、ハッシュ関数などを利用して共通鍵を生成する。

と、曖昧に書かれている。
曖昧というか、得られた座標から共有鍵を生成する方法に規定はないということを言っているのだ。


ちなみに、私がよく使うmbedTLSでは、単にX座標を使うようになっていた。
https://github.com/ARMmbed/mbedtls/blob/development/library/ecdh.c#L77

だが、このやり方がすべてというわけではなく、それ以外もありうるので、実装する人は注意しよう。

ああ、仕様をよく確認して注意するのがよいさ、私のように数時間悩まないようにね。。。

2017/07/17

[zybo]PetaLinuxでDigilentのチュートリアルが動かん (1)

前回、PetaLinuxでEthernetが使えるようになった。
が、それだけだ。
「完」などとタイトルに付けてみたものの、何も終わっていないというか、これから始まるところじゃないか。


まずは、Digilentのチュートリアルをやろう。
よくわからんが、チュートリアルをちょっといじったHardware設定をimportしたPetaLinuxだから、最後にデバッガで動かしている実行ファイルをPetaLinux上で動かせばいいんじゃなかろうか。

そんな安易な考えだったのだが、動かなかった。
Illegal Instruction。
fileコマンドで見ても、

getting_started_with_ZYBO.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

となっているので、CPUも間違ってないし、あまり悪いもののように思えない。

もちろん、SDx(SDSoCの環境を使っているので)からRun Asで実行すると動くのだが、そうするとPetaLinuxはもう動けなくなるようだ。
コンソールは入力できないし、pingも応答がなくなる。


どうも、私の想像とは違いそうだ。
こういうときは、FPGAマガジンNo.12を読もう。


3章に、PS部の設定を行う手順があった。
ここでPlatfrom Studioの画面で「Import XPS Settings」で設定をインポートさせていた。

XPSファイルは、Zybo Base(zip)のzybo_base_system\source\vivado\hw\lib\xml\ZYBO_zynq_def.xmlだろう。
こんな行もあるので、EthernetがLinuxから使えるようになるんじゃなかろうか。

<set param="PCW::ENET0::GRP_MDIO::IO" value="MIO 52 .. 53" />
<set param="PCW::ENET0::GRP_MDIO::ENABLE" value="1" />

こちらでも、同じような作業をしている。
4. Zynq VivadoでZYBO向けプロジェクト作成からBitstream出力まで – yuki-sato.com
ただ、プロジェクトを作るところでボードの選択ではなくZynqを選んでいる。
それに、XPSをインポートするとUART1などにチェックが入るように書かれているが、うちでは最初からチェックされていた(Run Block Automationを実行した後だが)。
そう考えると、ボードのファイルであるboard_filesにZynqの設定も書いてあるのかもしれない。


まずはXPSを読込んでみようとしたが、うちのVivado v2017.1(SDxに同梱されていたもの)でやっても、OK/Cancelのボタンしか表示されない。

image

Vivado v2017.2も同じだった。

Can't import XPS settings from .xml file in Re-Cus... - Community Forums
最後の書込みがXilinxの人でstill not fixedとなっているから、v2017.1/2のバグなのか。。。

TCLコマンドならできそうに書いてあるのでやってみたが、エラーになる。

set_property -dict list CONFIG.PCW_IMPORT_BOARD_PRESET "D:\Prog\Xilinx\ZYBO_zynq_def.xml" get_bd_cells processing_system7_0

ERROR: [Common 17-161] Invalid option value 'CONFIG.PCW_IMPORT_BOARD_PRESET' specified for 'objects'.

ああ、[]は省略可能の意味じゃなくて、そのまま書かんといかんのか。

set_property -dict [list CONFIG.PCW_IMPORT_BOARD_PRESET "ZYBO_zynq_def.xml"] [get_bd_cells processing_system7_0]

こうなった。

image

いやいや、全部消えてしまったじゃないか!
あ、このコマンドって、ファイルが読めなくてもエラーを出さずに終わるし、しかも設定を消しやがるんだ。
そして、パスはCygwin風に書かないといかんらしい。

これがちゃんとファイルを読んだときのメッセージだ。

set_property -dict [list CONFIG.PCW_IMPORT_BOARD_PRESET d:/Prog/Xilinx/ZYBO_zynq_def.xml] [get_bd_cells processing_system7_0]

INFO: [PS7-1] Applying Custom Preset d:/Prog/Xilinx/ZYBO_zynq_def.xml...

image

Ethernetは使えそうなのだけど、importするのと、手動でMDIOに変更するのはどちらが幸せなのだろうか?
幸せというのは、のちのち問題が少ないとか、憂いが少ないくらいの意味合いだ。

importする前はこうで、赤で囲んだり文字を書いたのが差分だ。
たぶん、ここに見えているものはPL部から制御できて、見えなくなったものはPS部から制御できるんじゃなかろうか。

image

比較したら何か決め手があるかと思ったのだが、よくわからん。
そもそも、プロジェクト作成時のBoard選択にせよ、このimportファイルにせよ、何が書かれているかわからんのがいかん。
自分でボードを作るようなことがあれば、この辺も編集できんといかんだろう。


まあ、今回はスルーするが、importするという手段があることは覚えておこう。
そして先は長そうだから、今回はこれまでだ。

2017/07/16

[zybo]PetaLinux (10) - 完

前回、ZynqのGPIO52, 53がGPIOのままになっていることに気付いた。
そこで、VivadoのPlatform StudioでPeripheral I/O Pinsを変更し、Ethernet 0のMDIOがEMIOになっていたものをMDIOに切り替えた。

今回、試すときだ。

まず、HTMLのMIO Table Viewを確認しよう。

image

うむ、あれでよかったようだ。

新しいHardwareファイル(というのか?)でpetalinux-configで何もせずExitし、petalinux-buildし、イメージファイル類を作って、あとは動かすだけだ!


実は、一度ここでプロジェクトを消して作り直した。
理由は分からないが、「Starting kernel ...」のログまでしか出なくなったからだ。
MIO 52,53の設定をしたためかと思ったが、戻してもだめだった。
そういうときは、やり直すまでだ。


結果は・・・OK!

■U-Bootのところ
Net:   ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
eth0: ethernet@e000b000

ethernet@e000b000 Waiting for PHY auto negotiation to complete.... done
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.0.83 (524 ms)


■BogoMIPSのところ
Calibrating delay loop (skipped), value calculated using timer frequency.. 650.00 BogoMIPS (lpj=3250000)


■PHYのところ
libphy: Fixed MDIO Bus: probed
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:1e:53)
RTL8211E Gigabit Ethernet e000b000.etherne:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.


DHCP環境だから、U-Bootの段階でIPアドレスがとれているようだし、ifconfigで見てもとれていた。
もちろん、pingも打てた。
そうか、そういうものなのか。。。


おそらく、だが、Ethernetの部分はPS部もPL部も使えるようになっていて、デフォルトではPL部が使う(EMIO)ようになっていた、ということではなかろうか。

喉の小骨が取れたようにすっきりした。

2017/07/15

[zybo]PetaLinux (9)

前回のあらすじ

・BogoMIPSがEthernetが動作している人のログと違う
・クロックの設定が間違っているとか、そこら辺から見ていくか
・Zynqの設定っぽいHTMLが出力されているので、その差分を見るのが早そう

HTMLも2.9MBくらいあって、そう簡単に比較できないのだ。
クロック以外にも差分はあるだろうから、慎重に見ていこう。


まず出てきたのが、MIO52,53の設定。
私はgpio[52], gpio[53]になっているのだが、Digilentの方はEnet0のmdc, mdioになっているのだ。
これはあからさまにあやしいんじゃなかろうか。

image

左がZynq、右がRealtek RTL8211Eを表しているのだが、これが接続されていないということか。


しかし、これはどうやっていじるものなのだ?
マイコンだったら、レジスタでピンアサインを変更したりするものだが、Linuxだしなぁ。

HTMLの表の名前が「MIO Table View」になっていたので検索した。
Using the Zynq MIO Table View
Platform Studioというアプリなのか?
Zynq Tabへのリンクがあったが、こんな画面は見たことがない。
ブロック図の接続なんかを表しているようだけど、そういうのはSDx IDEでチュートリアルをやったときの画面くらいか。

【Zynq】ZYBOでPSのMIOを使用してLチカしてみた
これを見ると、MIOにGPIOを割り当てるような作業をしている。
同じようなことをZYBOのチュートリアルでやったが、それでできたファイルをPetaLinux (1)で与えていたことを思い出した。
あのときは中身も見ずにディレクトリを指定しただけだったのだけど、よく見るとこの中にHTMLファイルが入っているではないか。

では、そのディレクトリをDigilentのhw-descriptionにしたらどうなるだろうか?
バージョンの違いが出てこなければよいが。。

petalinux-config --get-hw-description=../design_1_wrapper_hw_platform_0

とりあえずエラーにはならなかった。

petalinux-buildして、imageをつくって、動かす。
残念、kernel panicだ。
やはりバージョンが違うからダメか。


Vivadoでチュートリアルで作ったプロジェクトを開き、Open Block Designでブロックを開いた。
「+」でダイアログを開いてEthernetを検索。。。いくつか出てくるが、どれがよいのだ?
GPIOの時はAXI_GPIOだったので、AXI 1G/2.5G Ethernet Subsystemにした。
そして、自動で接続してもらう。
RGMIIのようなので、それを選択。

image

うーん、ZynqのMDIOの方がどこにも接続されていない。
というか、AXIを追加しなくても、このピンアサインだけ設定すればよいんじゃなかろうか?

よくわからんので、Zynqのブロックをダブルクリックした。

image

あ、これはさっきのPlatform Studioではないか。

MIO ConfigurationでI/O Peripheralsを見ると、ENET0はMIO16..27になっているので、これは大丈夫だろう。
あとは、MIO52とMIO53だ。
これがMDCとMDIOになってほしいのだけど、どこだ?

Peripheral I/O Pinsを開いて検索すると、こうなっていた。

image

EMIOがアクティブ?っぽいので、MDIOをクリックすると、そっちが緑色になった。
これでよいのだろうか・・・。

最初にやったAXIの追加はやらない方がよさそうな気がするので、全部やり直して、上記のPeripheral I/O Pinsの設定だけにした。

あとはチュートリアルに従ってやっていくだけなのだが、今日は時間切れだ。。。

[zybo]PetaLinux (8)

kernelは、PetaLinuxをインストールした場所ではなく、プロジェクトを作った場所にあった。
その都度ダウンロードしているということか。。。そりゃ重たいわ。


では、前回の続きから追っていこう。
まずはBogoMIPS計算の箇所を確認。

build/tmp/work-shared/plnx_arm/kernel-source/init/calibrate.c

私がビルドしたときのようなログ

Calibrating delay loop (skipped), value calculated using timer frequency.. 650.00 BogoMIPS (lpj=3250000)

が出るためには、printedが0で、lpj_fineが非0でなくてはならん。
オリジナルなんかは、

Calibrating delay loop... 1292.69 BogoMIPS (lpj=6463488)

だから、if文を全部くぐり抜けて、elseでcalibrate_delay_converge()を呼ぶことによってlpjを取得しているのだろう。

私もそうしたい。


skippedのときはきれいな値なので、おそらくkernelのconfigで、何かの設定値を0以外にするとその値をプリセット値としてしようするとか、そんな作りになっているんじゃなかろうか。
しかし、どこになにがあるやらわからんし、そういう値がどこにあるかも知らない。

ディレクトリを眺めていると、./project-spec/hw-description/ps7_init.htmlというファイルがあった。

image

おお、なんか設定値らしきものがたくさん載っているぞ。
ZynqのPS部レジスタ値一覧みたいだから、これを元に考えていくのがよいんじゃなかろうか。


PS Reference Clockが50.0になっているが、IC22が50MHzだから、これはよいように思う。
まさか、単位がHzってことはないだろう。

次に目立つのは650MHzで、これは「CPU 6x Freq」らしい。
私がビルドしたときのBogoMIPSは650.00だから、これが1300くらいになるということだろうか。
しかし、リファレンスマニュアルでは50MHzのINPUTがCPUの650MHzとDDR3の525MHz(DDRだから1050Mbps)になるようなことを書いている。
うーむ。

幸い、Digilentのpetalinux-bspsにもHTMLファイルがあった。
こちらも、CPU 6x Freqは650だ。
じゃあ、ここじゃないな。


しかし、見比べることができる!
比較すると、クロックのところだけしか見ていないが、FPGAx Freqのところが違っている。


image


petalinux-bsps
image


これが影響しているのかどうかはわからないが、ずいぶん違うな。


まずは目視で比較しようとしたが、とてもできそうな量ではなかった。。
WinMergeで見たところ、そんなに多くはなかったのだが、それでも191箇所。
今日で見終わることはできないな。

2017/07/13

[zybo]PetaLinux (7)

(2017/07/13 21:59:タイトルが6番になっていたので、7番に修正)

まず、Digilentが提供しているpetalinux-bspsの、ビルド済みを動かしてみよう。
BOOT.BINとimage.ubをSDカードにコピーするだけだ。

libphy: MACB_mii_bus: probed
mdio_bus e000b000.etherne: /amba/ethernet@e000b000/mdio has invalid PHY address
mdio_bus e000b000.etherne: scan phy mdio at address 0
mdio_bus e000b000.etherne: scan phy mdio at address 1
mdio_bus e000b000.etherne: scan phy mdio at address 2
mdio_bus e000b000.etherne: scan phy mdio at address 3
mdio_bus e000b000.etherne: scan phy mdio at address 4
mdio_bus e000b000.etherne: scan phy mdio at address 5
mdio_bus e000b000.etherne: scan phy mdio at address 6
mdio_bus e000b000.etherne: scan phy mdio at address 7
mdio_bus e000b000.etherne: scan phy mdio at address 8
mdio_bus e000b000.etherne: scan phy mdio at address 9
mdio_bus e000b000.etherne: scan phy mdio at address 10
mdio_bus e000b000.etherne: scan phy mdio at address 11
mdio_bus e000b000.etherne: scan phy mdio at address 12
mdio_bus e000b000.etherne: scan phy mdio at address 13
mdio_bus e000b000.etherne: scan phy mdio at address 14
mdio_bus e000b000.etherne: scan phy mdio at address 15
mdio_bus e000b000.etherne: scan phy mdio at address 16
mdio_bus e000b000.etherne: scan phy mdio at address 17
mdio_bus e000b000.etherne: scan phy mdio at address 18
mdio_bus e000b000.etherne: scan phy mdio at address 19
mdio_bus e000b000.etherne: scan phy mdio at address 20
mdio_bus e000b000.etherne: scan phy mdio at address 21
mdio_bus e000b000.etherne: scan phy mdio at address 22
mdio_bus e000b000.etherne: scan phy mdio at address 23
mdio_bus e000b000.etherne: scan phy mdio at address 24
mdio_bus e000b000.etherne: scan phy mdio at address 25
mdio_bus e000b000.etherne: scan phy mdio at address 26
mdio_bus e000b000.etherne: scan phy mdio at address 27
mdio_bus e000b000.etherne: scan phy mdio at address 28
mdio_bus e000b000.etherne: scan phy mdio at address 29
mdio_bus e000b000.etherne: scan phy mdio at address 30
mdio_bus e000b000.etherne: scan phy mdio at address 31
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 147 (d8:80:39:5e:8a:d6)
macb e000b000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2014 Intel Corporation.


(中略)

macb e000b000.ethernet eth0: link up (100/Full)

link upしているし、DHCP環境でIPアドレスもとれている。
pingもできた。


よし、ここから始めよう。
でも、眠たいので次回だ。


2017/07/13 22:00

QSPI、Digilent、自分の3つログがあるので、見比べてみた。

差分が簡単にとれないので、目に付いたところから調べていこう。
今回は、ここ。


QSPI
Calibrating delay loop... 1299.25 BogoMIPS (lpj=6496256)

Digilent
Calibrating delay loop... 1292.69 BogoMIPS (lpj=6463488)


Calibrating delay loop (skipped), value calculated using timer frequency.. 650.00 BogoMIPS (lpj=3250000)


私のだけログの出方が違うし、スピードも半分くらいしか出てない。
lpjというやつが半分くらいしかないためだろうか?
これまでで、一番解決しそうな手がかりだ。


まず、どういう値なのか。
有効となったCPU数と各CPUのBogoMIPS値の合計を示すメッセージ - ZDNet Japan

由来などは、Wikipediaに出てくるだろうから、それを読んでおくれ。

そして、lpj。
CPUのBogoMIPS値を計算した結果を表示するメッセージ - ZDNet Japan

lpjからBogoMIPSの値を計算しているようだ。
そして、その値の関係に違いは無い。

QSPI
1299.25 / 6496256 = 200 x 10^-6

Digilent
1292.69 / 6463488 = 200 x 10^-6


650.00 / 3250000 = 200 x 10^ -6

QSPとDigilentは199.9999...となるので、もう200にした。


それにしても、私のBogoMIPSはあまりにきれいな値すぎないか?
まさか、(skipped)って、BogoMIPSの処理をスキップして、何か設定値を使っているというなのか。


PetaLinuxでインストールされたkernelの場所はわからんかったが、init/calibrate.cのcalibrate_delay()にあるようだ。
短い関数なので、まるまる載せよう。
違うkernelなのだが、そこまで変わらんだろう。

void calibrate_delay(void)
{
	unsigned long lpj;
	static bool printed;
	int this_cpu = smp_processor_id();

	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
		lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
		if (!printed)
			pr_info("Calibrating delay loop (skipped) "
				"already calibrated this CPU");
	} else if (preset_lpj) {
		lpj = preset_lpj;
		if (!printed)
			pr_info("Calibrating delay loop (skipped) "
				"preset value.. ");
	} else if ((!printed) && lpj_fine) {
		lpj = lpj_fine;
		pr_info("Calibrating delay loop (skipped), "
			"value calculated using timer frequency.. ");
	} else if ((lpj = calibrate_delay_is_known())) {
		;
	} else if ((lpj = calibrate_delay_direct()) != 0) {
		if (!printed)
			pr_info("Calibrating delay using timer "
				"specific routine.. ");
	} else {
		if (!printed)
			pr_info("Calibrating delay loop... ");
		lpj = calibrate_delay_converge();
	}
	per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
	if (!printed)
		pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
			lpj/(500000/HZ),
			(lpj/(5000/HZ)) % 100, lpj);

	loops_per_jiffy = lpj;
	printed = true;

	calibration_delay_done();
}

今回は、3番目のルートを通ったログを見ていることになる。
よって、lpjはlpj_fineという値を参照している。

困ったことに、lpj_fineはこのファイル内に定義してあるものの、ファイル内では参照しているだけだ。
staticではないので、グローバル変数扱いか。
ちっ。


[PATCH 1/2] ARM: delay: set loops_per_jiffy when moving to timer-based loop

lpj_fine			= freq / HZ;

なので、周波数を周波数で割った値のようだ(timer->freq/HZ、というソースもあった)。


ここから一気に押し進めたいところだったが、ログの出方がそれぞれ違うので、簡単には追えないのだ。
眠たいので、今回はここまで。

2017/07/12

[zybo]PetaLinux (6)

日課というか、日記に近くなってきた。
同じようなことばかりやっているので、あらすじを載せよう。

あらすじ

ZYBOに新しいkernelを載せたいので、PetaLinux v2017.2をインストールした。
kernelは動いたものの、Etherenetが動かないので調査中。

たったこんだけなのだが、連載の2番以降はずっとこれだ。


今朝は目線を変えて、RTL8211Eについて調べることにした。
私の起動ログには「Generic PHY」と出てくるのだが、ZYBOに載っているのはRTL8211E。
ネットで検索すると「RTL8211E」と出ているものが多い。
だから、私もそうなる努力をすべきじゃなかろうかと思うのだが、エラーになっていないので少し迷う。。

最初に見ていた「電気回路/zynq/Petalinux のビルド - 武内@筑波大」をみると、こちらはGeneric PHYで接続できているようだ。
バージョンが違うとはいえ、PetaLinuxだし、MACBだし。

また、「RTL8211E linux」で出てきたこちらでは「Generic PHY support is enough to make it work.」といっているので、Generic PHYでも問題ないんじゃなかろうかという気になってきた。


この人も動かなかったようだが、解決方法の毛色が違った。

Solved: Question about Linux on my Zynq - Community Forums

eth0は外部クロックだったからIO PLLにしたら動いた、とか何とか。


この部分かな?

image

IC22は、DSC1121CE5だ。

image

でも、これって直接ETH_CLKにつながっているから、設定も何もないんじゃないの?

image


ETH_CLKはIC1で、IC1はRTL8211Eだ。
あ、これがMDIOなの?
ZynqのGPIOか何かかと思ってたが、MIOがZynq側で、MDIOがRTL8211側だ。

image

ACTやLINKのLEDはPHYにつながっていて、LINKは点灯、ACTはたまに点滅している

root@petazybo:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:1E:53
           UP BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:220 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:25334 (24.7 KiB)  TX bytes:0 (0.0 B)
           Interrupt:145 Base address:0xb000

正しいデータかわからんが、RXがあるから、何か受信していないことはないようだ。
ifconfigでIPアドレスを与えてもpingできんけどね。


よし、方針転換して、Generic PHYのままでOKと見なして、クロックとか設定とか、その辺を見ていくことにしよう。


[zybo]PetaLinux (5)

毎日暑いですね(これを書いているときは夏)。
汗で肌がペタペタします。
ん、ぺたぺた?
そういうときは、PetaLinuxだ!
・・・済みません、疲れてます。


なんとなくこうじゃないか、でEthernet PHYを解決するのは無理そうなことが分かってきたが、エラーも出ないのでよくわからないという状況だ。
前回の最後で、Hardentというところのファイルを2つダウンロードしたのだけど、眺めてもそれっぽいものが見当たらなかった。
まあ、見て分かるほど熟練していないせいかもしれないが、少なくとも簡単にわかりそうなものはなかった。


方針としては、Generic PHYではなく、ZYBOで使われているRTL8211EのPHYを探す、ということにした。
もし見つかって、入れてもダメだったら、また考えよう。

となると、まずはkernelのconfigからだろう。
PetaLinuxではpetalinux-configを使っているが、そもそもどういうオプションがあるのだろうか。

$ petalinux-config --help
petalinux-config             (c) 2005-2013 Xilinx, Inc.

ERROR: You are not inside a PetaLinux project. Please specify a PetaLinux project!
Configures the project or the specified component with menuconfig.

Usage:
   petalinux-config [options] {--component <COMPONENT> |--get-hw-description[=SRC] |--searchpath <--ACTION> [VALUE]}

Options:
   -h, --help                      show function usage
   -p, --project <PROJECT>         path to PetaLinux SDK project.
                                   default is the working project
   --oldconfig                     takes the working configuration
   -c, --component <COMPONENT>     Specify the component
                                   If no component is specified, it will do
                                   top level subsystem configuration only
                                   project: to configure the whole project
                                   If you specify other component,it will
                                   configure that component
                                   E.g. -c rootfs
   --get-hw-description [SRC]      get hardware description.
                                   if [SRC] is specified, look in that
                                   location for an Vivado export to SDK directory.
                                   Otherwise, this MUST be run from
                                   WITHIN the vivado export to SDK directory.
   --defconfig [DEFCONFIG_TARGET]  defconfig the specified component.
                                   It only applies to kernel for now.
   -v, --verbose                   verbose mode

「-c kernel」でkernelの設定ができたのだが、kernelとrootfs以外にcomponentがあるのだろうか?

まあいい、普通にkernelのconfigを見ておこう。

image

うーん、いきなり当てが外れた。
悔しいので、他のPHYは外して、RealtekとXilinxの2つ(画像の下2つ)にチェックしてみよう。

Ethernet Driverもたくさんあるけど、Cadence MACB/GEM、Intel PRO/100 PCI-Express Gigabit、Intel(82586/82593/82596)、あとはXilinx devicesをデフォルトのままにしてみる。

うん、ダメだね。
Generic PHYだったよ。


それ自体はもうよいのだけど、kernelのconfigまで気にしだしたということは変数が2つになったということなので、もしどちらも条件が一致しないと動作しないようであれば、ますます解決が難しくなりそうだ。

まあ、疲れているときに考えてもよいアイデアは出ないので、寝よう。

2017/07/10

[zybo]PetaLinux (4)

ログの中に"macb"というものがあったが、これはネットワーク関係らしい。

Xilinx Wiki - Macb Driver

ログに出ているくらいだからドライバとしてはビルドできているのだろう。

設定場所はかなり深い。。。
Cadence MACB/GEM supportまであればよさそうだ。
extendedはZynqMP専用か。

image


devicetreeの説明もあるが、値の意味がわからん。
えーい、そのまま使ってしまえ!

gem0: ethernet@e000b000 {
	compatible = "cdns,gem";
	reg = <0xe000b000 0x1000>;
	status = "disabled";
	interrupt-parent = <&gic>;
	interrupts = <0 22 4>;
	clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
	clock-names = "pclk", "hclk", "tx_clk";
	#address-cells = <1>;
	#size-cells = <0>;
	phy-handle = <ðernet_phy>;
	phy-mode = "rgmii-id";
	ethernet_phy: ethernet-phy@7{
		reg = <7>;
	};
};


コンパイルエラー・・・。

いや、落ち着くのだ。
この書き方は、dtsにそのまま書く場合のやりかただ。
dtsiに設定の上書きっぽく書くときは、&gem0、みたいな始まり方ではないか。


ん、ということは、どこかにオリジナルのgem0が既にあるということじゃないか。
調べると、components/plnx_workspace/device-tree-generation/zynq-7000.dtsiの中にあった。

		gem0: ethernet@e000b000 {
			compatible = "cdns,zynq-gem", "cdns,gem";
			reg = <0xe000b000 0x1000>;
			status = "disabled";
			interrupts = <0 22 4>;
			clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
			clock-names = "pclk", "hclk", "tx_clk";
			#address-cells = <1>;
			#size-cells = <0>;
		};

他のところにも散らばっているので、そのなかで設定されていなさそうなものだけ追加してみよう。

&gem0 {
	ethernet_phy: ethernet-phy@7{
		reg = <7>;
	};
};


libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:1e:53)
Generic PHY e000b000.etherne:07: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:07, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

前と比較。

macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (ba:6a:97:4f:c3:6e)
Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)

Generic PHYが00から07になったくらいか。
これは、regを<7>にしたのが効いたということだろう。
その次のirqが-1になっているのが、よくない気がする。

が、そもそも7でよいのかどうかも不明だ。
根拠をどうやって得るとよいのだろうか?


この人のログ(zedboard)でもirqは-1なのだが、最後でlink upしている。
ということは、irqは関係ないのか。
■QSPIからブート(PetaLinux編) - gogo fpga

Cadence GEMの行に出ているirqは、146になっている。


&gem0 {
	phy-handle = <ðernet_phy>;
	phy-mode = "rgmii-id";
	ethernet_phy: ethernet-phy@1{
		reg = <1>;
	};
};

変わらず。


読めないけど、真似する。
zynq-7000系列基于zynq-zed的vivado初步设计之linux下控制PL扩展的GPIO - luhao806的专栏 - CSDN博客

&gem0 {
	status = "okay";
	phy-handle = <ðernet_phy>;
	phy-mode = "rgmii-id";
	ethernet_phy: ethernet-phy@0{
		reg = <0>;
	};
};

変わらん。


ZYBOの設定をちょっとアレンジ。

&gem0 {
	phy-handle = <ðernet_phy>;
	phy-mode = "rgmii-id";
	ethernet_phy: ethernet-phy@1 {
		compatible = "realtek,RTL8211E";
		device_type = "ethernet-phy";
		reg = <1>;
	};
};

変わらん。
オリジナルのようにgem0_mdioの中に入れると全然ダメだった。


こちらはv2016.3での状況らしい。
Solved: why kernel updating doesn't find ethernet phy? - Community Forums
うまくいってるときと、いかなくなったときのkernelバージョンが同じになっているが、たぶん後者がv2016.3なんじゃなかろうか。
動いていたときのInterl Driverは2.3.2-kで、動かないときは3.2.6-kだ。

PHYを認識しないときのdevicetreeにはmdioが入っていて、解決した方では入っていない。
けど、この内容はさっき試したのとほぼ同じだ。
ethernet_phyという名前を付けていないくらいか(上記では文字化けしているが、"phy-handle"に代入しているのは<&ethernet_phy>だ)。


こちらは質問内容とは関係ないのだが、ログにGeneric PHYではなくRTL8211Eが出ている。
unexpected crash of embedded-linux on Zynq-Device (Zybo) - Stack Overflow

libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:01:22)
RTL8211E Gigabit Ethernet e000b000.etherne:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

Generic PHYではダメなんだろうか?



こちらはkernel 4.8.1で、Generic PHYのログが出ているし、link upしていない。
Linux Kernel 4.8.0正式版をZYBOで動作させてみた。 - ひでみのアイデア帳

こちらはちょっと古いが、macbを使っていて、最初はGeneric PHYでつながってなさそうだが、あとでEthernetのドライバの変更を行い、RTL8211Eになってlink upしたようだ。
PetaLinuxプロジェクトの新規作成 - ぼくの技術日誌



ともかく、エラーっぽいログが出てないので、何が悪いのかがわからんのだ。
出ているものといえば、

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

くらいだ。

さすがに力業では無理な感じがしてきたので、もっと理屈で考えていきたいのだが、さてどこからやるとよいのか。。。

最後の記事で参照してあるリンク先に載っているHardnetのリンクが切れているのだが、こちらかな?
dropboxからファイルが落とせるようなので、次回はそれを試そう。

[zybo]PetaLinux (3)

QSPIで起動したときのログを見比べることにした。
こちらは、pingなどできるのだ。

...
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
libphy: XEMACPS mii bus: probed
...
xemacps e000b000.ps7-ethernet: invalid address, use assigned
xemacps e000b000.ps7-ethernet: MAC updated d6:a8:55:6f:6a:87
xemacps e000b000.ps7-ethernet: pdev->id -1, baseaddr 0xe000b000, irq 54
...
xemacps e000b000.ps7-ethernet: Set clk to 25000000 Hz
xemacps e000b000.ps7-ethernet: link up (100/FULL)

link upするのよねぇ。
e1000eになっているし、RTLなど出てこないので、そういうものかもしれん。


こちらが、いま一番まともに動いていそうなときのログ抜粋。

libphy: Fixed MDIO Bus: probed
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:22:01)
Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

うーん、なんだろうねぇ。

[zybo]PetaLinux (2)

前回は、PetaLinux v2017.2をカスタマイズ無しでビルドして、ZYBOで動くことは確認できたけれども、Ethernetの設定などが動いていなさそうだ、というところまでだった。


ログを見る限りでは、IntelのEthernetドライバを使っているようだったのだが、ZYBOにはカニマークのチップが載っている。
RTL8211E-VLというチップのようだ。
FPGAはともかく、デバイスドライバ周りはLinuxの範囲だから、ちゃんと仕立てないといかん。


PetaLinux v2017.2のリファレンスガイドによると、ZYBOで関係しそうなAuto Config SettingsのDevice-Treeファイルは、

  • skeleton.dtsi
  • zynq-7000.dtsi
  • pcw.dtsi
  • system-conf.dtsi
  • system-top.dts

のようだ。

それ以外にLinuxで関係するのだったら、kernelのconfigか。
こちらは別フォルダで、project-spec/meta-plnx-generated/recipes-kernel/linux/configs/plnx_kernel.cfgにある。
reciepsというフォルダ名があるので、Yocto Projectなのか。


Digilentのpetalinux-bspsにもdevice-treeのディレクトリがある。
そして、kernelのconfigもあるようだ。


まず、Device Treeから片付ける。

dtsiの"i"は、includeの"i"。
components/plnx_workspace/device-tree-generation/system-top-dtsの中で*.dtsiをincludeしている。

推測だが、zynq7000.dtsiは差分があるものの、zynq7000シリーズに共通の設定が書いてありそうな気がするから、最新のものを使った方がよいのではなかろうか。

pcw.dtsiは、差分をマージしよう。
skeleton.dtsiは差分がないので、そのまま。

残るはsystem-conf.tdsiとsystem-top.dts。
どちらも差分が多い。

Digilentの方は、system-top.dtsでsystem-conf.dtsiだけをincludeし、system-conf.dtsiが他をincludeしている。

system-top.dts
  system-conf.dtsi
    skeleton.dtsi
    zynq-7000.dtsi
    pcw.dtsi
    pl.dtsi


生成した方はzynq-7000.dtsi, pl.dtsi, pcw.dtsi, 最後にsystem-user.dtsiをincludeしている。
system-conf.dtsiは、plnx_arm-system.ppというファイルに出てきたのだが、これは自動生成されたファイルのような気がする。
コメントからすると、system-user.dtsiがsystem-conf.dtsiをincludeしているのかな?

system-top.dtsi
  zynq-7000.dtsi
  pl.dtsi
  pcw.dtsi
  system-user.dtsi
    system-conf.dtsi


system-conf.dtsiはコメントに"DO NOT modify"となっているから、いじりたくはない。
しかし、アドレスっぽいものが書いてあるので、system-conf.dtsiに反映するための設定がどこかにあるはずだ。


他の設定はともかく、Ethernetのドライバは、kernelのmenuconfigで、ドライバを適当に選んだらうまいことやってくれるんじゃないの?

zynq / zybo > ZyboにてPetalinuxでEthernetを使うまでの手順 - Qiita

&gem0を書き換えたそうだ。
petalinux-config -c kernelも見てみたが、PHYなんかは比較的設定されているように見えるのだ。

system-conf.dtsiは書き換えたくなかったが、includeの関係からすると、そこを書き換えるのが一番よさそうに見える。
今回は、ZYBOの方にある&gem0の設定を追記して、petalinux-buildし直す。

ダメだ、変わらん。
ZYBOのPHY設定をコピーするのではなく、上記リンク先に書いてあるように書き換えた。
違いは、regやxlnxが追加されているというところか。

・・・ダメだった。
ログが変わらんので、どこかが足りないのか。

Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

しかし、こちらのログでは、e1000eだがネットにつながっている。
PetaLinuxプロジェクトの新規作成 - ぼくの技術日誌

こちらはPHY driverがRTL8211Eとなっているが、私のところではGeneric PHYになっている。
そこだろうけど、kernelのconfigはRealtek PHYsにチェックを入れてるしなぁ。


Subsystem AUTO Hardware SettingsのEthernet Settingsで"ps7_ethernet_0"になっているのが関係しているのだろうか?
これ以外の選択は"manual"しかないのだが。。。



リファレンスガイドを見ていると、そういう設定は"system-user.dtsi"に書くようだ。
場所は、project-spec/meta-user/recipes-bsp/device-tree/filesの下にあった。

/include/ "system-conf.dtsi"
/ {
};
&gem0 {
	phy-handle = <&phy0>;
	phy-mode = "rgmii-id";
	reg = <0xe000b000 0x1000>;
	xlnx,eth-mode = <0x1>;
	xlnx,has-mdio = <0x1>;
	xlnx,ptp-enet-clock = <108333336>;
	ps7_ethernet_0_mdio: mdio {
		phy0: phy@1 {
			compatible = "realtek,RTL8211E";
			device_type = "ethernet-phy";
			reg = <1>;
		};
	};
};

新しくprojectを作り直した。
が、全然だめになった。

macb e000b000.ethernet: invalid hw address, using random
libphy: MACB_mii_bus: probed
mdio_bus e000b000.etherne:01: mdio_device_register
macb e000b000.ethernet eth0: no PHY found

少なくとも、以前はPHYを認識できていたということか。
そして比較して気付いたが、U-Bootの段階で以前はログが出ていた。

Net:   ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
PHY is not detected
GEM PHY init failed
No ethernet found.

ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
mdio_register: non unique device name 'eth0'
No ethernet found.
ZYNQ GEM: e000b000, phyaddr ffffffff, interface rgmii-id
mdio_register: non unique device name 'eth0'

eth0はLinuxで見えていたのだが、U-Bootだから設定していないので出ているログなのだろうか?

念のため、system-user.dtsiに追加した部分をコメントアウトしたが、ちゃんとeth0が見えた。
ただ、U-Bootのログが出ていない・・・・あ、Subsystem AUTO Hardware SettingsのEthernet SettingsでPrimary Ethernetをmanualにしていたのをわすれていた。
設定をp7にすると、U-Bootに同じログが出た。


ということは、Subsystem AUTO Hardware SettingsはLinuxでEthernetを使うことに関しては影響がないということか。
PHYのところがうまくいってないのか。

まあ、少なくとも、system-user.dtsiに書いたことが原因でethernetのPHYが認識しなくなったのだから、ここにうまいこと書けばよいのだろう。


&gem0 {
	phy-handle = <&phy0>;
	phy-mode = "rgmii-id";
	gem0_mdio: mdio {
		phy0: phy@1 {
			compatible = "realtek,RTL8211E";
			device_type = "ethernet-phy";
			reg = <1>;
		};
	};
};

これはpetalinux-bspsに書いてあった内容だが、ダメ。
U-Bootに出てくるログで、phyaddrが1になった。

macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:22:01)
Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)

  ↓↓

mdio_bus e000b000.etherne:01: mdio_device_register
macb e000b000.ethernet eth0: no PHY found

見比べると、eth0が見えているときはirq=-1だから、変な感じがする。
アドレスは指定していないのに、0xe000b000になるのも、なんとなく気になる。


うーん、わからん。。。
知識がない分、地道にdtsiを変更しながら動作を見ていくしかないのか。

2017/07/09

[zybo]PetaLinux (1)

ZYBOで動く更新頻度が高いLinuxディストリビューションを探すシリーズ。
何か程よいのを見つけて、さっさとHDLの勉強に入りたいのだが、自分にとってPS/PLを使うのに一番楽な方法を探したいのだ。

Yocto Projectはレイヤーを選ぶことでいい線までいったけど、bitstreamをなんとかせんといかんようなので、一時中断。
Xillinuxはよさそうだったけど、Ubuntu 12.04 LTS for ARMもサポートが終了したのかもしれないので、今回は見送り。


次に出てきたのは、PetaLinuxだ。
次、というよりは、Xilinxがメンテナンスしているから、むしろ本命だろう。


PetaLinux ツール

ダウンロードはこちら。
毎回最新のものが置かれているようで、今は2017/06/29にリリースされたv2017.2がダウンロードできる。

https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools.html


リリースノート。
AR# 69372: PetaLinux 2017.2 - Product Update Release Notes and Known Issues

Yoctoもリストに載っているので、rel-v2017.2のyocto-manifestsをレイヤーとして選んでbitbakeするのと同じような環境になるのかもしれない。
リファレンスガイド(pdf)の最初にも「Yocto Extensible SDK」と書いてあるし。

対応ボードには、残念ながらZYBOは入っていない。
ZYBOのページからpetalinux-bspsに飛べたのだが、コメントを見る限りではv2016.2かv2015.4のようだ。

ただ、こちらを見ると、z-turnというボード向けにを汎用テンプレートから環境を作っているようなので、ZYBOも似たようなことができるはずだ。
電気回路/zynq/Petalinux のビルド - 武内@筑波大

まあ、それだったらYoctoでrel-v2017.2を試したときにやればよかったやん、ということになるが、あのときはまだ知識が足りなかったのだよ。


まずは、PetaLinuxツールのインストール。
うちはVirtualBoxで動いているXubuntu16.04にインストールした。

petalinux-v2017.2-final-installer.runというファイルがダウンロードできたのだが、これが7.7GBもある。
そして、インストールにはかなり時間がかかる。
インストールは実行したディレクトリに行われるか、引数で与えたディレクトリに行われる。
リファレンスガイドを読む前にインストールしたので、runファイルをダウンロードしたディレクトリで実行してしまい、長い時間待たされて、そのあとでインストールするディレクトリ選択が出てこなかったので、一度終了させてcdしてまたやりなおし、という手間を掛けてしまった。
なお、sudoはいらない。

インストール時に出てくるログは、武内氏のサイトとだいたい同じ。
環境変数を設定するスクリプトのことも出力されているようだが、いくつもインストールが行われているので流されてしまった。
リファレンスガイドでは、インストールディレクトリにあるsettings.shをsourceすればよいようだ。
これを実行すると、空きディスクなどもチェックするためか、まあまあ時間がかかる。
うちでは、tftp serverがないと警告された。
SDカードに焼くつもりだから、無くても大丈夫かな? ダメだったらインストールしよう。

gccはリリースノートに書いてあったように、6.2.1。


そして、z-turn用のプロジェクトを作っているのを真似して、ZYBOの環境を作りたい。
petalinux-createコマンドを実行すると、そのディレクトリにディレクトリが作られた。

$ petalinux-create -t project -n petazybo --template zynq

なお、-sでBSPのパスを指定することもできるようだ。
petalinux-bspsをcloneして指定したが、そういうものではないようだ。
plnx_bsp_creator.shというスクリプトを動かしてみたが、petalinux-packageでエラーになっている。
bootは"arm"しかサポートしていないなどといっているのだけど、今回は忘れよう。


そして、petalinux-configの実行
system.hdfだけじゃなくて、他にもいろいろいるようだ。
LED点滅だとHardware Exportが使えないので、ZYBOのチュートリアルで作ったフォルダを指定した。
platformの0と1が同じファイル構成に見えるので、よくわからんが0にしておいた。

$ petalinux-config --get-hw-description=../design_1_wrapper_hw_platform_0

そうすると、menuconfigっぽいものが出てきた。

image

Exitして保存すると、bitbakeが走り出した。
時間がかかるので、放置しておこう。

ここまで、エラー無しで完了した。
まだZYBOっぽい設定はしていないのだけど、大丈夫だろうか。。



次はkernelのビルド
サイトの人はここでエラーが出たらしいが、うちはどうだろう?

$ petalinux-build -c kernel

うちは大丈夫だった。
バージョンが上がったので、なんか対処されたのかもしれないし、ずっと開発に使っているXubuntuなので別のことで対処されていたのかもしれん。
LANGはen_US.UTF-8にしていた。

$ ls images/linux
design_1_wrapper.bit  rootfs.tar.gz     u-boot.bin  zImage
rootfs.cpio           system.dtb        u-boot.elf  zynq_fsbl.elf
rootfs.cpio.gz        System.map.linux  vmlinux

-cなしでビルドすると、image.ubとrootfs.tar.gzもできるらしい。
最初からそれでよかったのかも。

$ petalinux-build
(...)

$ ls images/linux
design_1_wrapper.bit  rootfs.cpio.gz  System.map.linux  vmlinux
image.ub              rootfs.tar.gz   u-boot.bin        zImage
rootfs.cpio           system.dtb      u-boot.elf        zynq_fsbl.elf

増えてる。



uImageの作成はやらなくてよいことがわかったらしいので、スキップ。
BOOT.binの作成はいるだろう。

petalinux-packageコマンドは、petalinux-bspsで失敗したあれだ。
生成されているファイル名もサイトと同じなので、同じことをやってみよう。

$ petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --fpga  images/linux/design_1_wrapper.bit --u-boot --force
INFO: File in BOOT BIN: "/home/xxx/Xilinx/petauser/petazybo/images/linux/zynq_fsbl.elf"
INFO: File in BOOT BIN: "/home/xxx/Xilinx/petauser/petazybo/images/linux/design_1_wrapper.bit"
INFO: File in BOOT BIN: "/home/xxx/Xilinx/petauser/petazybo/images/linux/u-boot.elf"
INFO: Generating zynq binary package BOOT.BIN...
INFO: Binary is ready.
WARNING: Unable to access the TFTPBOOT folder /tftpboot!!!
WARNING: Skip file copy to TFTPBOOT folder!!!

TFTP serverを準備していないので警告が出ているが、全体としては問題なさそうだ。
カレントディレクトリに2.5MBくらいのBOOT.BINができていた。
images/linuxにもコピーされているようだ。


SDカードにコピーする前に、リファレンスガイドを読んでおこう。
バージョンが違うので、何か違いがあるかもしれん。

  • 今回のpetalinux-createの使い方は、"Create New Project"に書いてあるやり方。
    --templateでCPU_TYPEを指定する。
  • "Version Control"でgitignoreの中身が書いてある。
    petalinux-bspsのスクリプトにもあったが、確かめていないし、今回はgitに入れてない。
  • "Import Hardware Configuration"がsystem.hdfのあるフォルダを指定したところ。
    項目の"Subsystem AUTO Hardware Settings"を確認するように書かれているが、今回はやってないな。
  • "Build System Image"は、同じだ。
  • "Generate uImage"は、今回スキップした内容だろう。
    FITを使いたくないときは、これでuImageを作るとよいそうだから、覚えておこう。
  • BOOT.BINは、"Generate Boot Image for Zynq Family Devices"だろう。
    今回は--forceを付けたが、リファレンスガイドには付いていなかった。
  • "Package Prebuilt Image"は、JTAG/QEMUでブートするためのものか?
    "not mandatory to boot with JTAG/QEMU"と書いてあるけど、withoutではなかろうか。
  • "Boot a PetaLinux Image on Hardware with SD Card"がSDカードの準備だろう。
    BOOT.BINとimage.ubをFAT32に置けばよいらしい。

というわけで、サイトに書いてあるのと同じだ。


コピーして、ZYBOに挿して起動すると、普通に立ち上がってしまった。

PetaLinux 2017.2 petazybo /dev/ttyPS0

petazybo login: root
Password:
Login incorrect

いや、パスワードなんて知らないんですけど!
あ、rootのrootでいいのか。

# uname -a
Linux petazybo 4.9.0-xilinx-v2017.2 #1 SMP PREEMPT Sun Jul 9 12:54:30 JST 2017 armv7l GNU/Linux

へー。
ZYBOっぽいことを何もしなくても、立ち上がるだけなら立ち上がるんだ。
DONE LEDも点灯している。


起動ログを載せたいところだが、ブログエディタでそういう便利なものがまだ使えないので、割愛だ。

最初はU-Bootのログから始まる。
これは、SPLがU-Boot側で提供されるとか何とか書いてあったことと関係するのかな?

しかし、bitstreamを読んだようなログがないし、FPGAっぽいものといえば、

FPGA manager framework
fpga-region fpga-full: FPGA Region probed

くらいだ。


困ったことに、ethernetにつながらない。
DHCPでも見つからないし、staticに割り当てても見つからん。
しかし、LINK LEDは点灯しているし、ACT LEDも点滅している。
ということは、ドライバなんだろう。

Generic PHY e000b000.etherne:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

とログが出ているが、ZYBOに載っているチップにカニが見えるので、Realtekだろう。

petalinux-configして出てくるmenuconfigで、"Subsystem AUTO Hardware Settings"の中を見るとEtherenetの設定があって、その中にPrimary Ethernetという設定があった。

image

なんじゃこりゃ?

リファレンスガイドのAppendix CにAuto Config Settingsの説明がある。
この辺のファイルを設定しておいたら、自動的に参照してkernelなどに反映してくれるような気がする。


深みにはまりそうなので、次回に回そう。

[zybo]Xillinux

XILLYBUS社のLinuxなので、Xillinux
Lは2つだ。

FPGAマガジン17を読んでいるのだが、特集の第3章でZYBOにLinuxを載せているところがあった。
そこで使われているのがXillinuxだった。

Ubuntu 12.04 LTS for ARMをベースにしているらしい。
Ubuntuなら更新がaptでできるのでよいかな、と思ったのだが、12.04は今年の4月末でサポートが終わっている。
ARM版もそうなのかはわからないのだが、そう時差が大きいとは思えん。


便利そうなのだが、この時期に使い始めるものでもなさそうなので、今回は見送りだ。
いつか、新しいLTSが出たら、また考えよう。

2017/07/08

[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つある。

image

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だ)。


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

2017/07/06

[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の連載をしていたようなので、読んでおこう。

2017/07/04

[勉]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ページ分くらいだ。
レシピの作り方などが続いていくが、そこは流して読んでいくことにしよう。
ともかく、今日はここまで。

2017/07/02

[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