2017/08/18

[linux][c/c++]現在時刻の取得

Linuxで時間の取得を行いたい場合がある。
今の時間だ。
time(NULL)でepoch timeを取得していたのだが、それでよいのか自信がなくなってきた。


マイコンの場合、RTCに設定した時刻が取ってこれるだけで、それ以上でもそれ以下でもない。
それに、RTCから自分で値を引っ張り出さないといけないので、epochも何も気にしようがない。

しかし、time()はきっとライブラリ側でOSが管理しているしくみに置き換えられているはず。
Linuxで時間といえばgettimeofday()だよなあ、と検索したのだが、どうもgettimeofday()は廃止予定らしい。
gethostbyname()もそんな感じだったな。。

推奨されているのは、clock_gettime()
まずは動かしてみよう。

https://gist.github.com/hirokuma/17bdf87bf3c8c6f29008e74635f9984e

2017/08/18 10:10くらいにBash on Ubuntu on Windowsで実行させると、こうなった。

$ ./tst
tv_sec=1503018649, tv_nsec=105938100

ネットでepochを現在時刻に変換するサイトを見つけてやってみると、JSTとして変換すると現在時刻になった。
dateコマンドでは、こうなる(あれこれしているうちに5分くらい経ってしまったが)。

$ date
Fri Aug 18 10:15:53 DST 2017


これは、内部ではUTCで管理していて、出力時にJSTの下駄を履かせているという考え方でよいのだろうか?
(DSTになっているのも気になるが。。。)
VirtualBoxで動かしているXubuntu16.04でも同じになったので、Bash on Ubuntuがそうしているわけではなさそうだ。


そして、epoch timeは各地の時刻ではなく、UTCで出すというのが共通の認識ということでよいのだろうか。
数字しかないので、UTCがデフォルト、のようなルールがないと困るのだけど、明示的に書いてある資料が見つからない。


オライリーの「C言語クイックリファレンス」には、

  • time()は現在のカレンダー時刻を返す
  • これは、紀元と呼ばれる
  • Unixの紀元はUTCの1970年1月1日 00:00:00

とある。
そして、「紀元」は"epoch"だから、epoch timeはUTCということでいいんじゃないかな。
うんうん、そうしておこう。

tig

ファイル履歴管理にgitを使っているのだが、未だにコマンド慣れしていない。
慣れない操作で失敗するのも嫌なのでGUIのツールを使っていたのだけど、最近はクラウド上につくったVMを扱わんといかんことも多くなり、なるべくgitをコマンドラインで使うようにしている。


でも、ある程度はGUIっぽく表示してくれた方が見やすいじゃないか。
そう思って探していると、tigというコマンドが見つかった。

gitを逆に並べたtigだが、コマンドラインで動かすツールながらも、GUIっぽく出してくれる。
なんというか、FDみたいなコマンドになるのかもしれん。
・・・FDってWindowsのみだったかも。


tigの操作は、ちょっとviっぽい。
カーソルの移動がそうだからか。


使うのは、ステージに挙げたりcommitしたりするところが主だ。
git addするとき、ファイルのパスをいちいちコマンドで書くのが面倒なのだよ。

tigを立ち上げて、sを押して更新したファイルの一覧を出し、uを押してcommitしたいものをステージに上げる。
上げ終わったら、大文字のCを押してcommitするエディタを起動する。
うちではnanoが立ち上がった。

historyなんかも重たくなく見られるので、使いこなせると便利そうだ。


ただ、最近はtigする気力も無いので、VirtualBoxでGUIが動く状況であればVisual Studio Codeを使っている。
差分なんか見やすいしね。

2017/08/17

[勉]MIPI

Xilinxからメールが来た。

MIPI D-PHY 搭載のザイリンクス UltraScale+ デバイス

MIPI?
初めて聞く単語なので、これは調べねばなるまい。


Mobile Industry Processor Interfaceの略らしい。

