便利なコマンド(備忘録用)

久しぶりの更新である。最近は仕事が忙しく、2月に掲げた目標をまだ達成できていない。GW明けも仕事が忙しくなりそうなので、少しずつ進められるように頑張る。
※GW中は旅行に行っていたので、進めておらず。。

今回はZyboの開発ではなく、Atomのショートカート操作や便利なコマンドなど、自分が覚えておきたい内容をまとめた。

目次

Atom

markdown や ソースコードの記述は、Atomを使用している。Atomには便利なパッケージが多いが、特に感動したのはverilog-HDL lintチェックができるパッケージ。Vivadoを使用しないでlintチェックできるので、開発スピードがかなり上がった。
atomを起動すると、たまに変なディレクトリの位置で開くことがある。カレントディレクトリの位置でatomを開きたい場合は、以下のコマンドを入力すればよい。

カレントディレクトリでatomを開きたい場合

atom ./

Word

普段、設計書を書くときは、markdownで記述してPandocにより「markdown → word」の変換を行っている。変換したwordを確認するときは、ポチポチとマウスを使って変換した.docをダブルクリックしていた。これが、地味にめんどくさい。そのため、コマンドを実行するとmarkdown → wordの変換とwordの起動を自動で行うようにしたい。

コマンドラインからWordを起動する方法

コマンドラインからwordを開く場合、以下のように「wordの実行ファイル」と「起動したいdocファイル」の両方を起動させる必要がある。 

"C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE" "D:\Dropbox\電子工作\マイコン\マイコンの汎用入出力.docx"


※そんなことは知らず./＊＊＊.docx と入力し、wordが開かないと悩んでいたこともあった。。

この上記コマンドを、「markdown → word」に変換するbash内に追記すれば、markdown → wordの変換とwordの起動を自動で行うようにできる。

コマンド

ファイルの検索

find ~/ -name tanuki.txt

フォルダ内のファイルを表示(tclコマンド)

glob *

とりあえずはこれくらい。今後も便利なものがあったら追記してゆく。

関連資料

  1. バッチファイルでエクセルを起動する方法
    http://www.tsukuru-hp.com/batch/dos_18.htm
  2. ATOMをコマンドラインから動かす
    https://qiita.com/coa00/items/a3136077d7b4506ecc71

AXI4-Stream to Video Out IPについて

AXI4-Stream to Video Out IPのデータシート#関連資料を読み、必要そうな情報をまとめた。このIPを理解するのが難しく、記事の内容が間違っているかもしれない。間違いは気づき次第修正する。

目次

概要

AXI4-Stream to Video Out IPは、Video Timing Controller（VTC）と組み合わせて使用し、AXI4-Stream I/Fをビデオ信号に変換するIPである。

入出力信号とブロック図

入出力信号とブロック図を下に示す。

ブロック図

信号名 方向 バス幅 説明
vid_io_out_clk in 1 ピクセルクロック
vid_io_out_ce in 1 ピクセルクロックのイネーブル信号
・Lowにするとvtg_ce信号もLowになる。
aclken in 1 AXI4-Stream I/F のイネーブル信号
・High：有効
・Low ：無効
aclk in 1 AXI4-Stream I/F のクロック
aresetn in 1 AXI4-Stream I/F のリセット信号
・ローアクティブ
vtg_ce out 1 VTCクロックイネーブル信号
fid in 1 AXI4-StreamバスのフィールドID
・0=even field
・1=odd field
vid_io_out_reset in 1 リセット信号、ハイアクティブ
・Independent clock modeのときのみ使用可能
locked out 1 VTCのロック信号
・アンロック時：0・ロック時：1
・ロック時、タイミング信号とビデオ信号が出力
overflow out 1 FIFOがアンダーフローしたことを示すフラグ
underflow out 1 FIFOがオーバーフローしたことを示すフラグ
status out 32 VTCの遅延とステートマシンの状態をモニタする信号
・デバック時に使用する
video_in in - スレーブAXI4-Stream I/F
vtiming_in^※2^ in - VTCのタイミング信号
・vtg_vsync
・vtg_hsync
・vtg_vblank
・vtg_hblank
・vtg_act_vid
・vtg_field_id
vid_io_outr^※3^ out - ビデオ信号
・vid_active_video
・vid_vsync
・vid_hsync
・vid_vblank
・vid_hblank
・vid_data
・vid_field_id
s_axis_video_tvalid in 1 有効なデータであることを示す信号
s_axis_video_tuser^※1^ in 1 ビデオフレームの先頭を示す信号
・SOF信号とも呼ぶ
s_axis_video_tlast^※1^ in 1 ビデオフレームの最後を示す信号
・EOF信号とも呼ぶ
s_axis_video_tready^※1^ out 1 FIFOのalmost full 信号


  • ※1 ：役立つか分からないが、自分の備忘録としてtuser、tlast、tready信号の波形を貼っておく。 波形EOF_SOF


  • ※2 ：Video Timing Controllerのタイミング信号はすべて出力させた方が良いらしい。また、Video Timing ControllerとAXI4-Stream I/Fの設定は、一致させないといけないらしい。

  • ※3 ：ビデオ信号「vid_data」の格納データは、下図に示すように、LSBから順番にGreen、Blue、Redとなっている。
    data_VideoOut


