問題タブ [imx6]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
yocto - Yocto Image のビルドが失敗する理由は、「何も RPROVIDES libavresample がない」ためです。
iMX6 ベースのボード SECO A62J 用に fsl-image-gui に基づいてカスタム Yocto イメージを構築しようとしています。これには Hob を使用します。
マシン、レイヤー、イメージを選択した後、クロムを追加してパッケージ リストをカスタマイズします。これにより、Chromium の依存関係である libexif と libav が自動的に選択されます。パッケージのビルドは成功です
最後のステップはイメージ自体のビルドであり、ここで問題が発生します。Chromium、libexif、libav (およびその依存関係) など、イメージに含めたいパッケージを選択します。
そして、私はそれらのエラーを得ました:
RPROVIDES 'libavresample' は何もありません (ただし、/home/adrien/fsl-release-bsp/build_anna/recipes/images/fsl-image-gui-edited-20170131-144607.bb RDEPENDS か、そうでなければそれを必要とします)
と
必要なビルド ターゲット 'fsl-image-gui-edited-20170131-144607' にはビルド可能なプロバイダーがありません。欠落しているかビルドできない依存関係チェーンは次のとおりです: ['fsl-image-gui-edited-20170131-144607', 'libavresample']
ただし、ライブラリ libavresample.so は正常にビルドされ、sysroots/"machine_name"/usr/lib/ のビルド ディレクトリの下にあります。
Yocto がこのライブラリを見つけてイメージに含めることができないのはなぜですか。
usb - IMX6 USB ホスト コントローラーの詳細
IMX6 プロセッサを搭載したボードで WinCE7 を実行しているシステムがあります。システムの負荷が高い場合、USB トレーサで約 2 秒間、IN トークンが表示されないことがあります (バスが有効であることを示す SOF のみが表示されます)。ドライバーのどこかで、"IssueBulkTransfer" 関数の呼び出しが行われ、Microsoft ライブラリを経由して BSP に到達すると思われます。私の質問は、ホストコントローラーに IN トークンを送信するように指示した場合、コントローラーのマイクロコードは、ドライバーが毎回 IN トークンを再送信する必要がなく (したがって、CPU 時間を使用して)、 NAK を受信した場合に IN トークンを送信し続けるでしょうか?
ありがとう
yocto - yocto から特定のパッケージを削除する方法
特定のハードウェア (nxp の imx6 saber-sdb) 用に yocto を構築しています。ビルド プロセスから特定の (クロム) パッケージを削除したいと考えています。Chromium パッケージがダウンロード、コンパイルされず、ターゲット イメージの一部にもならないようにします。
誰かがこれを行う方法を私に提案できますか?
よろしくお願いします、ギリ
assembly - アドレスによっては NEON vst ストアが非常に遅い
アセンブラでネオンに最適化されたボックス フィルタを作成しました。i.MX6 (cortex-a9) で実行されています。私は今、マシンのメモリ帯域幅の問題について説明していますが、これは私の観察を説明していません:
私のコード(インラインアセンブラ)
画像全体に 105 ミリ秒かかるため、命令ごとに 25 CPU サイクルになります!
vst 命令のみを削除すると、アルゴリズムは最大 9.5 ミリ秒まで高速化されます。これは、メモリ帯域幅に関する私の期待に適合しています。
ここで、入力バッファーと出力バッファーを交換してみましたが、同じ量のロードとストアに 17 ミリ秒もかかりませんでした! 入力バッファが以前に書き込まれたため、違いが予想されていた場合は、L2 キャッシュに残っている可能性があり、より高速に読み取ることができますが、キャッシュされていないデータから読み取って保存する方が 6 倍高速です。キャッシュされた...
どちらのバッファーも 512 ビットのアライメントを持ち、同じキャッシュ ポリシーで同じメモリ領域に存在します。
何が問題の原因であるか、またはそれをさらに調査するために何を試みるかについて何か考えがありますか?