2017/07/30

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

前回(12)で/devにファイルを作ってくれるようになったが、rmmodの方を何もしていないことに気付いた。

本を真似して追加。

device_destroy(char_class, char_dev);
class_destroy(char_dev);


が、rmmodすると、エラーというか、派手に失敗した。

# rmmod zybo_gpio
Unable to handle kernel paging request at virtual address 0f400020
pgd = de690000
[0f400020] *pgd=00000000
Internal error: Oops - BUG: 5 [#1] PREEMPT SMP ARM
Modules linked in: zybo_gpio(O-) uio_pdrv_genirq
CPU: 1 PID: 1062 Comm: rmmod Tainted: G           O    4.9.0-xilinx-v2017.2 #1
Hardware name: Xilinx Zynq Platform
task: de4a4140 task.stack: de78c000
PC is at class_unregister+0x8/0x4c
LR is at char_exit_module+0x20/0x54 [zybo_gpio]
pc : []    lr : []    psr: 000e0013
sp : de78df38  ip : dd61cb6c  fp : 00000000
r10: 00000000  r9 : de78c000  r8 : c0106e24
r7 : 00000081  r6 : be83db60  r5 : 000000f4  r4 : 0f400018
r3 : 0f400018  r2 : 0000003b  r1 : c7c1fb00  r0 : 0f400018
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 18c5387d  Table: 1e69004a  DAC: 00000051
Process rmmod (pid: 1062, stack limit = 0xde78c210)
Stack: (0xde78df38 to 0xde78e000)
df20:                                                       bf008b40 000000f4
df40: be83db60 bf008570 bf008980 00000880 be83db60 c0177650 dd735900 6f62797a
df60: 6970675f b6f3006f 00000001 de4a4140 00000000 c0a33838 de4a4140 00000000
df80: c0a33838 0000005b de4a4140 c0131bdc de78c000 00106e24 0002165c 6f62797a
dfa0: 6970675f c0106c60 0002165c 6f62797a be83db60 00000880 000ba9b0 be83de18
dfc0: 0002165c 6f62797a 6970675f 00000081 be83df0e 00000002 000b87b8 00000000
dfe0: be83db58 be83db48 000214b4 b6e17a60 600e0010 be83db60 f4f71bdc 6efff6d7
[] (class_unregister) from [] (char_exit_module+0x20/0x54 [zybo_gpio])
[] (char_exit_module [zybo_gpio]) from [] (SyS_delete_module+0x164/0x1d4)
[] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x3c)
Code: e8bd4010 eaf8ae6e e92d4070 e1a04000 (e5903008)
---[ end trace 7dde3b5d13b2d080 ]---
Segmentation fault

classの登録・削除をコメントアウトするとrmmodしても問題ないので、追加した部分に問題があることになる。


PCがclass_unregisterになっているから、class_destroy()だろうか?
いや、device_destroy()したあと、先にclass_unregister()してやらないといけないみたいだ。。。が、それでも同じだ。


insmodしたときに、out-of-treeとか出てるので、それだろうか。。。
わからんが、気になるので調べよう。

treeは、デバイスツリーかと思っていたのだが、kernelのソースツリーなのか。
https://www.kernel.org/doc/Documentation/kbuild/modules.txt

確かにこのドライバはkernelのソースツリーには入っていない。
では、別に問題ないのかな?


じゃあ、さっぱりわからんな。
Linuxのドライバのサンプルを探すところからやらねば。


2017/07/31 0:02追記

あ、class_destroy()の引数を間違えているではないか。。。

誤:class_destroy(char_dev);

正:class_destroy(char_class);

そうよね、classの削除なんだから、classを引数に取るよね。。。

gistを修正した。
まあ、いつもに比べると傷は浅いな(失敗慣れしすぎ)。

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

前回(11)のminorを32から24に書き換えるというのが変だということに気付いた。
32で動いていたのだから、そこは書き換えたらいかんだろう。

よくわからんが、class登録するときだけ24にして、他は32のままに変更した。
そうすると、/devにも作成されたし、echoすると成功した。

