SDSoC

SDSoC 2015.2 のチュートリアルをやってみた1(新規プロジェクトの作製)
SDSoC 2015.2 のライセンスが手に入ったので、使ってみた。
”SDSoC 環境ユーザー ガイド 入門 UG1028 (v2015.2) 2015 年 7 月 20 日”の18ページ”第 2 章 チュートリアル : プロジェクトの作成、ビルド、実行”をやってみることにした。
SDSoC 2015.2 のチュートリアルをやってみた2(ハードウェア・アクセレーション)
前回は、SDSoC の新規プロジェクトを作製して、テンプレートに Matrix Multiplication and Addition を選択し、SDRelease でビルドした。
今回はその続きから行う。なお、”SDSoC 環境ユーザー ガイド 入門 UG1028 (v2015.2) 2015 年 7 月 20 日”の18ページ”第 2 章 チュートリアル : プロジェクトの作成、ビルド、実行”の21ページ”ハードウェア インプリメンテーション用の関数のマーク”からをやってみる。
SDSoC 2015.2 のチュートリアルのファイル構造を確認してみた
SDSoC 2015.2 のファイル構造を見ていくことにする。プロジェクトは、”SDSoC 2015.2 のチュートリアルをやってみた2(ハードウェア・アクセレーション)”とする。
SDSoC 2015.2 のチュートリアル2(システム最適化)をやってみた1
”SDSoC 環境ユーザー ガイド 入門 UG1028 (v2015.2) 2015 年 7 月 20 日”の 28 ページの”第3章 チュートリアル : システム最適化”をやってみた。
SDSoC 2015.2 のチュートリアル2(システム最適化)をやってみた2
データ ムーバー選択の制御をやってみた。
SDSoC 2015.2 のZYBO用サンプルデザインをやってみる1(File IO Video Processing)
今までやってきた SDSoC のチュートリアルは ZC702 ボード用なので、ZC702 ボードを持っていない私には実機動作ができない。
今回はZYBO用のサンプルデザインをやって、ZYBOで実機動作させてみようと思う。
File IO Video Processing をやってみようとしたが、yuvの画像を要求されるので、実機テストは出来なかった。
SDSoC 2015.2 のZYBO用サンプルデザインをやってみる2(Matrix Multiplication)
ZC702 でもやってたMatrix Multiplication のサンプルをやることで、ZYBOの実機でテストすることを目指す。成功して、HW の方が SW よりも 29 倍速いという結果になった。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した1(ソースの公開)
SDSoC のチュートリアルをある程度やってきて、大体、雰囲気が分かったので、いつものラプラシアンフィルタを題材にハードウェアとソフトウェアの性能差を測ってみることにした。
ソースコードを貼り付けた。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した2(ソフトウェアのみでテスト)
とりあえず、ソフトウェアのみでテストしてみた。
800x600の画像もラプラシアンフィルタ処理が出来て、ハードウェア(HW)(まだハードウェアにしていないけど)が 61.3 ms、ソフトウェア(SW)が 47.4 ms だった。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した3(ソフトウェアのみでテスト2)
前回は、ラプラシアンフィルタのハードウェアとソフトウェアで動かすアプリケーションを作製し た。但し、ハードウェアの実装はテストのため、まずはソフトウェアで実装し、ZYBOで試した。その際に、ラプラシアンフィルタの実装は、ハードウェア、ソフ トウェアとも同じで、ソフトウェアの方が malloc() でメモリをアロケートしているので、ソフトウェアの遅いはずなのだが、速くなった。
これはキャッシュの問題かもしれないということで、ラプラシアンフィルタ処理の前にダミーのラプラシアンフィルタ処理を置いてみた。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した4(ハードウェア化)
前回まで、ソフトウェアで性能の評価を行ったが、今回は、lap_filter_axim() をハードウェアにする。
ラプラシアンフィルタのワークスペースをBRAM に取るらしいので、800x600ピクセルの画像はラプラシアンフィルタ処理出来なかった。
SDカードに書いてZYBOの実機で試してみたところハードウェアでのラプラシアンフィルタの処理時間は590 us ソフトウェアでのラプラシアンフィルタの処理時間は 300 us 程度で、ハードウェアの方が遅かった。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した5(ハードウェア化2)
前回はハードウェア化したほうが遅いという結果が出たが、今回はmalloc() をすべて sds_alloc() に、free() を sds_free() にして、性能を測ってみた。こうすると物理メモリが連続的に取得され、ハードウェアに有利になるはずだ。
./lap_filter2.elf を実行したところ、ハードウェアのラプラシアンフィルタ処理時間は 503 us 、ソフトウェアのラプラシアンフィルタ処理時間は安定しない。最低は 600 us で、最高は、14.1 ms程度だった。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した6(ハードウェア化3)
いまのところハードウェアの配列の引数がVivado HLSでハードウェア化されるとBRAMへのインターフェースになっていて、ZYBOのBRAMを超える大きさの画像が扱えない。大きな画像が扱えるために、Vivado HLSで生成されるラプラシアンフィルタ処理用IPのポートをAXI4 Master にしようと思っているのだが、どうもうまく行かなかった。
ハードウェア化する関数で、Vivado HLSの様に m_axiの pragma を使用してAXI4 Master ポートにする方法だ。このように修正してもやはりBRAMを超える大きさの画像は扱えない。この方法でやってみることにした。ソースコードを貼り付けた。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した7(ハードウェア化4)
前回は、ハードウェア化する関数をAXI4 Master ポート入出力にする方法を発見して、ラプラシアンフィルタのハードウェア、ソフトウェアで実装した時の性能を確認した。その結果は、約4.5倍、ハードウェアの方が遅く なってしまった。
今回はハードウェア化する関数 lap_filter_axim() の書き方をVivado HLS でやったように memcpy() で書き換えてどのくらいハードウェアが速くなるのかやってみた。
ハードウェアでのラプラシアンフィルタ処理時間は 410 us, ソフトウェアでのラプラシアンフィルタ処理時間は 299 us だった。ハードウェア用のラプラシアンフィルタ処理時間はソフトウェアのラプラシアンフィルタ処理時間の 410 us / 299 us ≒ 1.37 倍になった。よって、性能は 0.72 倍になった。まだハードウェアの方が遅いが性能差はずいぶんと縮まった。
SDSoC 2015.2 でハードウェアとソフトウェアのラプラシアンフィルタの性能を比較した8(ハードウェア化5)
前回はハードウェア化したラプラシアンフィルタ処理時間は 3.29 倍速くなったが、まだソフトウェア処理よりも遅かった。
次に、Vivado HLS で tu1978 さんが書き換えてくれたコードで試してみた。C++だと、テストベンチがC だったからか? extern "C" しても うまく行かなかったので、Cに書き換えて使用した。
ハードウェアでのラプラシアンフィルタ処理時間は 153 us で、ソフトウェアでのラプラシアンフィルタ処理時間は299 us だった。ハードウェアでのラプラシアンフィルタ処理時間はソフトウェアでのラプラシアンフィルタ処理時間よりも 0.517 倍に短くなった。つまり性能は 1.95 倍になった。