構成

AXI4-Stream to Video Output は下図に示すように3つのブロックから構成されている。これらの概要や入出力信号について説明する。

VideoInToAXI4-Stream

Data Formatter

Data Formatterはビデオ信号のI/Fを生成するブロック。 ロック信号がLow (VTCからタイミング信号と入力データのタイミングが一致していない)のとき、ビデオ信号とタイミング信号はすべて出力をOFFする。ロック信号がHigh になり、vblank信号の立ち上がりのタイミングで、ビデオ信号とタイミング信号が出力される。

疑問点

vblank信号とビデオ信号の出力タイミングの関係を表したシミュレーションの結果を下図に示す。シミュレーション結果を見るとvblank信号が8サイクル後に、ビデオ信号が出力されている。
てっきり、vblank信号が出力後すぐにビデオ信号が出力されるのだと思ったのだが、違うようだ。その理由が分かったら追記する。

DataFormatter01

Stream Coupler

Stream Couplerは、クロック載せ替え回路とバッファリングの役割を担うブロック。このブロックは、非同期FIFOとFIFOの入力側に配置している書き込みロジックにより構成されている。

Output Synchronizer

Output Synchronizerは、入力データとVTCからのタイミング信号の同期をとる役割を担うブロック。同期をとるための制御フローを下に示す。入力データとタイミング信号の同期は、Coarse AlignmentとFine Alignmentを行うことで実現する。

synchronizerDiagram

制御フローは、モードの設定によって異なる。モードは、スレーブモードとマスターモードの2種類存在する。上記の制御フローはスレーブモード時のものである。

  • スレーブモード ：VTCからのタイミング信号とSOF信号・EOF信号を比較し、入力データとタイミング信号の出力タイミングを一致させる。
  • マスターモード ：EOF信号のみを使用して、入力データとタイミング信号の出力タイミングを一致させる。
    ※データシートを見ると、Slave モードを推奨しているようだ。

シミュレーション結果を下図に示す。データシートと上記の制御フローに記載されている通りの動作が行われている。

Simulation01

疑問点

  • 使用したシミュレーションモデルは、マスターモードなのかスレーブモードなのかわかっていない。シミュレーションモデルのDUTのソースコードを見ると、C_VTG_MASTER_SLAVE = "0"となっていたので、おそらくスレーブモード?。

  • 使用したシミュレーションモデルは、Fine Alignment時にSOF信号とEOF信号のタイミングが4回連続で一致している。そのため、制御フローにある「VTC Leading」や「FIFO Leading」の動作は見られなかった。これらの動作時はどうなっているか分かったら追記する。

設定項目

このIPは、下図に示すように設定項目がある。これらについて説明する。

設定画面Vout

Pixels Per Clock

出力するピクセル数を選択する。この設定により、ビデオ信号のバス幅が変化する。選択項目は次の中から選択する。

  • 選択：1、2、4

Video Format

使用するビデオ信号のフォーマットを選択する。Autoを選択すると、入力ビデオ信号のビデオフォーマットに基づき、使用するビデオ信号のフォーマットが選択される。この設定により、ビデオ信号のバス幅が変化する。なお、ビデオ信号のバス幅は次の計算式から求められる。