GISTに置いておこう。
https://gist.github.com/hirokuma/1bda2e783813412c4df16b8027f5480c


まだ、32だの24だのが何なのか理解していないので、次回からはそこを調べていこう。
Linux/Zynqのつながりを見ていくことになるはずだ。


あとは、おまけだ。


image.ubの効率的な作り方を知っておきたい。

全体をビルドするときは petalinux-build だけでやっているが、けっこう時間がかかる。
今回だと、koファイルだけビルドして、image.ubの元になる場所にコピーして、image.ubを作り直す、というだけでよいはずだ。
事前のチェックとか、そういうのはすっ飛ばせないだろうか。


まず、--helpを見る。
使えそうなのは、この辺りか。

Deploy kernel forcefully:
   $ petalinux-build -c kernel -x deploy -f

Build kernel and update the bootable images:
   $ petalinux-build -c kernel
   $ petalinux-build -x package

Build rootfs only:
   $ petalinux-build -c rootfs

Build myapp of rootfs only:
   $ petalinux-build -c rootfs/myapp

以前ダメだったスラッシュでの方法も書かれている。
が、これはmyappなので、moduleだと使えないんじゃなかろうか?
試しにgpio-demoでやってみたが、やっぱりエラーだ。


PetaLinuxのユーザーズガイドを見る。
v2017.2はUG1144(pdf)だが、内容はv2017.1と同じらしい。
コマンドラインリファレンスUG1157(pdf)もある。
ネットから探しているけど、DocNavを使うのがよいだろうね。

気になっていたこのコマンド。

$ petalinux-build -x package

これは、今のdeployエリアに入っているものからFIT imageを作るものらしい。
だから、koファイルを作って、deployエリアにコピーさえすれば、最後に -x packageでimage.ubができるはず。
rootfs/myappではなく、myappを直接指定すればよいのかな?

$ petalinux-build -c myapp
$ petalinux-build -x package

やってみた。

$ petalinux-build -c led8drv
[INFO] building led8drv
[INFO] sourcing bitbake
INFO: bitbake led8drv
Loading cache: 100% |############################################| Time: 0:00:00
Loaded 3236 entries from dependency cache.
Parsing recipes: 100% |##########################################| Time: 0:00:02
Parsing of 2447 .bb files complete (2415 cached, 32 parsed). 3237 targets, 224 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Initialising tasks: 100% |#######################################| Time: 0:00:06
Checking sstate mirror object availability: 100% |###############| Time: 0:00:13
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 2430 tasks of which 2389 didn't need to be rerun and all succeeded.
INFO: Copying Images from deploy to images
[INFO] successfully built led8drv

lsでimage/linuxのタイムスタンプを見ると、rootfs.cpioやvmlinuxは更新されているが、image.ubは同じだ。

$ petalinux-build -x package
[INFO] building project
[INFO] sourcing bitbake
INFO: generating FIT Image
INFO: bitbake petalinux-user-image -R /home/xxx/build/conf/fit-image.conf
Loading cache: 100% |############################################| Time: 0:00:00
Loaded 3236 entries from dependency cache.
Parsing recipes: 100% |##########################################| Time: 0:00:02
Parsing of 2447 .bb files complete (2415 cached, 32 parsed). 3237 targets, 224 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Initialising tasks: 100% |#######################################| Time: 0:00:05
Checking sstate mirror object availability: 100% |###############| Time: 0:00:11
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 2431 tasks of which 2402 didn't need to be rerun and all succeeded.
INFO: Copying Images from deploy to images
[INFO] successfully built project

こっちは、image.ubのタイムスタンプが更新された。


しかし、それぞれ時間かかるのよねぇ。

$ time petalinux-build -c led8drv
real	1m23.720s
user	1m10.616s
sys	0m11.788s

$ time petalinux-build -x package
real	1m20.351s
user	1m7.700s
sys	0m10.048s

いっそのこと、petalinux-buildでやった方が早いんじゃないだろうか?