デバイス古今東西(17) ―― 撮像デバイスの変遷と次世代標準インターフェースMIPI規格|Tech Village (テックビレッジ) / CQ出版株式会社

「モバイル機器向け」なのだそうだ。
記事が2010年なので、7年前にはすでにあった規格ということになるな(2003年らしい)。

シリアル通信というと、UART, I2C, SPI, USBなどなど、たくさんある。
そこに連なるようなものなのか、


こちらが、mipi allianceのページ。
https://www.mipi.org/

仕様書をちょっとくらい見てみようかと思ったけど・・・数が多くて止めた。
Specifications Overview

カテゴリーだけで、これだけある。

  • Audio
  • Camera and Imaging
  • Chip-to-Chip/IPC
  • Control and Data
  • Debug and Trace
  • Display and Touch
  • Physical Layers
  • Software Integration

まあ、NFC Forumの規格もたくさんあったし、そういうものかもしれん。


これで終わってしまうのはさすがに悔しいので、Xilinxのメールで紹介された規格くらい調べておこう。

「MIPI D-PHYを搭載」

mipi allianceの説明ページは、こちら
PHYなので、物理層なのだろう。
スマートフォンのカメラやディスプレイ向きのようだ。

技術的な内容は出てこなかった。


MIPI ‐ 通信用語の基礎知識

同期式とのこと。
ソース同期と書いてあるので、クロック線は持たず、データ自体がクロックと同じ意味を持つということか。
マンチェスターみたいな感じかな?
マンチェスターだと1bitを2データで表すが、差動だと1データ分の時間で2データを表現できるので、倍の速度になるのかも。
上限が1Gbpsとなっているので、なにか技術的に上限が発生するのだろうが・・・そこまではわからんな。


これで終わろうと思ったが、最後に見たページではもう少し情報が載っていた。
前田真一の最新実装技術あれこれ塾:第47回 内部ディスプレイ接続規格 (4/4) - MONOist(モノイスト)

高速モードは1.5Gbpsみたいだ。
そして、予想と違ってクロック線があり、ビデオ信号だとレーンを複数用意するようだ。
下手に予想するもんじゃないな。

2017/08/11

hexdumpで16進数を出力したい

バイナリファイルをソースコードに埋め込みたいことがある。
画像データを配列として使いたい場合などだ。

ファイルから読み込んで%02xなどで出力させるだけなのだが、いちいちコマンドを作るのも面倒だ。
hexdumpというコマンドがあるのでやってみたが、オプションを使えばなんとかいけそうなものの、よくわからん。
だいたい、なんで2バイトごとに出すのがデフォルトなんだ?


と、コマンドに文句を言ってもしょうがないので、オプションを調べよう。

hiro99ma blog: hexdumpのフォーマット

0xを付けた出力をしたい場合は、これでよい。
これは8バイトごとに改行しているので、8/1になっている。

$ hexdump -e '8/1 "0x%02x, " "\n"'  abcdef.bin


pythonで、ひたすらずらずら並べた文字列を作りたいこともある。

$ echo "$(hexdump -e '1/1 "%02x"' abcdef.bin)"

echoはなくてもよいのだけど、改行を付加しないので、コマンドラインで実行すると見づらかったのだ。


で、hexdumpを16進数の1桁ダンプ以外で使うことが無さそうなので、aliasに登録しようとした。

alias hexdump='hexdump -e '\''1/1 "%02x"'\'

いやあ、こんなに難しいとは。。
シングルクオーテーションで全体を囲む中にシングルクオーテーションを入れたい場合は、

  • 一度シングルクオーテーションを閉じる
  • \'を付ける
  • シングルクオーテーションを始める

ということをせんといかんそうだ。

青文字がシングルクオーテーションで囲んだ範囲、赤文字がエスケープしたシングルクオーテーションとなる。

alias hexdump='hexdump -e '\''1/1 "%02x"'\'