AXI4S Vudeo Input Component Width

AXI4-Streamにより入力されるビデオ信号の各bit幅のこと。ManualとAutoで選択可能。Manualの場合は、次の中から選択する。

Native Video Output Component Width

出力するビデオ信号の各bit幅のこと

Clock モード

common モードと independent モードがある。

commonモード

commonモードは、video_inとvid_io_outが共通の同期クロックで動作している場合に使用する。このモードは、内部FIFOにあるクロック乗せ換え回路を使用しないため、リソースが節約できる。

independent モード

independent モードは、video_inとvid_io_outが非同期クロックで動作している場合に使用する。 aclkはvid_io_out_clkと同じかそれ以上の周波数であること。aclkがvid_io_out_clkよりも遅い場合、バッファリングが必要である。

Timing モード

Slave モードと Masterがある。これらの違いは、上記のOutput Synchronizerにて記載している。

Hysteresis Level

フレームバッファの「クッションレベル?」を定義するらしい。推奨する設定値は12~16の間。なお、FIFOの深さは次の式により決まるようだ。

  • FIFO depth min = 32 + FIFO initial Fill LeveL(Hysteresis Levelのこと?)

シミュレーションモデル

このIPコアには、下図に示すようにシミュレーションモデルが存在する。上記で示したいくつかのシミュレーション結果は、このシミュレーションモデルを使用したものである。
初めてシミュレーションモデルがあることに気が付いた。シミュレーションモデルの使い方は別の記事で説明する。

IPCoreTable

おわりに

データシートを読んで半分くらい理解できた気がする。残りは実際に設計したときに理解できるようにしたい。

関連資料

  1. AXI4-Stream to Video Out v4.0
    https://japan.xilinx.com/support/documentation/ip_documentation/v_axi4s_vid_out/v4_0/pg044_v_axis_vid_out.pdf
  2. Video Beginner Series 8: Debugging the AXI4-Stream to Video Out IP
    https://forums.xilinx.com/t5/Video/Video-Beginner-Series-8-Debugging-the-AXI4-Stream-to-Video-Out/td-p/866346

Video Timing Controllerについて

Video Timing Controllerのデータシート#関連資料を読んで、必要そうな情報をまとめた。データシートが英語版しかないためにgoogle翻訳を活用したが、そのせいで怪しい日本語になっているかも・・・

目次

機能

  • タイミング信号(水平同期信号および垂直同期信号)、Active Videoエリアの出力
  • タイミング信号の信号論理は個別に切替可能
  • タイミング信号(水平同期信号や垂直同期信号)、信号論理およびActive Videoエリアの検出
  • 検出可能な最大ビデオフレームサイズは最大8192クロック
  • AXI4-liteインタフェースにより、設定値を動的に変更可能

ブロック図と入出力信号

ブロック図と入出力信号を以下に示す。

ブロック図

信号名 方向 バス幅 説明
clk in 1 ピクセルクロック^※1^
clken in 1 IPコアのイネーブル信号^※2^
・low：動作停止
・high:動作開始
det_clken in 1 Timing Detectionのクロックイネーブル信号
・low：無効
・high:有効
gen_clken in 1 Timing Generatorのクロックイネーブル信号
・low：無効
・high:有効
resetn in 1 ローアクティブのリセット信号
s_axi_aclk in 1 AXI I/Fの動作クロック
s_axi_aclken in 1 AXI I/Fのリセット信号(ローアクティブ)
ctrl - - AXI4-Lite I/F
fsync_in in 1 フレーム同期入力信号
フレームごとに1クロックイネーブル信号を入力すると、内部ジェネレータカウンタがリセットされ、この入力に同期して生成されたフレームタイミングのカウントが開始
fsync_out out - フレーム同期出力信号
各フレームの同期bitが1クロック出力される。
irq out - IRQ信号、ハイアクティブ信号
vtiming_in in - Detector I/F
・active_video_in
・hblank_in
・hsync_in
・vblank_in
・vsync_in
vtiming_out out - Generator I/F
・active_video_out
　　-：High：Active Videoエリア
　　-：Low ：Blanking Videoエリア
・hblank_out
・hsync_out
・vblank_out
・vsync_out