$ time petalinux-build
real	2m34.151s
user	2m10.356s
sys	0m19.984s

微妙やね。。。
コマンドを2回打ち込まなくてよい分、この方が楽かもしれん。

2017/07/29

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

動かんシリーズの1~10で、PetaLinux v2017.2を載せたZyboのJEコネクタに接続した7セグLEDを制御できるようになった。

PetaLinuxがよいのか、というのは難しいところだ。
できれば、Ubuntuみたいにセキュリティアップデートを動的に行いやすいディストリビューションの方がよいのかもしれない。
メーカーが、売った人を追跡できるような規模であれば、営業さんにアップデートしてもらうという作戦もあるのかもしれんが、そうもいかんだろうしねぇ。
みんなどうしてるんだろう?


さて、まずはデバイスファイルから解決しよう。

以前、NXPのOM5578をRaspberry Piで動かそうとしたときに、ドライバのエラーが出て/devにファイルが作られないということがあった。
だから、自分でmknodしたり、あらかじめrootfsに仕込んだりせず、ドライバが自分でデイバスファイルを作ることができるのだと思う。


あー、udevというものがあったな・・・。
PetaLinuxでもudevを使っているのだろうか?

Starting udev
udevd[725]: starting version 3.2

あるのね。

私が持っている『Linuxデバイスドライバプログラミング』では、ドライバのクラス登録と、/sys/class配下にドライバ情報を作る作業を行うらしい。


もしかしたら、テンプレートで作ったソースファイルだとやってくれているかもしれない、と思ってディレクトリを見ていると、<project_name>/project-spec/meta-user/recipes-apps/gpio-demoというフォルダがあることに気付いた。
こんなアプリ追加してないんですけど。。。

ネットで検索すると、echoで書込むことによってLEDが光るらしい。
えんべでっどログ: ZYNQのMIO GPIOをLinuxから使う

# echo 913 > /sys/class/gpio/export
# echo out > gpio913/direction
# echo 1 > gpio913/value

お、MIO7のLED(LD4)が点灯した。
0を書込むと消灯する。

デバイスファイルを使わずにアクセスすることもできる、ということか。
そういえば、Raspberry Piも同じようなものがあったな。


このドライバは、./build/tmp/work-shared/plnx_arm/kernel-source/drivers/gpio/gpio-zynq.cのようだ。

本によると、class_create()やclass_device_create()を使うようなのだが・・・このソースには使われていなかった。
もう9年くらい前の本だから、時代が変わったのだろうか?
あるいは、kernelの組込みドライバだから、別のしくみがあるのだろうか。
なんとなく、後者である気がするのだが、深入りはやめておこう。


ただ、デバイスツリーも気になっているのだ。
あれは、デバイスの情報を取ってくることができないので、代わりに別バイナリにしたとか、そんな話だったと思う。
Raspberry Piで見たとき、デバイスツリーの情報からmknodしている箇所があったような気がするのだが、他のと記憶が混ざっている気もする。
この本では、まだデバイスツリーが登場する前なので、関連があるともないともわからない。
うーむ。


まあ、本の通りやってみよう。

やってみたのだが、class_device_create()が未定義と言われる。
includeが足りないのかと思ったら、廃止になったのか・・・。
driver - Linux function class_device_create changed to? - Stack Overflow

device_create()になったらしいが、なかなかつらいな。
サイトにはサンプルも更新されているようなので、そちらを見た方が良いのかも。
SBクリエイティブ:Linuxデバイスドライバプログラミング


とりあえずdevice_create()にするとビルドできた。
insmodすると、/devにファイルができてる。
おお!

・・・しかし、リダイレクトで書込むとエラーになった。

-sh: /dev/zybo_gpio32: No such device or address

lsで見ると、majorは244でいいんだけど、前回mknodしたときのminorは24だったのだ。

# ls -l /dev/zybo_gpio32
crw-------    1 root     root      244,  32 Jul 29 08:58 /dev/zybo_gpio32

