akio_tsuchiya
2020年2月19日 10時51分
＜ご質問１＞
Armadillo-840の「NORフラッシュメモリ書き換え処理に関する仕様変更のお知らせ (2018年4月/Armadillo-800シリーズ対象)」
に対応する為、弊社でもシステムエンハンスに対応する事となりました。
https://armadillo.atmark-techno.com/news/announce/20180409
今回は、プラットフォームレベルでのエンハンス対応が要求されます。
そこで、問題となるのが、以下のデバイスに対する初期化です。
/sys/class/graphics/fb0/blank ＜＝ 標準のHDMIの表示領域の初期化
/sys/class/graphics/fb1/blank ＜＝ 標準のLCDの表示領域の初期化
/sys/class/graphics/fb2/blank ＜＝ 標準のUSBコンソールの表示領域の初期化
Armadillo-840の標準出力として「/sys/class/graphics/fb0」は、デバイスがマウントされている為、利用可能です。
しかし、個別に、
「/sys/class/graphics/fb1」
及び
「/sys/class/graphics/fb2」
に対して、直接グラフィックデータを書き込む手法はあると考えています。
これは、OSの標準ディスプレイドライバ経由ではなく、直接ハードウェアにグラフィックデータを書き込む手段として
稀に利用されれる手法と理解していますが、必ずしも、一般的な手法では無い事は承知いたしております。
恐らく、「fb1」と「fb2」のデバイスを、どこかにマウントすれば、この手法が利用可能と思われるのですが、
一般的には、何処と、どの様な記述でマウントすればよいのかご教示いただけないでしょうか？
＜ご質問２＞
もし、このような方法で、直接グラフィックデバイスにデータを書き込む場合のArmadillo-840内部の処理に対して、アドバイスを戴けないでしょうか？
（１）CPUはOSからの多くの要求に対して、対応するタスクをスケジューリングして、処理スレッドを準備している。
（２）一般的なグラフィック処理では、OSのドライバを介してグラフィック描画を行う為、タスクスケジューリングは、OSが把握可能。
（３）これに対し、直接グラフィックデバイスに対してデータを書き込んだ場合、OSのタスクスケジュールは、タスクの重さを把握できるのでしょうか？
（４）もしOSが感知できない場合、直接、CPUの処理スレッドが生成されると思うのですが、その際のスレッド処理優先度は、スレッドの重さを把握できるのでしょうか？
＝＞現在のマルチスレッド処理では、重たいスレッドを優先的にスケジューリングし、空きスレッドにガベージコレクトや軽いスレッドをディスパッチする仕組みと理解しています。
（５）上記の内容で、（４）のスレッド判定ができないまま、比較的重たいスレッドが複数ディスパッチされると、ハードウェアアクセラレーションの一つとして、SGX処理が呼び出されるものと理解しています。
上記の結果、処理しきれない場合、SGXエラーが発生するとすると、対処の方法は無透かしいのでしょうか？
或は、何かの方法で、解決す手段はあるのでしょうか？
ご回答の程、何卒、宜しくお願い申し上げます。
コメント
akio_tsuchiya
溝淵様
明確なご回答、誠にありがとうございます。
しかし、今回は、既存のソフトウェアが、このような造りとなっています。
/etc/config/rc.local に、次の記述があります。
＜前略＞
echo 0 > /sys/class/graphics/fb1/blank
echo 0 > /sys/class/graphics/fb2/blank
＜後略＞
その為、起動ログでは、
＜前略＞
Running local start script (/etc/config/rc.local).
/etc/config/rc.local: line 21: can't create /sys/class/graphics/fb1/blank: nonexistent directory
/etc/config/rc.local: line 22: can't create /sys/class/graphics/fb2/blank: nonexistent directory
＜後略＞
とエラーになります。
これは、既存のユーザーアプリを開発した方に聞くしか手が無いという事でしょうか？
それとも、何か、一般的な手掛かりはあるでしょうか？
誠に恐縮ですが、ご回答をお願い申し上げます。
CPUスレッドは、マルチスレッド処理のプログラミング講座で概要をお聞きした程度ですが、
まだまだ、私の知識が足りず、上手くお伝えできていませんでした。
にもかかわらず、ご回答をいただき、誠に恐縮です。
これは、上げ足を取るつもりは全くありません。
アドバイスとして、ご回答をいただければ幸いです。
> SGX540ライブラリ経由でアクセスした場合は、SGX処理が呼び出されます。
となると、今回はQtをフレームワークで利用し、ユーザーアプリ側からはSGXモジュールを指定している訳ではありません。
この場合、SGXの行列演算なのか、CPUの処理なのかは、Qtがディスパッチしていると考えてよいのかと推測します。
現時点では、Qt5.4.2を使い続けているのですが、この部分も刷新した方が良いと考えるべきでしょうか？
アドバイスとして、ご回答いただければ幸いです。
> 溝渕です。
>
> > ＜ご質問１＞
> :(省略)
> > 恐らく、「fb1」と「fb2」のデバイスを、どこかにマウントすれば、この手法が利用可能と思われるのですが、
> > 一般的には、何処と、どの様な記述でマウントすればよいのかご教示いただけないでしょうか？
>
> RGB等の生画像を直接描画させる方法についてのご質問という認識で良いでしょうか。
>
> フレームバッファデバイスは、/dev/以下にあります(/sys/以下ではないです)。
> /dev/fb1に画像を書き込んでみてください。
>
> 例として、ランダムデータをフレームバッファに書き込むコマンドを示します。
> 画面には砂嵐のような画像が表示されると思います。
>
>
> [armadillo]# cat /dev/urandom > /dev/fb1 >
>
>
> > ＜ご質問２＞
> > もし、このような方法で、直接グラフィックデバイスにデータを書き込む場合のArmadillo-840内部の処理に対して、アドバイスを戴けないでしょうか？
> >
> > （１）CPUはOSからの多くの要求に対して、対応するタスクをスケジューリングして、処理スレッドを準備している。
> > （２）一般的なグラフィック処理では、OSのドライバを介してグラフィック描画を行う為、タスクスケジューリングは、OSが把握可能。
> > （３）これに対し、直接グラフィックデバイスに対してデータを書き込んだ場合、OSのタスクスケジュールは、タスクの重さを把握できるのでしょうか？
>
> タスクの「重さ」とはとは何を指していますか。処理完了までの時間であれば、恐らく推計することは困難かと思います。
>
> > （４）もしOSが感知できない場合、直接、CPUの処理スレッドが生成されると思うのですが、その際のスレッド処理優先度は、スレッドの重さを把握できるのでしょうか？
> > ＝＞現在のマルチスレッド処理では、重たいスレッドを優先的にスケジューリングし、空きスレッドにガベージコレクトや軽いスレッドをディスパッチする仕組みと理解しています。
>
> Linuxは優先度をnice値で指定可能です。「重さ」については、申し訳ございませんが意図が読み取れません。
>
> > （５）上記の内容で、（４）のスレッド判定ができないまま、比較的重たいスレッドが複数ディスパッチされると、ハードウェアアクセラレーションの一つとして、SGX処理が呼び出されるものと理解しています。
>
> SGX540ライブラリ経由でアクセスした場合は、SGX処理が呼び出されます。
> Linuxカーネルがダイナミックに利用するハードウェア(CPU or SGX)を決定す
> る機構については存じ上げません。
>
> > 上記の結果、処理しきれない場合、SGXエラーが発生するとすると、対処の方法は無透かしいのでしょうか？
>
> エラー発生時は、ソフトウェア(SGXドライバ)でエラー通知を実装している場合はユーザーランドに通知されます。
>
at_mizo
溝渕です。
> /etc/config/rc.local に、次の記述があります。
>
> ＜前略＞
> echo 0 > /sys/class/graphics/fb1/blank
> echo 0 > /sys/class/graphics/fb2/blank
> ＜後略＞
>
> その為、起動ログでは、
>
> ＜前略＞
> Running local start script (/etc/config/rc.local).
> /etc/config/rc.local: line 21: can't create /sys/class/graphics/fb1/blank: nonexistent directory
> /etc/config/rc.local: line 22: can't create /sys/class/graphics/fb2/blank: nonexistent directory
> ＜後略＞
>
> とエラーになります。
>
> これは、既存のユーザーアプリを開発した方に聞くしか手が無いという事でしょうか？
これは恐らく、fb1とfb2が無い為に出力されているエラーです。rc.localで各
フレームバッファのblankを解除する目的で処理を追加されたのだと思います。
ボードドライバ("arch/arm/mach-shmobile/board-armadillo840.c")から各fbのplatform_deviceを削除していませんか?
> > SGX540ライブラリ経由でアクセスした場合は、SGX処理が呼び出されます。
>
> となると、今回はQtをフレームワークで利用し、ユーザーアプリ側からはSGXモジュールを指定している訳ではありません。
>
> この場合、SGXの行列演算なのか、CPUの処理なのかは、Qtがディスパッチしていると考えてよいのかと推測します。
QtのQPA(Qt Platform Abstraction)次第です。Armadillo-840の標準では、QPA
にeglfsが利用されるためにGPU(PowerVR SGX540)が動作します。
> 現時点では、Qt5.4.2を使い続けているのですが、この部分も刷新した方が良いと考えるべきでしょうか？
お使いの環境のQPAをご確認ください。
Qtアプリケーション実行時に、環境変数"QT_QPA_PLATFORM"を指定することで、
QPAを明示することもできたように記憶しています。
# Qt5.4迄のアップデート内容を把握していない為、もしかすると非対応になっているかもしれません
akio_tsuchiya
溝淵様
溝淵様の凄いスピードでのクイックレスポンス、感服いたします。
・board-armadillo840.c改造の件
このモジュールは、以下の２か所に存在します。
～/linux-3.4-at27/arch/arm/mach-shmobile/ 約7kb
～/hermit-at-3.11.0/src/target/platform/ 約71kb
この2つには、別段改造や着手はしていません。
Grepしても、このフォルダ以外に「board-armadillo840.c」はありません。
このユーザーアプリでは、LED点灯やスイッチ等の入力を目的にボードのI/Oドライバを
個別に開発し適用しています。
過去にこのユーザーアプリを開発した方は、
「f0とf1とf2のデバイスが持つバッファを独自に割り付けて使っている事を断片的にお聞きいたしました。」
この点は、元の開発者の方にお聞きするしか手が無いと判断すべきでしょうか？
或は、私が何か環境構築で、実施を行っていない部分があるのでしょうか？
この様なご質問を行い、誠に恐縮ですが、もう一度、アドバイスをください。
・Qtの件
調査してみますが、明示的にSGXを呼び出したいわけではありません。
しかし、必ずSGXコールを行うことで、処理が上手く回るようになるのであれば検討いたします。
既存のユーザアプリでは、f0とf1とf2をレイヤの様に使い分け１画面に同時描画しています。
この様な場合、一つのArmadilllo-840内で、同時に３つ（f0とf1とf2）のデバイスからSGXモジュールをコールした場合、
競合は発生しないのでしょうか？
こちらもアドバイスいただければ幸いです。
何卒、宜しくお願い申し上げます。
> 溝渕です。
>
> > /etc/config/rc.local に、次の記述があります。
> >
> > ＜前略＞
> > echo 0 > /sys/class/graphics/fb1/blank
> > echo 0 > /sys/class/graphics/fb2/blank
> > ＜後略＞
> >
> > その為、起動ログでは、
> >
> > ＜前略＞
> > Running local start script (/etc/config/rc.local).
> > /etc/config/rc.local: line 21: can't create /sys/class/graphics/fb1/blank: nonexistent directory
> > /etc/config/rc.local: line 22: can't create /sys/class/graphics/fb2/blank: nonexistent directory
> > ＜後略＞
> >
> > とエラーになります。
> >
> > これは、既存のユーザーアプリを開発した方に聞くしか手が無いという事でしょうか？
>
> これは恐らく、fb1とfb2が無い為に出力されているエラーです。rc.localで各
> フレームバッファのblankを解除する目的で処理を追加されたのだと思います。
>
> ボードドライバ("arch/arm/mach-shmobile/board-armadillo840.c")から各fbのplatform_deviceを削除していませんか?
>
>
> > > SGX540ライブラリ経由でアクセスした場合は、SGX処理が呼び出されます。
> >
> > となると、今回はQtをフレームワークで利用し、ユーザーアプリ側からはSGXモジュールを指定している訳ではありません。
> >
> > この場合、SGXの行列演算なのか、CPUの処理なのかは、Qtがディスパッチしていると考えてよいのかと推測します。
>
> QtのQPA(Qt Platform Abstraction)次第です。Armadillo-840の標準では、QPA
> にeglfsが利用されるためにGPU(PowerVR SGX540)が動作します。
>
>
> > 現時点では、Qt5.4.2を使い続けているのですが、この部分も刷新した方が良いと考えるべきでしょうか？
>
> お使いの環境のQPAをご確認ください。
>
> Qtアプリケーション実行時に、環境変数"QT_QPA_PLATFORM"を指定することで、
> QPAを明示することもできたように記憶しています。
> # Qt5.4迄のアップデート内容を把握していない為、もしかすると非対応になっているかもしれません
>
at_mizo
溝渕です。
> ～/linux-3.4-at27/arch/arm/mach-shmobile/ 約7kb
> ～/hermit-at-3.11.0/src/target/platform/ 約71kb
>
> この2つには、別段改造や着手はしていません。
今回の場合は、Linuxカーネルの内容ですので前者が該当します。このファイ
ル自体に変更を行っていない場合、カーネルコンフィギュレーションに変更を
加えてはいないでしょうか。
> 過去にこのユーザーアプリを開発した方は、
> 「f0とf1とf2のデバイスが持つバッファを独自に割り付けて使っている事を断片的にお聞きいたしました。」
> この点は、元の開発者の方にお聞きするしか手が無いと判断すべきでしょうか？
何を行ったかを具体的に教えていただけると、アドバイスできる可能性はあり
ます。上記内容だけですと私からアドバイスできることはありません。
私の理解力にも至らない点はあるかと思います。申し訳ございません。
> この様な場合、一つのArmadilllo-840内で、同時に３つ（f0とf1とf2）のデバイスからSGXモジュールをコールした場合、
> 競合は発生しないのでしょうか？
よっぽど作りの悪いドライバでなければ、競合しないよう作られていると思い
ます。何か問題が発生しましたか。
akio_tsuchiya
> 今回の場合は、Linuxカーネルの内容ですので前者が該当します。このファイ
> ル自体に変更を行っていない場合、カーネルコンフィギュレーションに変更を
> 加えてはいないでしょうか。
前任者から受け取った環境構築手順に、そのような記述は無いのですが、
恐らく実施されている可能性は高いと思われます。
> 何を行ったかを具体的に教えていただけると、アドバイスできる可能性はあり
> ます。上記内容だけですと私からアドバイスできることはありません。
この部分は、現在、問合せ中です。
> よっぽど作りの悪いドライバでなければ、競合しないよう作られていると思い
> ます。何か問題が発生しましたか。
以前にも問合せした内容と重複しますが、SGXエラーが発生しています。
御社より、個別対応もいただいています。
ついでではありますが、今回の起動ログの最終段階で、
アプリケーションがディスプレイにデータ展開できず、
終了しています。
＜前略＞
auto-run-app.sh: 1.1.0
Starting PVR Server: failed
/etc/config/settei found. ＜＝これは、ユーザアプリで利用する、個別のフォルダです。
atmark-dist v1.55.1 (AtmarkTechno/Armadillo-840)
Linux 3.4-at27 [armv7l arch]
armadillo840-0 login: Could not open egl display
ここから、私共の何か至らぬ点が分かれば幸いです。
アドバイスをいただければ幸いです。
> 溝渕です。
>
> > ～/linux-3.4-at27/arch/arm/mach-shmobile/ 約7kb
> > ～/hermit-at-3.11.0/src/target/platform/ 約71kb
> >
> > この2つには、別段改造や着手はしていません。
>
> 今回の場合は、Linuxカーネルの内容ですので前者が該当します。このファイ
> ル自体に変更を行っていない場合、カーネルコンフィギュレーションに変更を
> 加えてはいないでしょうか。
>
>
> > 過去にこのユーザーアプリを開発した方は、
> > 「f0とf1とf2のデバイスが持つバッファを独自に割り付けて使っている事を断片的にお聞きいたしました。」
> > この点は、元の開発者の方にお聞きするしか手が無いと判断すべきでしょうか？
>
> 何を行ったかを具体的に教えていただけると、アドバイスできる可能性はあり
> ます。上記内容だけですと私からアドバイスできることはありません。
>
> 私の理解力にも至らない点はあるかと思います。申し訳ございません。
>
>
> > この様な場合、一つのArmadilllo-840内で、同時に３つ（f0とf1とf2）のデバイスからSGXモジュールをコールした場合、
> > 競合は発生しないのでしょうか？
>
> よっぽど作りの悪いドライバでなければ、競合しないよう作られていると思い
> ます。何か問題が発生しましたか。
>
at_mizo
溝渕です。
> ついでではありますが、今回の起動ログの最終段階で、
> アプリケーションがディスプレイにデータ展開できず、
> 終了しています。
>
> ＜前略＞
> auto-run-app.sh: 1.1.0
> Starting PVR Server: failed
> /etc/config/settei found. ＜＝これは、ユーザアプリで利用する、個別のフォルダです。
>
> atmark-dist v1.55.1 (AtmarkTechno/Armadillo-840)
> Linux 3.4-at27 [armv7l arch]
>
> armadillo840-0 login: Could not open egl display
>
> ここから、私共の何か至らぬ点が分かれば幸いです。
>
>
> アドバイスをいただければ幸いです。
アプリケーションや環境等を把握していない為、ログメッセージのみからアド
バイスをするのは困難です。
何を行っているか(実行しているコマンドや独自アプリの実装、環境等)を教え
ていただけるとアドバイスできるかもしれません。
akio_tsuchiya
溝淵様
ご多忙の中、早速のご回答、誠に痛み入ります。
現在、僅かな手掛かりしかないのが事実ですが、
前任者（別会社）の方に、/sys/f1、/sys/f2の件で問い合わせ中です。
今できそうなことは、こちらが、前任者から受け取った環境構築メモを元に、
新環境の構築手順を、箇条書き程度でまとめてみます。
少しお時間をいただきます。
明日には、ここに記載できるようにいたします。
もし、その中に、おかしな点があればご教示ください。
何卒、宜しくお願い申し上げます。
> 溝渕です。
>
> > ついでではありますが、今回の起動ログの最終段階で、
> > アプリケーションがディスプレイにデータ展開できず、
> > 終了しています。
> >
> > ＜前略＞
> > auto-run-app.sh: 1.1.0
> > Starting PVR Server: failed
> > /etc/config/settei found. ＜＝これは、ユーザアプリで利用する、個別のフォルダです。
> >
> > atmark-dist v1.55.1 (AtmarkTechno/Armadillo-840)
> > Linux 3.4-at27 [armv7l arch]
> >
> > armadillo840-0 login: Could not open egl display
> >
> > ここから、私共の何か至らぬ点が分かれば幸いです。
> >
> >
> > アドバイスをいただければ幸いです。
>
> アプリケーションや環境等を把握していない為、ログメッセージのみからアド
> バイスをするのは困難です。
>
> 何を行っているか(実行しているコマンドや独自アプリの実装、環境等)を教え
> ていただけるとアドバイスできるかもしれません。
>
akio_tsuchiya
溝淵様
ざっくりですが、弊社で行っている環境構築手順を記述いたします。
以下の～ココカラ～ ・・・ ～ココマデ～ をご参照ください。
１．手順に過不足があれば、ご指摘ください。
２．以下の手順合いで f0、f1、f2 のデバイスドライバに関わる部分があればご教示ください。
３．何かご提示させていただければ、より詳しいことが分かるソースやスクリプトなどの資源があればご指定下さい。
何卒、宜しくお願い申し上げます。
～ココカラ～
事前に、QtCreatorにてユーザーアプリをコンパイルしておく。 ＜＝［userapps］
Workフォルダを作成
Workフォルダ内で、以下の資源を展開
tar xfvz hermit-at-3.11.0-source.tar.gz
tar xfvz atmark-dist-20191226.tar.gz
tar xfvz linux-3.4-at27.tar.gz
展開したatmark-dist-20191226フォルダ内入る
linux-3.xのシンボリックリンクを作成する。
make menuconfigを実行し、画面から対象のハードウェアを設定する。
・Vendor (AtmarkTechno)
・AtmarkTechno Products (Armadillo-840)
内容を保存でメニュー画面から抜ける。
makeを実行し、カーネル及びユーザーランドを作成する。
QtのバージョンをQt5.4.2とする為、既存のQtライブラリを削除する。
rm -rf romfs/lib/libQt5*
rm -rf romfs/lib/qt5/*
Qt5.4.2のライブラリを展開する。
tar zxvf qt5.4.2-romfs.tar.gz
#動画再生ソフト Gstreamer のライブラリを更新(動画停止時に画面に残像を残す対応)
cp libgstacmfbdevsink.so romfs/usr/lib/gstreamer-1.0/
atmark-dist-20191226フォルダを出る
Workフォルダに戻る
toolフォルダに入る
独自ドライバの作成を行う（あまり関係ないかもしれませんが作成ドライバは以下の３つ）
ADC101S051（アナログデバイス用ドライバ）の作成
LED点灯制御ドライバの作成
赤外線リモコンドライバの作成
tool/qtフォルダに入る
tool/qtフォルダに事前にコンパイルした［userapps］をコピーする。
version.ini ファイルの整合性確認ファイルを作成する
./qt-copy を実行する
./makeImage を実行する
tool/qtフォルダを出る
toolフォルダを出る
Workフォルダに戻る
ブートローダの作成
展開した hermit-at-3.11.0 フォルダに入る
hermit の作成
make armadillo840_nor_defconfig と make を行う
src/target/armadillo8x0/loader-armadillo840-nor-v3.11.0.bin を /var/www/ にコピーする
hermit-at-3.11.0 フォルダを出る
Workフォルダに戻る
squashfs-a800-firmware-v3.02.img を /var/www/ にコピーする
作成した以下のファイルを、Armadillo-804の/mnt/root/resourcesフォルダ配下にコピーする。
ブートローダー loader-armadillo840-nor-v3.11.0.bin
Linuxカーネル linux.bin.gz
ユーザーランド romfs.img.gz
動画ミドルウェア squashfs-a800-firmware-v3.02.img
以下の内容を、Armadillo-804の/mnt/root/resourcesフォルダ配下で実行する。
killall ［ユーザーアプリ］
cd ..
netflash -k -n -u -b -s -r /dev/flash/userland /root/resources/romfs.img.gz
echo 0 > /sys/class/mtd/mtd0/ro
netflash -k -n -u -b -r /dev/flash/bootloader /root/resources/loader-armadillo840-nor-v3.11.0.bin
echo 0 > /sys/class/mtd/mtd3/ro
netflash -k -n -u -b -r /dev/flash/firmware /root/resources/squashfs-a800-firmware-v3.02.img
netflash -k -n -u -b -s -r /dev/flash/kernel /root/resources/linux.bin.gz
最後にArmadillo-804を再起動する。
～ココマデ～
> 溝淵様
>
> ご多忙の中、早速のご回答、誠に痛み入ります。
>
> 現在、僅かな手掛かりしかないのが事実ですが、
> 前任者（別会社）の方に、/sys/f1、/sys/f2の件で問い合わせ中です。
>
> 今できそうなことは、こちらが、前任者から受け取った環境構築メモを元に、
> 新環境の構築手順を、箇条書き程度でまとめてみます。
>
> 少しお時間をいただきます。
> 明日には、ここに記載できるようにいたします。
>
> もし、その中に、おかしな点があればご教示ください。
>
> 何卒、宜しくお願い申し上げます。
>
>
> > 溝渕です。
> >
> > > ついでではありますが、今回の起動ログの最終段階で、
> > > アプリケーションがディスプレイにデータ展開できず、
> > > 終了しています。
> > >
> > > ＜前略＞
> > > auto-run-app.sh: 1.1.0
> > > Starting PVR Server: failed
> > > /etc/config/settei found. ＜＝これは、ユーザアプリで利用する、個別のフォルダです。
> > >
> > > atmark-dist v1.55.1 (AtmarkTechno/Armadillo-840)
> > > Linux 3.4-at27 [armv7l arch]
> > >
> > > armadillo840-0 login: Could not open egl display
> > >
> > > ここから、私共の何か至らぬ点が分かれば幸いです。
> > >
> > >
> > > アドバイスをいただければ幸いです。
> >
> > アプリケーションや環境等を把握していない為、ログメッセージのみからアド
> > バイスをするのは困難です。
> >
> > 何を行っているか(実行しているコマンドや独自アプリの実装、環境等)を教え
> > ていただけるとアドバイスできるかもしれません。
> >
at_mizo
溝渕です。
> １．手順に過不足があれば、ご指摘ください。
> ２．以下の手順合いで f0、f1、f2 のデバイスドライバに関わる部分があればご教示ください。
> ３．何かご提示させていただければ、より詳しいことが分かるソースやスクリプトなどの資源があればご指定下さい。
まず、今回の実質な問題はフレームバッファのsysfsノードが無いことですの
で、前任者様が作成された環境と現在ではLinuxカーネルイメージがなると思
います。
今回示していただいた手順には、Linuxカーネルへの変更は加えられていませ
ん(Armadillo-840の標準イメージです)。
以上より、前任者様はLinuxカーネルに何かしらの変更を行っていると思いま
す。
akio_tsuchiya
溝淵様
今回も、明確なご回答、誠にありがとうございます。
> 今回示していただいた手順には、Linuxカーネルへの変更は加えられていませ
> ん(Armadillo-840の標準イメージです)。
>
> 以上より、前任者様はLinuxカーネルに何かしらの変更を行っていると思いま
> す。
やはり、重要な手順が、環境構築マニュアルに記載されていないという事ですね。
この点を、前任者にお聞きしてから、必要ならば、改めてご相談いたします。
今回のご質問は、一旦クローズとしてください。
本当に、ありがとうございました。
> 溝渕です。
>
> > １．手順に過不足があれば、ご指摘ください。
> > ２．以下の手順合いで f0、f1、f2 のデバイスドライバに関わる部分があればご教示ください。
> > ３．何かご提示させていただければ、より詳しいことが分かるソースやスクリプトなどの資源があればご指定下さい。
>
> まず、今回の実質な問題はフレームバッファのsysfsノードが無いことですの
> で、前任者様が作成された環境と現在ではLinuxカーネルイメージがなると思
> います。
>
> 今回示していただいた手順には、Linuxカーネルへの変更は加えられていませ
> ん(Armadillo-840の標準イメージです)。
>
> 以上より、前任者様はLinuxカーネルに何かしらの変更を行っていると思いま
> す。
>
akio_tsuchiya
溝淵様
一旦クローズとしながら、やはりご教示いただきたい内容が３点あります。
申し訳ありません。
①昨日、御社のダウンロードサイトからatmark-dist-20160927.tar.gzを取得し、展開を行い、
前任の方から受け取ったatmark-dist-20160927.tar.gzも、別のフォルダに同様に展開を行い、
２つを比較したところ、大量の差異が検出されました。
御社のatmark-dist-20160927.tar.gzは、現時点と2016年の掲載当時では、内容が異なるでしょうか？
或は、この差異が、OSのカスタマイズととらえるべきでしょうか？
②この差異の中に、atmark-distフォルダ直下のMakefileに、添付ファイルの差異が見られるのですが、
この記述は、SGX対策ととらえればよいのでしょうか？
この時、利用しているその他の資源ファイルは、linux-3.4-at20.tar.gzとhermit-at-3.8.1-source.tar.gzです。
③今回の「NORフラッシュ書き換え対策」を考慮した場合、2018年当時のサイト掲載は「linux-3.4-at26.tar.gz」と
記載されておりますが、現時点では「linux-3.4-at27.tar.gz」を選択しても、問題は無いでしょうか？
現時点での「NORフラッシュ書き換え対策」での推奨が「at26」と捉える、社内担当もいる為、杓子定規な質問ですが
アドバイスいただければ幸いです。
（私自身は、「linux-3.4-at27.tar.gz」が、多くの対策が取られていて、より安心と考えています。）
何卒、アドバイスをお願い申し上げます。
> 溝淵様
> 今回も、明確なご回答、誠にありがとうございます。
>
> > 今回示していただいた手順には、Linuxカーネルへの変更は加えられていませ
> > ん(Armadillo-840の標準イメージです)。
> >
> > 以上より、前任者様はLinuxカーネルに何かしらの変更を行っていると思いま
> > す。
>
> やはり、重要な手順が、環境構築マニュアルに記載されていないという事ですね。
> この点を、前任者にお聞きしてから、必要ならば、改めてご相談いたします。
>
> 今回のご質問は、一旦クローズとしてください。
>
> 本当に、ありがとうございました。
>
> > 溝渕です。
> >
> > > １．手順に過不足があれば、ご指摘ください。
> > > ２．以下の手順合いで f0、f1、f2 のデバイスドライバに関わる部分があればご教示ください。
> > > ３．何かご提示させていただければ、より詳しいことが分かるソースやスクリプトなどの資源があればご指定下さい。
> >
> > まず、今回の実質な問題はフレームバッファのsysfsノードが無いことですの
> > で、前任者様が作成された環境と現在ではLinuxカーネルイメージがなると思
> > います。
> >
> > 今回示していただいた手順には、Linuxカーネルへの変更は加えられていませ
> > ん(Armadillo-840の標準イメージです)。
> >
> > 以上より、前任者様はLinuxカーネルに何かしらの変更を行っていると思いま
> > す。
> >
| ファイル | ファイルの説明 |
|---|---|
| atmarkdist-20160927_makefire.pdf |
at_mizo
溝渕です。
> ①昨日、御社のダウンロードサイトからatmark-dist-20160927.tar.gzを取得し、展開を行い、
> 前任の方から受け取ったatmark-dist-20160927.tar.gzも、別のフォルダに同様に展開を行い、
> ２つを比較したところ、大量の差異が検出されました。
>
> 御社のatmark-dist-20160927.tar.gzは、現時点と2016年の掲載当時では、内容が異なるでしょうか？
同一です。
弊社で公開しているファイルは、同名上書きを行いません。
> 或は、この差異が、OSのカスタマイズととらえるべきでしょうか？
恐らくですが、そのように推測します。
> ②この差異の中に、atmark-distフォルダ直下のMakefileに、添付ファイルの差異が見られるのですが、
> この記述は、SGX対策ととらえればよいのでしょうか？
この部分は、GPU driverをモジュールとしてビルドした場合に、ユーザーラン
ドにモジュールをインストールする処理を追加しています。
「SGX対策」が何を示しているのか私は認識しておりません。モジュールにす
ることで解決する問題等がありましたか?
> ③今回の「NORフラッシュ書き換え対策」を考慮した場合、2018年当時のサイト掲載は「linux-3.4-at26.tar.gz」と
> 記載されておりますが、現時点では「linux-3.4-at27.tar.gz」を選択しても、問題は無いでしょうか？
恐らく問題無いかと思います。
バージョン間での修正内容は次の通りです。
https://armadillo.atmark-techno.com/news/20191031/software-update-a800
> 現時点での「NORフラッシュ書き換え対策」での推奨が「at26」と捉える、社内担当もいる為、杓子定規な質問ですが
> アドバイスいただければ幸いです。
> （私自身は、「linux-3.4-at27.tar.gz」が、多くの対策が取られていて、より安心と考えています。）
弊社からのおすすめとしては、最新版をご利用いただきたいです。これは製品
マニュアルにも記載しております。
https://manual.atmark-techno.com/armadillo-840/armadillo-840_product_ma…
ただ、御社ソフトウェア品質担保の為にat26での試験が十分行なわれている状
況で、"at26->at27"での修正が御社にとって不要とご判断される場合は、無理
に上げる必要は無いかと思います。
akio_tsuchiya
溝淵様
いつも明快なご回答、誠に感謝いたします。
①atmark-dist-20160927.tar.gzの内容差異確認の件
> 同一です。
>
> 弊社で公開しているファイルは、同名上書きを行いません。
であれば、本件は、多岐に渡り、カスタマイズが行われているのは明確と言う事ですね。
同様に、hermitやlinuxも調査し始めました。
②SGX対応（前回添付ファイルの内容）確認の件
> この部分は、GPU driverをモジュールとしてビルドした場合に、ユーザーラン
> ドにモジュールをインストールする処理を追加しています。
>
> 「SGX対策」が何を示しているのか私は認識しておりません。モジュールにす
> ることで解決する問題等がありましたか?
SGX対策モジュールが適用された結果と言う事と理解いたしました。
・社内では、適用しても、変化が無かったので、適用されていないとお聞きしていました。
内容に差異がある為、前任者には、確認いたします。
③「linux-3.4-at27.tar.gz」採用の件
現時点では、「linux-3.4-at26.tar.gz」を選択する理由は無いです。
「linux-3.4-at27.tar.gz」の選択を検討いたします。
また、このようなアドバイスが戴けますと幸いです。
ご多忙の中、本当に感謝いたします。
> 溝渕です。
>
> > ①昨日、御社のダウンロードサイトからatmark-dist-20160927.tar.gzを取得し、展開を行い、
> > 前任の方から受け取ったatmark-dist-20160927.tar.gzも、別のフォルダに同様に展開を行い、
> > ２つを比較したところ、大量の差異が検出されました。
> >
> > 御社のatmark-dist-20160927.tar.gzは、現時点と2016年の掲載当時では、内容が異なるでしょうか？
>
> 同一です。
>
> 弊社で公開しているファイルは、同名上書きを行いません。
>
>
> > 或は、この差異が、OSのカスタマイズととらえるべきでしょうか？
>
> 恐らくですが、そのように推測します。
>
>
> > ②この差異の中に、atmark-distフォルダ直下のMakefileに、添付ファイルの差異が見られるのですが、
> > この記述は、SGX対策ととらえればよいのでしょうか？
>
> この部分は、GPU driverをモジュールとしてビルドした場合に、ユーザーラン
> ドにモジュールをインストールする処理を追加しています。
>
> 「SGX対策」が何を示しているのか私は認識しておりません。モジュールにす
> ることで解決する問題等がありましたか?
>
>
> > ③今回の「NORフラッシュ書き換え対策」を考慮した場合、2018年当時のサイト掲載は「linux-3.4-at26.tar.gz」と
> > 記載されておりますが、現時点では「linux-3.4-at27.tar.gz」を選択しても、問題は無いでしょうか？
>
> 恐らく問題無いかと思います。
>
> バージョン間での修正内容は次の通りです。
>
> https://armadillo.atmark-techno.com/news/20191031/software-update-a800
>
>
> > 現時点での「NORフラッシュ書き換え対策」での推奨が「at26」と捉える、社内担当もいる為、杓子定規な質問ですが
> > アドバイスいただければ幸いです。
> > （私自身は、「linux-3.4-at27.tar.gz」が、多くの対策が取られていて、より安心と考えています。）
>
> 弊社からのおすすめとしては、最新版をご利用いただきたいです。これは製品
> マニュアルにも記載しております。
>
> https://manual.atmark-techno.com/armadillo-840/armadillo-840_product_ma…
>
> ただ、御社ソフトウェア品質担保の為にat26での試験が十分行なわれている状
> 況で、"at26->at27"での修正が御社にとって不要とご判断される場合は、無理
> に上げる必要は無いかと思います。
>
at_mizo
2020年2月19日 11時35分
溝渕です。
> ＜ご質問１＞
:(省略)
> 恐らく、「fb1」と「fb2」のデバイスを、どこかにマウントすれば、この手法が利用可能と思われるのですが、
> 一般的には、何処と、どの様な記述でマウントすればよいのかご教示いただけないでしょうか？
RGB等の生画像を直接描画させる方法についてのご質問という認識で良いでしょうか。
フレームバッファデバイスは、/dev/以下にあります(/sys/以下ではないです)。
/dev/fb1に画像を書き込んでみてください。
例として、ランダムデータをフレームバッファに書き込むコマンドを示します。
画面には砂嵐のような画像が表示されると思います。
> ＜ご質問２＞
> もし、このような方法で、直接グラフィックデバイスにデータを書き込む場合のArmadillo-840内部の処理に対して、アドバイスを戴けないでしょうか？
>
> （１）CPUはOSからの多くの要求に対して、対応するタスクをスケジューリングして、処理スレッドを準備している。
> （２）一般的なグラフィック処理では、OSのドライバを介してグラフィック描画を行う為、タスクスケジューリングは、OSが把握可能。
> （３）これに対し、直接グラフィックデバイスに対してデータを書き込んだ場合、OSのタスクスケジュールは、タスクの重さを把握できるのでしょうか？
タスクの「重さ」とはとは何を指していますか。処理完了までの時間であれば、恐らく推計することは困難かと思います。
> （４）もしOSが感知できない場合、直接、CPUの処理スレッドが生成されると思うのですが、その際のスレッド処理優先度は、スレッドの重さを把握できるのでしょうか？
> ＝＞現在のマルチスレッド処理では、重たいスレッドを優先的にスケジューリングし、空きスレッドにガベージコレクトや軽いスレッドをディスパッチする仕組みと理解しています。
Linuxは優先度をnice値で指定可能です。「重さ」については、申し訳ございませんが意図が読み取れません。
> （５）上記の内容で、（４）のスレッド判定ができないまま、比較的重たいスレッドが複数ディスパッチされると、ハードウェアアクセラレーションの一つとして、SGX処理が呼び出されるものと理解しています。
SGX540ライブラリ経由でアクセスした場合は、SGX処理が呼び出されます。
Linuxカーネルがダイナミックに利用するハードウェア(CPU or SGX)を決定す
る機構については存じ上げません。
> 上記の結果、処理しきれない場合、SGXエラーが発生するとすると、対処の方法は無透かしいのでしょうか？
エラー発生時は、ソフトウェア(SGXドライバ)でエラー通知を実装している場合はユーザーランドに通知されます。