※１：clk信号が未入力の場合、AXIはすべてのアドレスに対してスレーブエラー応答(0x2)をアサート
※２：Lowの場合、AXI I/Fはすべてのアドレスに対してスレーブエラー応答(0x2)をアサート

各機能の説明

Video Timing Conntrollerはタイミング信号の検出および、出力という２つの役割がある。

概念図

タイミング信号の出力は、下図にあるようにタイミング信号(Active Video(Active Videoエリアであることを示す)、H Blank、H Sync、V Blank、V Sync)を出力する。タイミング信号の検出は、入力されたタイミング信号(H Blank、H Sync、V Blank、V Sync)を検出する。

疑問：検出した値はAXI I/F経由で取得しないといけない?

画面

Video Timing Detection

入力ビデオ信号のタイミングを検出するために、最大で6つの入力信号（active_video_in、hblank_in、hsync_in、vblank_in、vsync_in 、active_chroma_in）がオプションとして設定できる。検出信号の設定(有効/無効)は、下図の赤枠にあるチェックボックスにより行う。

VTD

Video Timing Generation

最大で6つのビデオ出力信号（active_video_out、hblank_out、hsync_out、vblank_out、vsync_out 、active_chroma_out）を生成できる。ビデオ出力信号の設定(有効/無効)は、下図の青枠にあるチェックボックスにより行う。

VTG

またビデオ出力信号の極性は、下図の青枠にある各項目を選択(High/Low)することで変更できる。

極性

関連資料

  1. Video Timing Controller v6.1、PG016
    https://www.xilinx.com/support/documentation/ip_documentation/v_tc/v6_1/pg016_v_tc.pdf

  2. Video In to AXI4-Stream v4.0、PG043
    https://www.xilinx.com/support/documentation/ip_documentation/v_vid_in_axi4s/v4_0/pg043_v_vid_in_axi4s.pdf

2月の目標

FPGA vivado zybo
  • カメラモジュールから取得した画像をディスプレイに表示させる

構成図

今までやりたいと思っていたが、仕事の忙しさを言い訳にしてやらずにいた。ただ、これを一気に作りあげるのは無理だと思うので、ステップを踏んで進めていきたい。考えているのは、次のステップである。

  1. Test Pattern GeneratorとVideo Timing Controller、AXI4-Stream to Video Outを使用してディスプレイにテストパターンをVGA表示させる。

  2. 上記にDMA IPを追加して、DDRに保存している画像をディスプレイに表示させる。

  3. カメラインタフェースIPコアを作成し、カメラから取得した画像をディスプレイに表示させる。

あくまで、たたき台なので設計途中で変更する可能性がある。まずは、使用する予定である次のIPコアについてデータシートを読む。

  • Test Pattern Generator
  • Video Timing Controller
  • AXI4-Stream to Video Out

参考サイト

  1. Connecting test pattern generator to VGA output on ZYBO
    https://lauri.võsandi.com/hdl/zynq/xilinx-test-pattern-generator.html
  2. Video capture with VDMA
    https://lauri.võsandi.com/hdl/zynq/xilinx-video-capture.html
  3. BASYS3でディスプレイ出力
    http://aster-ism.hatenablog.com/entry/2014/11/26/204009

一月を振り返って

1月はノロウイルスやインフルエンザにかかり、つらい思い出しかなかった。ブログは10投稿できたので、満足している。来月も10投稿を目指したい。

目次

ノロウイルス感染(1/5-8)

ノロウイルスにかかったときは、前日に軽くお酒を飲んでいたため二日酔いのせいだと思ってた。ただ、3時間たっても吐き気が収まらず嘔吐し、その後も吐き気が収まらなかったので病院に行った。

最初に行った病院はすべて適当で、ノロウイルスかもしれないと受け付けで説明したのに隔離室にも案内されず、患者さんがたくさんいる待合場所で待機させられた。周りはインフルエンザらしき患者さんや妊婦、赤ちゃんがおり、病院は妊婦や赤ちゃんにノロウイルスやインフルエンザがうつることを考えていないのか疑問に思った。