まあ、これは元のソースが32になっていたから、仕方ないのかな?

24に変更して、ビルドし直す。
insmodして、echoして・・・ダメだ、同じエラーだ。

# ls -l /dev/zybo_gpio24
crw-------    1 root     root      244,  24 Jul 29 09:09 /dev/zybo_gpio24

/sys/class/zybo_gpio/zybo_gpio24はできているんだけどねぇ。

# cat /sys/class/zybo_gpio/zybo_gpio24/uevent
MAJOR=244
MINOR=24
DEVNAME=zybo_gpio24

続きは、また明日だ。

[zybo]PetaLinux v2017.2でHDLを書かずにLED制御の準備をする (2017/7月)

今月のこれまでの成果として、Zybo + PetaLinux v2017.2で、HDLを書かずにLED制御の準備をするまでの手順を書き残そう。
「LED制御の準備」というのは、ドライバを作る手前まで、という状態に持っていくことを指している。
まだチュートリアルが動かせないシリーズがあるので、DeviceTreeなども解決してから続きを書こう。


ツールは、こう。

  • Vivado v2017.2 (Windows10)
  • XSDK v2017.2 (Windows10)
  • PetaLinux v2017.2 (Xubuntu 16.04 on VirtualBox)


HDFファイル作成

まず、Vivadoでの作業を行う。

  1. Vivadoを起動
  2. Projectを作成する
    1. Boardは"Zybo"を選択
  3. "Create Block Design"をクリック
    1. "+"アイコンをクリックして、Zynqを追加
    2. 上の方にリンク"Run Block Automation"が出てくるので、クリックして、チェックされているのを確認して、OK
    3. "+"アイコンをクリックして、AXI GPIOを追加
    4. 上の方にリンク"Run Connection Automation"が出てくるので、クリック
      1. 一番上のツリーにチェックする
      2. axi_gpio_0>GPIOの中から"leds_4bits"を選択して、OK
    5. LinuxからEthernetを使いたい場合は、ZYNQをダブルクリック
      1. 左のPeripheral I/O Pinsをクリック
      2. Searchに"Ethernet"と打つ
      3. Ethernet0>MDIOにチェックが入っているので、右にスクロールさせて、MDIOをクリックしてOK
    6. Save
  4. 左側のツリーでSourcesタブを選択し、Design Sourcesの下にある項目(たぶんdesign_1(design_1.bd))を右クリック
    1. Create HDL Wrapper...を選択
    2. ダイアログが出てくるので、auto-updateの方になっているのを確認して、OK
    3. Critical Messagesダイアログが出てくるが、気にせずOK
  5. "Generate Bitstream"をクリック
    1. 終わるまで待つ
    2. 終わったらダイアログが出てくるので、Cancelを選択してOK
  6. メニューから、"File > Export > Export Hardware..."を選択
    1. Include bitstreamにチェックして、OK
  7. メニューから、"File > Launch SDK"を選択
    1. 立ち上がったら、自動的に関連するファイルを作ってくれるので、終了させる
  8. Vivadoも終了させる



PetaLinux image作成

  1. PetaLinuxの設定ファイルを読み込む
    $ source settings.sh
  2. プロジェクトを作るフォルダに移動(お好きな場所へ)
  3. 空のプロジェクトを作る。今回は"gpioled"という名前にする。
    $ petalinux-create -t project -n gpioled --template zynq
  4. できたディレクトリ(今回はgpioled)に移動する
    $ cd gpioled
  5. さきほど作ったVivadoプロジェクトの中から拡張子がsdkのフォルダ内にある"design_1_wrapper_hw_platform_0"というような名前のフォルダをまるごとgpioledの中にコピーする
  6. 読込んで設定
    $ petalinux-config --get-hw-description=./design_1_wrapper_hw_platform_0
  7. 特に変更せず終わらせると、そこそこ時間かかる処理が始まる。
  8. 忘れていたが、LEDのドライバを準備する。今回はleddrvという名前にする。
    $ petalinux-create -t modules -n leddrv --enable
  9. "gpioled/project-spec/meta-user/recipes-modules/leddrv"辺りにファイルができているので、うまいこと編集するとよいのだが、まずはテンプレートのままにしておく。
  10. ビルドする。こちらは時間がかかる。
    $ petalinux-build
  11. BOOT.BINを作る
    $ petalinux-package --boot --fsbl images/linux/zynq_fsbl.elf --fpga images/linux/design_1_wrapper.bit --u-boot --force