aliasをシングルクオーテーションで囲むのは、スペースも含めて入れてほしいという場合だけのはず。
まあ、これで登録しても、aliasコマンドで見ると

alias hexdump='hexdump -e '\''1/1 "%02x"'\'''

なんだけどね。

2017/08/07

[c/c++]lmdbでの検索

たまにはFPGAを離れて、DBのことをやってみるのもよいだろう。
そうだな、lmdbなんてどうだろうか?


最後にlmdbのことをやったときは、付属サンプルのmstest.cを見ていくだけだった。
今回は、KEYから検索したり、VALUEから検索するときのことを考えよう。



今のところ、私のlmdbに対するイメージはこうだ。

image


mdb_env_create()で1つのENVを作り、mdb_env_open()する。
ENVからmdb_txn_begin()でTXNを開始し、同じトランザクション内で処理したいものをmdb_dbi_open()でDBIを開く。
あとは、TXNとDBIのセットでmdb_put()したりmdb_get()したり。
終わってトランザクションを確定させたいなら、mdb_txn_commit()してmdb_dbi_close()。
変更したものを破棄するなり、読込むだけで保存するものが無ければ、mdb_txn_abort()だけ。
mdb_put/get()だけでなく、cursor系のAPIもある。


さて、検索するには、どのAPIを使うのがよいのか。。。

いまのところ、私の認識はこうだ。

  • KEYが指定できる場合は、mdb_get()
  • それ以外は、cursor系APIでDBIの中を全部探す

SQLではないので、自分でやるしかないだろう。
mdb_cmp()で比較するようなことができるのかと思ったが、関係なさそうだ。


自分でやるしかないので、全部KEY-VALUEに突っ込むだけではなく、DBIをうまいこと分散させるのもよいだろう。

2017/08/05

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

前回は、ZYBOのPmod JEをたたくドライバに載っているアドレスからリファレンスマニュアルを調べようとしたけど失敗した、というところまでだった。


ならば、正攻法で調べるしかあるまい。
Pmod JEからたどっていくのだ。

image

7本使っているが、1本見ればよかろう。

image

これはIC19Bなのだが、IC19AがZynqだから、これもZynqのピンなのだろう。
V12は、IO_L4P_TO_34という名称なのか。


これで検索して出てくればよかったのだが、それっぽいものが出てこない。
テクニカルマニュアルj_ug585-Zynq-7000-TRM.pdfの「2.8 PL I/Oピン」に載っているT[3:0]がそれか?

image

T0だから、メモリバイトグループT0に属するメモリバイトグループということか。


同じ表の中に、こういうのもあった。

image

IO_L3N_だから、こっちの可能性もある。

詳細は「パッケージおよびピン配置ガイド(pdf)」を参照とのこと。
別ドキュメントかー。


Zyboに搭載されているのは、ZYNQ XC7Z010-1CLG400C。

image

SIOとPS I/Oに大別されている。
PS I/OはPS側から制御するI/Oだろうから、SIOはPL側から制御するのかと思ったが、SIOは「SelectIOリソース」という意味らしいので、PSかPLかを選択できるのかもしれん。

ネットで検索すると、「7シリーズ FPGA SelectIOリソース ユーザーガイド」というPDFが出てきた。
7シリーズはZynqのPL部だから、PL部なのだろう。
Zynqの概略図でも、PL部に"Multi Standards I/Os"というものがあるし。
https://japan.xilinx.com/content/dam/xilinx/imgs/block-diagrams/zynq-mp-core-dual.png


IO_L4P_T0_34という名前だが、こういう意味になると思われる。

  • IO : ユーザーI/Oピン
  • L : 差動ペア
  • 4 : バンク固有のペア
  • P : 差動ペアの正側
  • T0 : メモリバイトグループT0に属する
  • 34 : バンク番号

さっぱりわかりません。。。


まず、バンクの説明図があった。
PLバンクの図らしい。

image