しかも、診察までに3時間半も待たされた挙句、すごく適当な医者に当たってしまった。ノロウイルスの検査は保険対象外で高い費用がかかる、陽性だとしても治療内容は変わらないのでやる必要がない、とのこと。医者に検査しない方がよいと説得され、診察がすぐに終了した。診察時間は１・2分だったと思う。異様に短かった。仕方がないので、整腸剤を貰って家に帰った。

夕方ごろに38.6℃の高熱がでて、全身から筋肉痛のような痛みが出た。これは、あの病院のせいで、インフルエンザにかかったのかと思い、今度は違う病院で診察してもらうことにした。違う病院に電話を掛けたところ、インフルエンザは発症後12時間が経過してからでないと検査ができないと言われた。仕方がなく、次の日に病院に行くことにした。

受け付けに行くと、すぐに隔離室に案内された。前の病院とは大違いである。隔離室で待っていると、看護師さんが来て、お金は発生しますがノロウイルスの検査をした方がよいと説明された。ぜひとも検査したいと思っていたので、喜んで了承した。検査は便を採取するらしく、お尻の穴に綿棒を入れ、ほじほじされた。少し恥ずかしかった。

しばらく待った後、診察を受けた。検査結果は陰性だったが、症状からノロウイルスにかかっていたとのこと。発症から検査までに2日もたったので、その間にウイルスが弱まったのだとか。最初の目的であるインフルエンザの検査は行ってくれなかったが(病院で熱を測ったときは、37.3℃だったせいかも)、お医者さんはノロウイルスの検査をしてくれ、かつ丁寧に診察結果を説明してくれた。次の日38℃以上の熱が出たらインフルエンザの検査をしますので、来てくださいと言われた。

診察後は、整腸剤と漢方を処方してくれた。前の病院は1種類しか整腸剤をくれなかったが、今回の病院は3種類の整腸剤を処方してくれた。この違いは何なのか。しかも薬剤師さんが丁寧に説明してくれる。病院以外でも対応が雲泥の差であった。もう、あの病院には絶対に行かないと誓った。

ちなみに、医者や看護師に「生カキを食べたんですと、」言うと、必ず「えっ！！そんな危険なもの食べたんですか。ありえないですよ」みたいな雰囲気を出された。医療業界では、生ガキを食べるのはあり得ないようだった。

インフルエンザ感染(1/26-31)

インフルエンザの症状は急にきた。はじめは、頭痛が少しするぐらいだった。その2時間後、急に寒気がするようになった。布団に入っても寒気が収まらず、熱を測ってみると38.3℃の高熱が出ていた。その後も熱が上がり、最高で39.3℃となった。その時は、全身の痛みとだるさと頭の痛みが酷く、息をするだけで精いっぱいだった。症状が発症してから12時間以上経過しないと、インフルエンザの検査ができないと前回のおかげで知ったので、その日は家でおとなしくしていた。辛すぎで全然眠れなかった。

その日は日曜日だったので、緊急外来に診察可能か電話した。診察できることになったので、朝の6時半から病院に向かった。病院に到着後、すぐに隔離室に案内され、インフルエンザの検査を受けることになった。インフルエンザの検査は、鼻の粘膜を採取するらしく、綿棒を両鼻に入れられ、ほじほじされた。そ

その後、しばらく待つと、別の患者さんが隔離室に来た。看護師とのやり取りを聞いていると、その人もインフルエンザにかかっているようだった。僕と同じく鼻をほじほじさせられてた。

検査してから20分後ぐらいに、診察を受けた。検査結果はインフルエンザのA型とのこと。結果を言うとき、このお医者さんはすごく申し訳なさそうにしていた。まったく悪いことしていないのに。インフルエンザの薬は吸入薬と新薬で一回で済むやつどっちにしますか?と言われたので、「新薬で」と答えた。薬をもらった後に気づいたのだが、その薬はゾフルーザで最近話題のものだった。

解熱剤ももらったのだが、これは素晴らしく効果が出た。飲んで1時間後には38℃→36.8℃まで下がった。ここまで下がると、もうインフルエンザが完治したんだと勘違いするが、薬の効果が切れる5時間後には38.6℃に戻っていた。解熱剤の投与間隔は6時間おきらしく、薬の効果が薄れるこの1時間は苦痛であった。

