軽量hps-to-fpgaブリッジ(またはすべてのブリッジ)に接続されている周辺機器にアクセスしようとするとLinuxがハングするのはなぜですか?

軽量hps-to-fpgaブリッジ(またはすべてのブリッジ)に接続されている周辺機器にアクセスしようとするとLinuxがハングするのはなぜですか?

私はAltera DE1-SoC開発ボードを8ヶ月間作業してきました。私が開発しているシステムには、Cyclone V FPGAチップ、特に5CSEMA5F31C6Nが含まれています。チップ上で組み込みLinuxオペレーティングシステムを実行します。

すべてがうまくいっており、開発が進行中です。 2週間前、同社のハードウェアエンジニアは新しいカスタムボードを組み立てました。デザインとコンポーネントは基本的に開発ボードに似ています。すべてのHPS関連ピンは同じ方法で接続されていますが、主な違いは、デフォルトのコンソールポートがUART1であることです。これで問題が解決し、UART1を介してU-bootとカーネルメッセージを受信できるようになりました。

ただし、システムは完全に起動しません。私はいくつかの理由でこれを指摘しました。まず、GPIO LEDをエクスポートしてsysfsファイルを生成するinit.dスクリプトがあります。 GPIOピンのエクスポートは機能しますが、方向を変更したり、値を変更したり、ピンからデータを読み取ったりするとシステムがハングします。 init.dスクリプトで機能を無効にし、デバイスを再起動しました。今回は、他のinit.dスクリプト行で起動に失敗しました。この行は、軽量ブリッジのレジスタ値を変更します。命令はでありdevmem 0xFF200XXX 32 1、XXXは特定のレジスタです。

すべてのブリッジでdevmemを試しましたが、すべての試みでLinuxがハングしました。 HPSのUARTレジスタ、HPSのSDCardレジスタでdevmemを使ってみました(参照)ここ)、凍結しません。

各ブリッジの状態 sysfs ファイルを読み取って、ブリッジが有効になっていることを確認できます。 fpga_bridgeステータスリターン有効

また、次のdmesg出力を使用して、ブリッジがドライバに接続されていることを確認することもできます。 dmesg 出力

Quartus Platform Designerを使用して、hps構成で3つのブリッジをすべて有効にしました。 u-boot.scrには次の行もあります。

fatload mmc 0:1 $fpgadata soc_system.rbf;
fpga load 0 $fpgadata $filesize;
setenv fdtimage soc_system.dtb;
run bridge_enable_handoff;
run mmcload;
run mmcboot;

また、次のU-bootコマンドラインでブリッジングを有効にしようとしました。このガイドライン

ただし、$l3regsには何も書き込めません。 l3regsに書き込む

Buildroot 2016.05および4.4 Linuxカーネルを使用してオペレーティングシステムを構築しています。私は.rbf、.dts、.dtb、preloader-mkpimage.bin、およびu-bootファイルを生成するためにSoC EDS 18.1 [ビルド625]を使用しています。

試してみることが不足していました。

sysfsファイルを使用してLinux OSでLEDをオン/オフできる場合は、問題が解決したようです。

ハードウェアが正しいと仮定すると、考えられる他の原因は何であり、どのように解決できますか?

ベストアンサー1

返信ありがとうございます。この問題は解決されました。

ボードでは、50MHz発振器を使用してHPS周辺機器をクロックし、同時に同じ50MHzクロックで25MHzの信号を生成し、ファブリックのHPSクロックピンに接続します。

新しいボードでは、50MHz発振器を使用する代わりに25MHz発振器を選択しました。今回は、シングルレールが発振器からファブリックのHPSクロックピンに直接接続されます。

HPS周辺機器に使用できる他の時計はありません。

したがって、専用の HPS クロックを内部で HPS ペリフェラルの入力ピンにルーティングします。これは、専用のHPSクロックピンがGPIOではないため、Cyclone Vアーキテクチャでは実行できないため、バグです。

おすすめ記事