これで、BOOT.BINとimage.ubができたので、SDカードにコピーしてZyboを起動。
ログインして、ドライバを確認。

# ls /lib/modules/4.9.0-xilinx-v2017.2/extra/
leddrv.ko

read/writeを用意していないが、insmodくらいならできるだろう。

# insmod /lib/modules/4.9.0-xilinx-v2017.2/extra/leddrv.ko
leddrv: loading out-of-tree module taints kernel.
<1>Hello module world.
<1>Module parameters were (0xdeadbeef) and "default"

open/closeもできそうだが、デバイスファイルがないのでできない気がする。


ひとまず、これで、デバイスファイルとドライバを作ればLED制御できそうな状態になったと思う。
以降の調査は、これからやっていこう。

2017/07/27

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

前回までで、ようやくここまで来た。

  • Vivado v2017.2でGPIOを7本有効にする
  • XSDK v2017.2で何かする(この工程はいるのか?)
  • hdfファイル一式をPetaLinux v2017.2に持っていって、user moduleを追加してビルドし、mknod, insmodして動かす


user moduleがビルドできずに悩んでいたのは、petalinuxで追加したmoduleのテンプレートにあったREADMEを読んだからだということに気付いた。

To compile and install your module to the target file system copy on the host,
simply run the
     "petlainux-build -c kernel" to build kernel first, and then run
     "petalinux-build -c rootfs/led8drv" to build the module
command.

-cで、rootfsとled8drvをそれぞれやりなさい、ということかもしれんが、わからんよ。。。


あとは、ドライバをいじるところをやれば、多少は理解できるんじゃなかろうか。


Linuxのドライバは、

  • open
  • close
  • read
  • write
  • ioctl

でできているはずだ。
ioctl()って逃げよねぇ、と思いつつも、他に手段が思いつかないので、便利に使っている。


Interface誌のダウンロードから持ってきたファイルを見ておこう。
closeではなくreleaseという名前になっているし、ioctlはないが、基本的にはこういう構成になるだろう。
プレフィクスが"char_"なのは、キャラクタ型ドライバだからか。
確か、ブロック型とキャラクタ型があって、ASCII社の本で簡単な区別方法を読んだ気がするが、探し出せなかった。
ブロック転送しないものはすべてキャラクタ型だ、とか、そんなだったような。


私だとioctl()でやってしまいそうだけど、ここはchar_write()で書込処理を行っている。
利点は、Linuxコマンドと組み合わせやすい、というところか。
ioctl()だと、ソース書かないと動かせない気がする。

今は、書き込んだデータがASCIIコードでそのまま吐き出されているのだが、条件は簡単で、

    • 1byte目が'0'
    • 2byte目が'x'
    • データ数は3より大きい

だった場合、3byte目をiowrite32()で書込んでいるだけのようだ。


では、簡単に書き換えて、ビルドし直してみよう。
やはり、echoした数字をそのまま表示させたい。

なんとなくカルノ図を描いたりする気がしたのだが、Linuxから見ると数字を変換してポートに書込むだけなので、変換テーブルしかいらなかった。

image

アノードが共通なやつを使っているから、0で点灯するのだ。
大ざっぱだが、こういう感じの修正になった。

    unsigned int val;
    const unsigned int VAL[] = {
        0x40, 0x79, 0x24, 0x30, 0x19, 0x12, 0x02, 0x78, 0x00, 0x10
    };

    if (('0' <= k_buf[2]) && (k_buf[2] <= '9')) {
        printk("WRITE %02x\n", (unsigned char)VAL[k_buf[2] - '0']);
        iowrite32( VAL[k_buf[2] - '0'], cookie);
    }