「すべてのHP I/Oバンクは完全にボンディングされていて、すべてのPSバンクは完全にボンディングされている」らしい。
HPと書いてあるけど、表ではHPが0本、HRが100本だったから、HR I/Oバンクだと思う。

  • HR : Hight Rangeバンクのことで、3.3V対応という意味のようだ
  • HP : Hight Performanceバンクのことで、1.8V対応という意味のようだ

Vivadoでも1.8Vを3.3Vに変更していたが、こういう意味があったのか。


ピン配置はASCIIファイルになっているらしい。
XC7Z010のCLG400はこれ
うん、V12はIO_L4P_T0_34で、メモリバイトグループ0、バンク34だね。
そして、I/Oタイプは「HR」とのこと。
さっきの図でBank 34 HRとなっていたから、そのままなのかな。


あとは、ピン配置の図と、ハンダ付けとかそういう説明があったが、今回はよかろう。
ピンの数は、20x20 = 400本のようだ。


わからなかった用語を検索しておく。

差動って、USBとかで使われている正負が逆転したやつだろうか?
それとも、差動増幅というやつだろうか。
なんとなく、前者っぽい。
https://ja.wikipedia.org/wiki/%E5%B7%AE%E5%8B%95%E4%BF%A1%E5%8F%B7#.E9.AB.98.E5.91.A8.E6.B3.A2IC.E3.81.AB.E3.81.8A.E3.81.91.E3.82.8B.E5.B9.B3.E8.A1.A1.E6.8E.A5.E7.B6.9A


というわけで、アドレスについては書いてなかった。

次はデバイスツリーを見る。
これにはアドレスが書いてあったはずなので、そこからたどれるかもしれん。
というより、アドレスを直接ドライバに書くのではなく、最終的にはデバイスツリーから取ってくるようにせんといかんのか。


0x41200000だが、ZynqではなくARMの方(plnx_arm-system.dts)に出てきた。
そっちか!

		gpio@41200000 {
			#gpio-cells = <0x2>;
			compatible = "xlnx,xps-gpio-1.00.a";
			gpio-controller;
			reg = <0x41200000 0x10000>;
			xlnx,all-inputs = <0x1>;
			xlnx,all-inputs-2 = <0x0>;
			xlnx,all-outputs = <0x0>;
			xlnx,all-outputs-2 = <0x0>;
			xlnx,dout-default = <0x0>;
			xlnx,dout-default-2 = <0x0>;
			xlnx,gpio-width = <0x4>;
			xlnx,gpio2-width = <0x20>;
			xlnx,interrupt-present = <0x0>;
			xlnx,is-dual = <0x0>;
			xlnx,tri-default = <0xffffffff>;
			xlnx,tri-default-2 = <0xffffffff>;
		};

ARMの方ではあるが、xlnxとなっているところが多いから、たぶんXilinxがカスタマイズしたのかな。


Zynqの概略PNGを見ると、PS部とPL部の接点は多くなかった。
そういえば、ZynqにAXI GPIOを追加したな。

image

今回のInterface誌に載っていた手順を振り返ると、こうだった。

  • Vivadoで新規プロジェクトを作る
  • AXI GPIOを追加する(Zyboのテンプレートを使ったので、ボード上のLEDにつながっていた)
  • GPIOのブロックを変更して、4bitを7bitにする
  • XDCファイルを変更して、ボード上のLEDからV12などに変更する

元々はボード上のLEDを制御するGPIOだったのだ。
だから、V12が0x41200000に割り振られているのではなく、AXI GPIOでアクセスする先頭が0x41200000で、AXI GPIOのつなぎ先をV12に変更した、というだけのことか。


いつものマイコンだと、ピンと機能が結びついていて、どの機能を有効にするかを設定する、というやり方だった。
FPGAでは、ある程度はピンの使い道を変更できるということだな。
「今回はUARTを2本使いたいけど、そうするとSPIが使えなくなるから、UARTの代わりに空いているI2CにしてFTDIのチップ載せるか」みたいなことはせず「今回はI2C使わないからUART2本とSPIに割り当てよう」ということができるのだ。