SDSoC のエディタに行番号を表示させる
SDSoC のエディタに行番号を表示させる方法を書いておく。

SDSoC 2015.2で motion detect demo をやってみる
HDMI入力は一通りできたので、今度はSDSoC に戻って、使い込んでみたいと思う。
まずは、HDMI への入出力をどうするか?というのが疑問だったので、D:\Xilinx\SDSoC\2015.2\docs フォルダにある zc702_hdm.pdf に従ってやってみることにした。

SDSoC 2016.2 でラプラシアンフィルタをテスト1
前回、SDSoC を試したのはSDSoC 2015.2 の時だったが、今回、SDSoC 2016.2 でもう一度、確かめてみよう。
前回やってみたラプラシアンフィルタをそのまま SDSoC 2016.2 でやってみようと思う。
SDSoC 2016.2 でラプラシアンフィルタをテスト2
前回は、SDSoC 2016.2 を使用して、すべてソフトウェアで実装したラプラシアンフィルタをコンパイルし、ZYBO 実機でテストした。今回は、ラプラシアンフィルタをハードウェアにして性能を確かめてみよう。
SDSoC 2016.2 でラプラシアンフィルタをテスト3
前回、SDSoC 2015.2 と同様に SDSoC 2016.2 でも 800 x 600 ピクセルの画像をラプラシアンフィルタ処理することはできなかった。それで、前回同様に、64 x 48 ピクセルでやってみることにした。