ゾフルーザの効果もあってインフルエンザ発症から3日目には平熱に戻っていた。だた、会社に電話したら一週間は出勤停止と言われた。今年は有休を使いすぎたため、残り2日しか有休が残っていない。有休がチャージされる4月までは、健康でいなければならない。

出勤停止中にpythonで家計簿を自動でつけるプログラムを作成した。クレジットカードの明細表(csvファイル)を読み、10種類の項目に分類し、その結果をcsvファイルに出力するものである。

イーサが動かない問題

ping zybo linux Ubuntu

はじめに

初めて作成したLinuxのイメージは、イーサが動かなかった(pingが応答しない)。原因は次の3つによるものであったが、これを見つけ出すのにすごく時間がかかった。


備忘録として、問題の解決策と原因を見つけ出すときに役立ったことをまとめる。

目次


イーサの原因調査

調査１：Ether PHYのリセット有効

LINK LEDや ACT LEDが点灯しなかったので、イーサが動かない原因は、Ether PHYのリセットが解除されていないのだと仮定した。

調査内容

  • 回路図とリファレンスマニュアルより、Ether PHYのリセット信号の接続関係や論理について調べる。

Zyboのリファレンスマニュアルより、イーサのブロック図を見ると、PHYのリセット信号「PHYRSTB」がFPGAにつながっていた。

イーサのブロック図

そして、Ether PHYのデータシートからリセット信号「PHYRSTB」の論理を見ると、ローアクティブであった。

リセット信号

Zyboの回路図を見ると、この信号は3.3vでプルアップされているので、FPGA側をLowに落とさない限り、電源投入後にリセットは解除される。

イーサ回路図

ただ、リセットが解除されていることを明示的にするため、トップモジュールに次を記述した。

module TopZybo(
+   output wire        ETH_RST_B,
    );
+    assign ETH_RST_B=1'b1;


調査結果

イーサが動かない原因は、Ether PHYのリセット信号によるものではなかった。

調査2：デバイスツリーの記述

次に、デバイスツリーの記述を疑った。ネットで検索すると、Xilinxのリポジトリにあるデバイスツリーは、MDIOの記述がないらしい。

調査内容

  • MDIOのデバイスツリーを記載する箇所と記載内容を調査する。

ダウンロードしたXilinxのリポジトリにあるデバイスツリーzynq-7000.dtsiを見ると、確かにMDIOの記載がなかった。他のデバイスツリーにもMDIOについては記載していなかった。 

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


一方、digilentのデバイスツリーzynq-zybo.dtsを見るとMIDOの記載があった。試しに、このデバイスツリーを使用したのがだ、イーサは動かないままであった。 

ps7_ethernet_0: ps7-ethernet@e000b000 {
    #address-cells = <1>;
    #size-cells = <0>;
    clock-names = "ref_clk", "aper_clk";
    clocks = <&clkc 13>, <&clkc 30>;
    compatible = "xlnx,ps7-ethernet-1.00.a";
    interrupt-parent = <&ps7_scugic_0>;
    interrupts = <0 22 4>;
    phy-handle = <&phy0>;
    phy-mode = "rgmii-id";
    reg = <0xe000b000 0x1000>;
    xlnx,eth-mode = <0x1>;
    xlnx,has-mdio = <0x1>;
    xlnx,ptp-enet-clock = <108333336>;
    mdio {
        #address-cells = <1>;
        #size-cells = <0>;
        phy0: phy@1 {
            compatible = "realtek,RTL8211E";
            device_type = "ethernet-phy";
            reg = <1>;
        } ;
    } ;
} ;


digilentのフォーラムを色々と検索していると、同じ問題に遭遇している人が書き込みしていた参考サイト：No.4。参考サイト：No.5より、どうやら、Ether PHYの情報はボード固有のものなので、zynq-7000.dtsiには書き込まないらしい。そこで、フォーラムの内容を参考に、MIDOのデバイスツリーを追加した。その内容は、ここで説明している。

調査結果

  • MDIOのデバイスツリーの記述が抜けていた。
  • ただし、この記述を追加しても、イーサは動かなかった。