というわけで、Pmod JE --- AXI GPIO、というつながりで考えればよさそうだ。


では、Pmod JEのV12がAXI GPIOにつながっているとしよう。
次は、AXI GPIOがARMのGPIOにつながっていることを確認したい。

AXIバスだから、このルートだろう。

image

AXIバスはARMのAMBAバスにつながっているようだ。
AMBA Interconnect、というらしい。

image

インターコネクトは、Zynqテクニカルマニュアルの5章だ。
PSから書込みたいので、M_AXI_GPxになるのかな?

image

「Zynq-7000 All Programmable SoC Data Sheet」の最後の方にメモリマップがあった。
http://www.xilinx.com/support/documentation/data_sheets/ds190-Zynq-7000-Overview.pdf

image

0x4000_0000がPL AXI slave port #0なので、PSがマスター=M_AXI_GP0という認識と一致した。


「5.6.1章 AXI信号」に表があって、「読み出しアドレス」「書込みアドレス」などあるのだが、アドレスっぽい値が書かれていない。
変換できるのかもしれんが、ちょっと私には無理だな。。。

0x4000_0000 + 0x0120_0000、という計算だと思う。
この0x0120_0000というオフセットの計算方法が知りたいのだ。
デバイスツリーでは、0x4120_0000, 0x4121_0000, 0x4122_0000の3つがあるので、何かあると思うのだが・・・。


ZYNQのPS/PL通信をやってみた(4) GPIOテストコードを書く: なひたふJTAG日記

最初のステップでXPSで生成したAXI_GPIOを操作したいけどアドレスがどこにあるか・・・とかそういうことを調べる必要はありません。それらはxparameters.hをインクルードすることで解決されます。

なんですってー!

PetaLinuxのディレクトリ内をfindした。

$ find ./ -name xparameters.h
./tools/hsm/data/embeddedsw/ThirdParty/sw_services/openamp_v1_1/src/open-amp/obsolete/system/generic/machine/zynqmp_r5/xil_standalone_lib/xparameters.h
./tools/hsm/data/embeddedsw/XilinxProcessorIPLib/drivers/common_v1_00_a/src/xparameters.h

ファイルはあったのだが、4年も経過したからか、該当するマクロ名はなかった。
XPSじゃないしね。


しかし、ネットで検索していると、xparameters.hを使っている人が多い。
そして、XPAR_LED_xxxみたいなものもあるので、これは自動生成する類のものと思われる。
GPIOをソフトウェアから制御する | 特殊電子回路


Vivadoでプロジェクトを立ち上げ、Launch SDKして、Newで"Application Project"を選び、Hello Worldを選んだ。
そうすると、なにやらbspというプロジェクトもできている。
その中を見ていくと大量のincludeファイルがあり、xparameters.hもあった。

image

あー、こうやってアドレスがわかるのね。。。


あまり納得できたわけではないのだが、今回はこれでもいい気がしてきたので、これで話を進めよう。

2017/08/04

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

Zybo用にビルドしたPetaLinux v2017.2で、Digilent社のチュートリアルを動かしたいというシリーズ。

・・・なのだが、手始めにInterface誌2016年4月号に載っていたLEDサンプルを動かしている。
そういえば5月号はどんな内容なのだろう、と読んでみたら、私がLinux上で0~9に光らせるようにした処理をFPGA上でやる内容だった。

そこに行く前に、まず今のドライバがどういう作りになっているのかを確認し、Digilentのチュートリアルを動かして、とにかくこのシリーズを終わらせてしまおう。
とはいえ、まだまだかかりそうだな。。。


ドライバのソースファイルはこちら(Gist)。
original: http://www.cqpub.co.jp/interface/download/2016/4/IF1604Z.zip

ZIPとなってるが、元ファイルがZIP提供だったのでそういうタイトルを付けているだけで、リンク先はGistだから安心して欲しい。