Zynq 用SDx v2016.3 を使ってみる1
SDSoC 2016.3 が出ているが、名前が変更されて、SDAccel と SDSoC が統合されてSDx になったようだ。Zynq 用のSDx が SDSoC なんだと思う。
さて、SDx v2016.3 を起動してみた。下の図に示す。すでにlap_filter2 プロジェクトはSDx v2016.3 にコンバートされている。


SDSoC のプラットフォームのお勉強1
SDSoC にはプラットフォームというベースとなるハードウェアとソフトウェアの集合がある。例えば、ハードウェアで言うとHDMI を使用するようなハードウェアをアクセラレーションしたいとすると、SDSoC がどう頑張ってもHDMI をサポートするハードウェアを直接出力することはできない。HDMI を扱うベースとなるハードウェアが必要となる。そのベースのプラットフォームを自由に作りたいと思っている。今回は、”SDSoC Environment Platform Development Guide UG1146 (v2016.3) November 30, 2016” を読みながら、SDSoC のプラットフォームについて勉強していくことにする。
SDSoC のプラットフォームのお勉強2
前回はプラットフォームの構成ファイルや構成フォルダを見てきた。今回は、ハードウェア・プ ラットフォームの作り方を見ていこう。
SDSoC のプラットフォームのお勉強3(ハードウェア・プラットフォームの試作1)
前回は、ハードウェア・プラットフォームの作り方を見てきた。今回は、試しにハードウェア・プ ラットフォームを作成するためにVivado 2016.3 のプロジェクトを作った。
SDSoC のプラットフォームのお勉強4(ハードウェア・プラットフォームのメタデータファイルを作る1)
前回はハードウェア・プラットフォームを作成するためのVivado 2016.3 のプロジェクトを作った。今回は、Tcl スクリプトを実行して、SDSoC Vivado Tcl API を読み込んで手順を実行し、ハードウェア・プラットフォームのメタデータファイルを作っていこう。
SDSoC のプラットフォームのお勉強5(ハードウェア・プラットフォームのメタデータファイルを作る2)
前回は、Tcl スクリプトを実行して、SDSoC Vivado Tcl API を読み込んで手順を実行し、ハードウェア・プラットフォームのメタデータファイルを作っていく過程の途中でクロックポートを宣言したところで終了した。今回は、最後の ZYBO_0_163_6.hpfm を生成する所まで行ってみよう。
SDSoC のプラットフォームのお勉強6(ハードウェア・プラットフォームの完成)
前回、ハードウェア・プラットフォームのメタデータファイルを作ることができた。今回は、ハー ドウェア・プラットフォームを完成させた。