ドライバの差し替えは、これでよいのかな?

$ petalinux-build -c led8drv
$ petalinux-build -x package

やるのは、ドライバのコンパイル・リンクと、rootfsへのコピーおよびUboot形式への変更だけなんだけど、あれこれやってるから時間がかかるな。。。

# mknod -m 666 /dev/zybo_led c 244 24
# insmod /lib/modules/4.9.0-xilinx-v2017.2/extra/zybo_gpio.ko
# echo 0x1 > /dev/zybo_led

うん、期待通りに点灯した。


mknodを毎回やるのはめんどうなので、何とかしたいところだ。
Raspberry Piでは、Device Treeに書いておけばudevか何かが自動的にmknodしていたように思うが、PetaLinuxはどうやるんだろう?

そういうのは、次回だ。

2017/07/25

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

前回(8)の続き。

ドライバのビルドはできたのだけど、insmodしても/dev/zybo_ledみたいなものが出てこない・・・。


昼ご飯を食べ終わって、急に思いついた。

あー、mknodしてない!

は、恥ずかしすぎる・・・。


# mknod -m 666 /dev/zybo_led c 244 24
# insmod /lib/modules/4.9.0-xilinx-v2017.2/extra/zybo_gpio.ko

Interface誌ではmknodするのが245になっていたが、insmodしたときが244だったので、そっちにあわせた。

echoすると、LEDが変化した。

# echo 0x1 > /dev/zybo_led
----- This is the Open Function -----
Node NAME: Ext_GPIO:
MAJOR Number = 244, MINOR Number = 24
Open device successfully: Ext_GPIO:


---- This is the WRITE function -----

k_buf is 0x1
  pos = 4
----- This is the Close Function -----
Closing device: Ext_GPIO:

image

書込んだ値にあわせて7セグも数字のように点灯するのかと思ったが、どうもASCIIコード('1'だと0x31)を出力させているらしい。

Aがb7、Bがb6、・・・ということらしい。
1だとビットは3つしかないのに、なんで4本光ってるんだ?
HI点灯とLO点灯の違いだろうか。


まあいい、このレベルまでは持ってくることができたから、次からはドライバのソースを見ていこう。

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

前回(7)の続き。
LED用のドライバを動かすためにmoduleを追加して、ようやくビルドできたところまで。
全部動いてからまとめて書くとあっさりしているのだろうけど、日記だから許しておくれ。


ビルドのテストとしてmymoduleという名前で追加したのだけど、もう不要になったから、先に削除しておこう。
モジュールのフォルダを削除しただけではコンパイルエラーになり、project-spec/meta-user/recipes-core/petalinux-image.bbappendに追加されていた名前を削除してもコンパイルエラーになった。
依存関係が残っているというエラーっぽいのだが。。。
project-spec/meta-plnx-generated/recipes-core/images/petalinux-user-image.bbにも書かれていたので、そこからも行削除するとビルドできるようになった。


PetaLinuxのリファレンスに書いてあるとおりにビルドしていたのだが、どれをやってうまくいったのかわからん。
エラーにはならなかったのだが、探す場所と探す名前を間違えていてね。。。
Interface誌のページからダウンロードしたCファイルをそのまま使うと、こうなった。

/lib/modules/4.9.0-xilinx-v2017.2/extra/zybo_gpio.ko

lsmodしても出てこないから、自動では読込まないのだろう。

# insmod /lib/modules/4.9.0-xilinx-v2017.2/extra/zybo_gpio.ko
zybo_gpio: loading out-of-tree module taints kernel.
Device registered successfully, Major No. = 244

out-of-treeと出てるけど、よいのかな?
successになっているけど、/dev/zybo_ledなんてデバイスファイルは見つからない。。。
別の名前で増えたわけでもない。


うーん、残念だが、また次回だ。

[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などに反映してくれるような気がする。


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