ドライバの基本的な部分は、たぶんどこも同じだろうから省略しよう。
FPGAっぽいところ、今回で言えばGPIOアクセスに関係するところだけ見ていく。


そうなると、見るのはまずopen()から。
何かやっていそうなのは、ioremap()とkmalloc()くらいか。

bitは、minorの下位5bit分。
名前からして、デバイスファイルのMAJOR, MINORのminorだろう。
それが、bit = [16, 23] = [0x10, 0x17]の範囲はエラーなんだと。
確かに、mknodしたときは24にしていた。

minorのb4をmodeに割り当てていて、0だったらREAD、1だったらWRITEにしている。
24=0x18だから、WRITEだ。

cookieに使うgpio_table[bit >> 3]は、0x18(0) --> 0x0c(1) --> 0x06(2) --> 0x03(3)、となる。
gpio_table[3]は、

MAP_BASE_ADDR + LED_PIO_BASE + LED_PIO_DATA_OFFSET
  = 0x41200000 + 0x10000 + 0x0

だ。

アドレスが出てきたので、Zynqのリファレンスマニュアルを見ていこう。

image

左側のPLは「CPUおよびACP」、右側のPLは「その他のバスマスター」。

ここからたどっていけばわかるだろうと思ったのだが・・・さっぱりわからん!
GPIOのピンとアドレスがマッピングされているだけではないのか?

Zynqだからなのか、Cortex-Aだからか、いきなりリファレンスマニュアルを読むのは早すぎたようだ。。。

2017/08/02

[xfce]thunarでのパスコピー

Linuxの環境として、Xubuntu 16.04を使っている。
AndroidのビルドがUbuntuで説明されていたのでUbuntuを使いだし、でもUnityになって使い慣れず探していたら、見つかったのがXubuntuだった、という流れだ。
Unityは、メニューが画面上部固定なので、いちいちマウスカーソルを動かすのが面倒でね・・・。
廃止になるらしいから、次は試してみるかも。


Xubuntuは、ウィンドウシステムとしてXfceというのを使っている。
読めないけど、ネズミの絵が出てきたり、テキストエディタがMousepadだったりするので、似た発音なのかもしれない。
XfceのAboutを見ると「collection of programs」となっているので、ウィンドウシステム(xfwm4)を含んだ一式らしい。

さて、よく使うことになるファイルマネージャーだが、デフォルトではthunarというものになっている。

image

これの、パスをコピーする方法が分かっていなかったのだ。
ファイルを右クリックしてプロパティを表示させ、そこに載っているパスをコピーしていたのだけど、さすがにめんどくさいし、方法があるはずだ、ということで検索した。


[SOLVED] Thunar: what is hot key to display path (e.g. for copy)
Ctrl+Lで移動用ダイアログを表示させると現在のパスが出ているから、それでいんじゃないの、ということのようだ。
まあ、これはこれでよいか。


しかし、ファイル名を含んだパスだと、このあとでファイル名だけコピーせんといかんから面倒だな。。。
と、何気なくファイルコピーの要領で、ファイルを選択してCtrl+CしてMousepadにCtrl+Vすると、フルパスが入っているではないか!
空のディレクトリだと使えない技なのだが、それだったら1つ上に上がって選択すればよいか。

あとは、メニュー「View > Location Selector」で"Toolbar Style"にしてもよいかも。
これだと、パンくずリストではなく、昔のExplorerのようにテキストでコピーできる。
昔はレジストリの編集をしてまでもテキストボックスにしていたのだが、最近は「パンくずリストもありやん」と思うようになった。
まあ、あやつはクリックすると切り替わってくれるからな。


最近はXilinxのPetaLinuxを扱うこともあって、Linuxもよく使っているから、もうちょっと使い慣れないともったいない。
歳を取ると、使い慣れる時間がもったいない気もするのだが、まあ気長にやるさ。

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の設定だけにした。

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