調査3：U-bootでイーサの動作確認

デバイスツリーを修正したにもかかわらず、イーサが動かなかった。原因がデバイスツリー側によるものなのか、Ubuntu側によるものなのか、わからなかった。そこで、デバイスツリーが正しいことを確認するために、U-bootでイーサの動作を行った。

調査内容

  • U-bootでイーサの動作を行い、デバイスツリーが正しいか確認する。

U-bootでイーサの動作確認(ping応答)を確認するために、IPアドレスの設定を行う。参考サイト：No.6-7を参考にしている。

手順

1.次のコマンドを入力し、IPアドレスを設定する。
Zynq> setenv ipaddr 192.168.1.10

2.設定したアドレスが反映されているか確認する。
Zynq> print ipaddr
ipaddrの後に設定したアドレスが記載されていればよい。
ipaddr=192.168.1.10

3.ping応答によるイーサの動作確認を行う。デバイスツリーの設定が正しければ2回目にはping応答確認が成功する。

Zynq> ping 192.168.1.5
ethernet@e000b000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
ping failed; host 192.168.1.5 is not alive
Zynq> ping 192.168.1.5
Using ethernet@e000b000 device
host 192.168.1.5 is alive


デバイスツリーの設定が間違えていた場合、2回目以降もping応答は失敗するとの表示が出る。

Zynq> ping 192.168.1.5
Using ethernet@e000b000 device

ARP Retry count exceeded; starting again
ping failed; host 192.168.1.5 is not alive


4.ちなみに、ping応答に失敗した場合、PHYの初期化がどこまで確認されたか確認した方がよい。その場合のコマンドと結果を次に示す。

Zynq> mii info
PHY 0x00: OUI = 0x0732, Model = 0x11, Rev = 0x05, 100baseT, FDX
PHY 0x01: OUI = 0x0732, Model = 0x11, Rev = 0x05, 100baseT, FDX
Zynq> mii dump
0.     (1140)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:0040) 0. 6,13 =   b10    speed selection = 1000 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)


speed selection が1000 Mbpsに設定されていれば、初期化は正常に行われている可能性が高い。逆に、speed selection が10 Mbpsに設定されていれば、初期化は失敗している可能性が非常に高い。

調査結果

  • U-bootでイーサが正常に動作することを確認した。
  • デバイスツリーは正しく設定されており、Ubuntu側に問題があることが分かった

調査4：Ubuntu側の設定確認

調査3より、イーサが動かない原因はUbuntu側にあることが分かった。Ubuntuでイーサが動かない原因を調査する。

調査内容

  • Ubuntuでイーサが動かない原因を調査する。

手順

1.ifconfigでネットワーク状況を確認する。

ita@ita-VirtualBox:~$ ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12136 (12.1 KB)  TX bytes:12136 (12.1 KB)

表示では、eth0が表示されていなかった。

2.次に、ifconfig -a コマンドを入力し、稼働していないネットワークも含めて状況を確認した。 でネットワーク状況を確認する。

eth0      Link encap:Ethernet  HWaddr e2:7c:ef:97:da:b4
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 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:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:28 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12136 (12.1 KB)  TX bytes:12136 (12.1 KB)

sit0      Link encap:IPv6-in-IPv4
          NOARP  MTU:1480  Metric:1
          RX packets:0 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:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0は認識されてはいるが、IPアドレスが設定されていないようだった。そこで、eth0のIPアドレスを設定する。
3.sudo ifconfig eth0 192.168.1.10とコマンドを入力し、IPアドレスを設定する。

ita@ita-VirtualBox:~$ sudo ifconfig eth0 192.168.1.10
sudo: unable to resolve host ita-VirtualBox: Connection refused


4.ifconfigでネットワーク状況を確認する。

[sudo] password for ita:
ita@ita-VirtualBox:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr e2:7c:ef:97:da:b4
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::e07c:efff:fe97:dab4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:43 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3442 (3.4 KB)  TX bytes:656 (656.0 B)
          Interrupt:28 Base address:0xb000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:836 errors:0 dropped:0 overruns:0 frame:0
          TX packets:836 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:61864 (61.8 KB)  TX bytes:61864 (61.8 KB)