SDx 2016.3 のプラグマによるハードウェアと性能の違い1
おなじみのSDx 用ラプラシアンフィルタのプロジェクトを使用して、SDx 2016.3 のデータに関するプラグマを入れて、ハードウェアがどう変更されたのか?性能がどうなったのかを検証してみよう。
SDx 2016.3 のプラグマによるハードウェアと性能の違い2
前回は、ラプラシアンフィルタを使用して、デフォルトの場合とSDS data zero_copy プラグマを入れた状態でどのようにVivado のブロックデザインが異なるかとその性能を調べた。今回は、SDS data access_pattern にSEQUENTIAL を指定したときのVivado のブロックデザインとその性能を調べた。
SDx 2016.3 のプラグマによるハードウェアと性能の違い3
前回は、SDS data access_pattern にSEQUENTIAL を指定したときのVivado のブロックデザインとその性能を調べた。今回は、SDS data access_pattern にRANDOM を指定したときと、以前 SDS data zero_copy を指定したら sds_alloc() を使用する必要があるとのことなので、やってみた。
SDx 2016.3 のプラグマによるハードウェアと性能の違い4
前回は、SDS data access_pattern にRANDOM を指定したときと、以前 SDS data zero_copy を指定したら sds_alloc() を使用する必要があるとのことなので、やってみた。今回は、ハードウェア化する関数 lap_filter_axim() の書き方をVivado HLS でやったように memcpy() で書き換えてどのくらいハードウェアが速くなるのかやってみた。

Vivado HLS のソースコードをSDx で試す1(memcpy() を使った第2段階のコード)
これまでの4つのSDSoCの記事と過去の記事はlap_filter2.c のline_buf と lap_buf の2つのバッファの大きさを間違えていた。それで、Block RAM が大きくなりすぎて、Block RAM の容量をオーバーしていたことが分かった。
それを修正しすると、800 x 600 ピクセルにしても問題なくビルドすることができた。
わずかの修正でVivado HLS のプロジェクトファイルがSDSoC で完成品になって動くということが分かった。衝撃的な事実だ。
Vivado HLS のソースコードをSDx で試す2(memcpy() を使った第3段階のコード)
前回はViavdo HLS のソースコードをわずかに変更しただけのAXI4 Master のラプラシアンフィルタをSDSoC でビルドすることができた。今回は前回のよりも性能が良いmemcpy() を使った第3段階のコードをSDSoC でビルドしてみよう。
Vivado HLS のソースコードをSDx で試す3(AXI4-Stream向きのコード)
次は、Vivado HLS で試したAXI4-Stream のソースコードを試してみようと思った。そこで、”hls::stream + axiu + SDSoC の実験”を参考にさせて頂いて、
#ifdef __SDSVHLS__
を定義したりして、いろいろと奮闘したのだが、力及ばずに、うまく行かなかった。
そこで考え直してみると、画像のピクセルがその順番でシーケンシャルで処理することができれば、
#pragma SDS data access_pattern(cam_fb:SEQUENTIAL, lap_fb:SEQUENTIAL)
を指定すれば、AXI4-Stream になるはずでは?ということで、cam_fb と lap_fb を配列にして、画像のピクセルが順番通りに処理できるように書いてみた。
Vivado HLS のソースコードをSDx で試す4(AXI4-Stream向きのコード)
前回は、Vivado HLS で使用していたAXI4-Stream のソースコードをSDSoC 用のサイドチャネル付きAXI4-Stream に対応するソースコードにうまく変換できなかったため、配列渡しとして書き換えた上でAXI4-Stream として実装するプラグマを与えたら、理論上の限界値に近い実行性能が出た。今回は、同じソースコードで、SDSoCのプラグマを変更して実行性能を見ていこう。最初に SDS data zero_copy を与えてみた。

SDSoCのチュートリアル をやってみた1(システムのデバック)
SDSoCのデバック方法やパフォーマンス測定のただし方法などを知らなかったので、 SDSoCのチュートリアルをやってみることにした。
最初にシステムのデバック方法をやってみた。
SDSoCのチュートリアル をやってみた2(システム パフォーマンスの見積もり)
前回は、ソフトウェアとハードウェア両方を含んだスタンドアロンのシステムをSDSoCのデ バックモードでデバックすることができた。今回は、”SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”の54 ページの”チュートリアル : システム パフォーマンスの見積もり”をやってみよう。
SDSoCのチュートリアル をやってみた3(タスクのパイプライン処理最適化)
”SDSoC Environment Tutorial: Introduction UG1028 (v2016.3) November 30, 2016”の33ページ”Chapter 5 Accelerator Optimization”をやってみよう。
SDSoCのチュートリアル をやってみた4(ハードウェア/ソフトウェア イベントのトレース)
”SDSoC 環境ユーザー ガイド SDSoC 環境の概要 UG1028 (v2016.2) 2016 年 7 月 13 日”の66ページの”第7章  チュートリアル : ハードウェア/ソフトウェアイベントのトレース”をやってみよう。