eth0が表示されるようになった。

5.この状態で、pingの応答確認を行う。

ita@ita-VirtualBox:~$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=128 time=0.452 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=128 time=0.364 ms
64 bytes from 192.168.1.5: icmp_seq=3 ttl=128 time=0.380 ms
64 bytes from 192.168.1.5: icmp_seq=4 ttl=128 time=0.384 ms
64 bytes from 192.168.1.5: icmp_seq=5 ttl=128 time=0.476 ms


IPアドレスを設定することで、Ubuntu側でイーサが動作した。 ただし、電源投入時に毎回IPアドレスの設定しなければならないので、設定ファイルを書き換えた。

6.設定ファイルの変更(IPアドレス追加) 方法は、ここ記載している。

これにより、毎回IPアドレスを設定しなくてもUbuntu側でイーサが動作する。ただし、windows側ではping応答に失敗することが分かった。次は、この原因を調査する。


調査結果

調査5：Window側の設定確認

Ubuntu側(Zybo)でイーサが動作したが、windows側ではping応答に失敗する。その原因を調査する。

調査内容

  • windows側ではping応答に失敗する原因の調査

参考サイト：No.8に記載されているが、Windows10 はファイアウォールのせいで、ping応答に失敗するらしい。そこで、この参考サイトに従って設定を変更したところ、Windows10からもping応答が成功した。

調査結果

色々試して大変だったが、問題が解決できてよかった。

参考サイト

  1. Zyboリファレンスマニュアル
    https://reference.digilentinc.com/reference/programmable-logic/zybo/reference-manual

  2. Ether PHYデータシート：RTL8211E
    http://download3.dvd-driver.cz/realtek/datasheets/pdf/rtl8211e(g)-vb(vl)-cg_datasheet_1.6.pdf

  3. Zybo回路図
    https://reference.digilentinc.com/_media/reference/programmable-logic/zybo/zybo_sch.pdf

  4. Ethernet for Zybo Linux
    https://forum.digilentinc.com/topic/9503-ethernet-for-zybo-linux/

  5. PetaLinux - システムのデバイスツリー DTS にイーサネット PHY 情報が含まれていない
    https://japan.xilinx.com/support/answers/61117.html

  6. U-Bootコマンドの使用
    http://www.u-boot.jp/download/Documents/uboot-commands.pdf

  7. Zynq 7010: u-boot PHY is not detected
    https://forums.xilinx.com/t5/Embedded-Linux/Zynq-7010-u-boot-PHY-is-not-detected/td-p/804993

  8. [Windows] Windows10 で ping が応答しない場合に確認すべき内容（Windows ファイアウォール） https://blog.dreamhive.co.jp/mkoba/?p=6055

zImageの作成ファイルの生成

FPGA linux ビルド

zImageファイルの生成手順について記載する。これも、参考サイト：No.1と同じことを行っている。

目次


前提条件

  • 使用するOSがUbuntu16.04 LTS であること。
  • 使用するvivadoのバージョンは、2018.2であること。

手順

この手順は、Xilinxリポジトリよりlinuxカーネルをダウンロードするところから、zImageファイルの生成まで説明する。


Xilinxリポジトリよりlinuxカーネルをダウンロード

次コマンドを入力し、Xilinxリポジトリよりlinuxカーネルをダウンロードする。
git clone https://github.com/Xilinx/linux-xlnx.git

ダウンロード完了後、linux-xlnxというディレクトリが生成されるので、そのディレクトリに移動する。
cd linux-xlnx

使用するvivadoのバージョンでブランチを切る。今回は2018.2なので、xilinx-v2018.2でチェックアウトし、xilinx-v2018.2_zyboというブランチを作成する
git checkout -b xilinx-v2018.2_zybo refs/tags/xilinx-v2018.2

zImageファイルの生成

次のコマンドを入力し、ビルドを行う。 

make ARCH=arm xilinx_zynq_defconfig
make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

ビルドが完了後、zImageが./arch/arm/boot/のディレクトリ内に生成される。

参考サイト

  1. zyboでXilinxリポジトリのu-bootとLinuxを動かす
    https://qiita.com/yoshiyasu1111/items/3cd78790c5e9df6beec1