SDx 2016.3 のプラグマによるハードウェアと性能の違い5
SDSoC 勉強会で SDSoC勉強会_170128_スライド「SDx 2016.3のプラグマによるハードウェアと性能」の18ページの性能比較表で「プラグマ無し」と「SEQUENTIAL」のハードウェア実行時間がばらつくのは、メモリ 領域を malloc() で取っているからではないか?という指摘を頂いた。malloc() でとるとページ(4kバイト)ごとに不連続なメモリを使用している可能性がある。ページごとに、スワップアウトしているかどうか?を確かめてスワップアウトされていたらス ワップインする必要がある。つまり、ページごとに余計な処理をする必要がある。それで、遅くもなっているし、時間の変動も起こるのではないか?という指摘だっ た。
それならば、sds_alloc() でCMA 領域に連続メモリ領域を確保すれば大丈夫なはずだ。なお、ソフトウェアはMMU を通っているので、MMUで論理アドレスー物理アドレス変換が自動的に行われるので、CPUから論理アドレスに書けばページが違っていても問題ない。(論点が微妙に違うの はご容赦ください)

@ikwzmさんの”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”をやってみる1
@ikwzmさんの作ってくれた”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”をやってみることにした。
SDSoC は、プロジェクトをビルドしてSD カードに書いて、基板を起動しても RAM イメージのLinux が立ち上がってアプリケーションソフトを起動して機能を実現する方式だ。しかしそれに不満があった。SDSoC は、Root File System も指定できるようだが、それでも SDSoC 用に1つMicro SD カードを用意することには代わり無い。
私の希望は、今まで使っている育て上げてきたLinux 上で SDSoC から出力された実行ファイルが実行できるということだ。それを @ikwzmさんが”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”で実現してくれたので、使ってみない手は無い。。。
しかも、FPGA+SoC+Linux+Device Tree Overlay+FPGA Region を使用すれば、Linux をリブートすること無しに、FPGA のコンフィギュレーション、デバイス・ツリーのロード、PS のクロック設定ができてしまう。つまり、Linux のリブート無しに SDSoC の実行ファイルを実行できるのだ。これは使わない手は無い。。。 @ikwzm さん、ありがとうございました。
ZYBO-Z7-20を使用する。
@ikwzmさん の”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”をやってみる2
前回は、Xilinx APF Accelerator driver のインストールを行った。今回は、Xilinx APF Accelerator driver を使用してSDSoC で作成した実行ファイルを実行してみよう。
@ikwzmさん の”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”をやってみる3
前回は、Xilinx APF Accelerator driver を使用してSDSoC で作成した実行ファイルを実行することができた。今回は、前回の実行ファイルを実行した後で、一旦ドライバを取り外して異なるマスタの回路をロードして、マス タ用の実行ファイルを実行してみよう。
@ikwzmさん の”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”をやってみる4
前回は、実行ファイルを実行した後で、一旦ドライバを取り外して異なるマスタの回路をロードし て、マスタ用の実行ファイルを実行することができた。今回は、”ZYBO-Z7-20のDebianにOpenCV 3.1.0をインストール”で ZYBO-Z7-20 の Debian に OpenCV 3.1.0 をインストールすることができたので、”reVISION-Zybo-Z7-20をやってみた6(Zybo-Z7-20 で確認)”でやったバイラテラル・フィルタや、”reVISION-Zybo-Z7-20をやってみた8(Dense Non-Pyramidal Optical Flow)”でやった Dense Non-Pyramidal Optical Flow を @ikwzm さんの”FPGA+SoC+Linux+Device Tree Overlay+FPGA Region(SDSoC対応編)”でやってみることにする。

SDSoC 2018.3 WebPACK が無くなってしまいました
2018年12月13日の時点では公開されていたSDSoC 2018.3 WebPACK ですが、昨日、Xilinx 社のSDSoC のダウンロードページを見ると、SDSoC 2018.3 WebPACK が無くなっていました。

SDx のUltra96-V2 用プラットフォームを作る1(PetaLinux 2018.3 のインストール、Vivado プロジェクト作成)
以下の参考資料があるので、それに従ってSDx 2018.3 でUltra96-V2 用のプラットフォームを作成することにした。
SDx のUltra96-V2 用プラットフォームを作る2(ブロックデザインの作成)
前回は、SDx 2018.3 でUltra96-V2 用のプラットフォームを作成することにしたということで、PetaLinux 2018.3 をインストールし、Vivado プロジェクト作成を行った。今回は、ハードウェア・プラットフォーム用のブロックデザインを作成する。
SDx のUltra96-V2 用プラットフォームを作る2(Platform Hardware Interfacesの宣言)
前回は、ハードウェア・プラットフォーム用のブロックデザインを作成した。今回は、 Platform Hardware Interfacesとして宣言するために、Vivado で Platform Interfaces を設定する。
SDx のUltra96-V2 用プラットフォームを作る3(ビットストリームの生成)
前回は、Platform Hardware Interfacesとして宣言するために、Vivado で Platform Interfaces を設定した。今回は、HDL Wrapperを生成して、論理合成、インプリメンテーション、ビットストリームの生成を行う。
SDx のUltra96-V2 用プラットフォームを作る4(DSA ファイルの生成)
前回は、HDL Wrapperを生成して、論理合成、インプリメンテーション、ビットストリームの生成を行った。今回は、DSA ファイルを生成する。これは、SDx でプラットフォームを作成する時に使用される。
SDx のUltra96-V2 用プラットフォームを作る5(PetaLinuxプロジェクト1)
前回、SDx でプラットフォームを作成する時に使用されるDSA ファイルを生成した。今回は、PetaLinuxのプロジェクトを作成しよう。
SDx のUltra96-V2 用プラットフォームを作る6(PetaLinuxプロジェクト2)
前回は、PetaLinux 2018.3 のプロジェクトを作成し、petalinux-config を行ったが、Python が 3系だったので、エラーになってしまった。その対策として、”pythonのバージョンを切り替える(anaconda使用の場合)”で Python を 2系に切り替えた。今回は、再度、petalinux-config を行っていく。
SDx のUltra96-V2 用プラットフォームを作る7(PetaLinuxプロジェクト3)
前回は、PetaLinux 2018.3 のプロジェクトの petalinux-config を行った。今回は、petalinux-build を行って、elf ファイルやLinux イメージを生成し、それらをSDx で利用しやすいように環境を整える。
SDx のUltra96-V2 用プラットフォームを作る8(PetaLinuxプロジェクト4)
前回は、petalinux-build を行って、elf ファイルやLinux イメージを生成し、それらをSDx で利用しやすいように環境を整えた。今回は、PetaLinux 2018.3 からスタテック・リンクされていたライブラリ(libsds_lib.so)がダイナミック・リンクに変更になっているので、その処理を行う。
SDx のUltra96-V2 用プラットフォームを作る8(SDxでプラットフォーム・プロジェクトを生成)
前回は、PetaLinux 2018.3 からスタテック・リンクされていたライブラリ(libsds_lib.so)がダイナミック・リンクに変更になっているので、その処理を行った。今回は、 PetaLinux での作業は終了したので、SDx を立ち上げてプラットフォーム・プロジェクトを生成し、ビルドしていこう。
SDx のUltra96-V2 用プラットフォームを作る9(SDxでアプリケーション・プロジェクトを生成)
前回は、SDx を立ち上げてプラットフォーム・プロジェクトを生成し、ビルドした。今回は、Example のArray Partitioning ベアメタル・アプリケーション・プロジェクトを作成しビルドした。
SDx のUltra96-V2 用プラットフォームを作る10(実機確認、Vivado HLS とVivado プロジェクト)
前回は、サンプルのアプリケーション・プロジェクトを作成しビルドできた。今回は、実機確認を すると共に、Vivado HLS とVivado のプロジェクトを見ていこう。実機確認は問題なく動作した。
SDx のUltra96-V2 用プラットフォームを作る11(LinuxのSDx アプリケーション・プロジェクトを作成)
前回は、実機確認をすると共に、Vivado HLS とVivado のプロジェクトを見た。今回は、Linux のSDx アプリケーション・プロジェクトを作成してみよう。しかし、Root FS が起動しなかった。
SDx のUltra96-V2 用プラットフォームを作る12(トラブルシューティング)
前回は、Linux のSDx アプリケーション・プロジェクトを作成したが、Root FS が起動しなかった。今回は、その原因を探っていこう。
いろいろと検索したのだが、どうもMicro SD カードのインターフェースのWrite Protection の問題だった。
SDx のUltra96-V2 用プラットフォームを作る13(Linuxでは失敗した)
前回は、Linux のSDx アプリケーション・プロジェクトを作成したが、Root FS が起動しなかった原因を究明し、動作するようになった。今回は、LinuxConfig で作成したSDx アプリケーション・プロジェクトの実行ファイルを動作させたい。結論から言うとSDx アプリケーション・プロジェクトの実行ファイルの動作に失敗した。

SDx 2019.1 のUltra96-V2 用プラットフォームを作る1(DSA ファイルを作成)
”SDx のUltra96-V2 用プラットフォームを作る13(Linuxでは失敗した)”で SDx 2018.3 で Linux 用のプラットフォームを使用して、アプリケーション・プロジェクトを作成し、PetaLinux 上で実行させたところ途中で止まってしまって、実行することができなかった。使用したPetaLinux 2018.3 は私が使用しているUbuntu 18.04 に未対応ということも合って規格外の使用ということになってしまった。よって、Ubuntu 18.04 に対応しているPetaLinux 2019.1 で試してみたいと思う。
SDx 2019.1 のUltra96-V2 用プラットフォームを作る2(PetaLinux1)
前回は、Vivado 2018.3 で作ってあったSDx のハードウェア・プラットフォームをVivado 2019.1 に変換し、DSA ファイルを生成した。今回は、PetaLinux をコンフィギュレーションして、ビルドしていこう。
SDx 2019.1 のUltra96-V2 用プラットフォームを作る3(PetaLinux2)
前回は、PetaLinux のプロジェクトを生成して、petalinux-config を行った。今回は、カーネルの petalinux-config とRoot File System の petalinux-config を行って、プロジェクトをビルドしていこう。
SDx 2019.1 のUltra96-V2 用プラットフォームを作る4(PetaLinux3)
前回は、カーネルの petalinux-config とRoot File System の petalinux-config を行って、プロジェクトをビルドした。今回は、boot, image ディレクトリを作り、boot.bif を作成し、mylib と mylib2 を作成する。
SDx 2019.1 のUltra96-V2 用プラットフォームを作る5(SDx 1)
前回は、boot, image ディレクトリを作り、boot.bif を作成し、mylib と mylib2 を作成した。今回は、SDx を立ち上げてプラットフォーム・プロジェクトを生成し、ビルドする。
SDx 2019.1 のUltra96-V2 用プラットフォームを作る6(SDx 2)
前回は、SDx を立ち上げてプラットフォーム・プロジェクトを生成し、ビルドして成功した。今回は、生成されたsd_card ディレクトリにファイルをMicroSD カードに書いて動作をチェックする。
やはり、ベアメタル・アプリケーションは動作するが、Linux アプリケーションは動作しない。



inserted by FC2 system