0

こちらの手順を使用して、beaglebone black (Angstrom ディストリビューション) で spi を有効にする作業を行っています。

/sys/devices/bone_capemgr.*/slotsドライバを有効にするために BB-SPI1-01 を追加する必要があるところです。

echo BB-SPI1-01 > /sys/devices/bone_capemgr.*/slotsただし、コマンドまたはを発行するecho BB-SPI1-01 >> /sys/devices/bone_capemgr.*/slotsと、エラーが発生しますecho: Write error: file exists

nano で行を編集しようとしても失敗します。ファイルを開いて編集することはできますが、保存するとError writing slots: no such file or directory

ファイルのパーミッションを 777 に設定しました。

ファイルを編集できない理由を誰か知っていますか? 不可能な場合、回避策はありますか?

4

5 に答える 5

2

私も、ILI9340C ディスプレイを Beaglebone Black に移植しようとしているときに、このジレンマと戦ってきました。その/dev/devices/bone_capemgr.*仕組みは、ディレクトリにエコーするものは何でも、そのslotsデバイスのデバイス ツリー オーバーレイを探しに行くというものです。これは、Linux カーネル 3.0 以降の新しい機能です。知らない人のために(これを見つけるのに私は永遠にかかりました)デバイスツリーは基本的にLinuxにデバイスの処理方法を伝えるドライバーですが、コードを含むのではなく、それ自体は単なる構成ファイルです。デバイスと対話するために何をどこに置くべきか、そしてその見返りに何を期待するかを Linux に指示します。つまり、コンパイルされたデバイス ツリー ファイル ( SPI デバイスを指すBB-SPIx-01.dts) であり、それをどう処理するかを指示します。/lib/firmware/spidev

BB-SPI1-01たまたま何らかのオーディオ用にすでにHDMIポートに接続されているため(私は思う)、したがって、HDMIを完全に無効にしない限り、SPI1常にHDMIフレーマーによって拘束されます。BB-SPI1-01これは、書き込みが/sys/devices/bone_capemgr.*/slots失敗する理由を説明しています。これは特別なファイルであり、それに書き込むと、カーネル プロセスが入力を読み取り、別の場所に「デバイス」ファイルを作成しようとします。BB-SPI1-01すでに有効になっているため、そのファイルは既に存在し、処理するカーネル プロセスはこれらのものはエラーを返し、それを開始したプロセスにパイプします。この場合は、ユーザーがecho BB-SPI1-01 > /sys/devices/bone_capemgr.*/slots.

明るい面でSPI0は、未使用のままです。したがって、それを使用するには、ユーザーランドで有効にするだけです。これを行うにはecho BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots、コマンド ラインで入力し、spidev が実行されていることを確認するために、modprobe spidevroot として入力します。ここで、確認するために、入力ls /dev | grep spiして何が表示されるかを確認します。/dev/spidevX.Yはあなたの SPI バスです/dev/spidev1.0

本当に長くなって申し訳ありませんが、誰かの助けになることを期待して、これまでの研究を1つの場所にまとめています.

ご不明な点がございましたら、お気軽にお問い合わせください。

于 2014-01-09T02:56:07.450 に答える
0

Mixazがコメントで述べたように、実際エラーはdmesg出力で見つかります。「そのようなファイルやディレクトリはありません」はニシンでありstrace、実際の問題についての手がかりさえ与えません。私の場合、私は見つけました:

[26858.517893] bone_capemgr bone_capemgr: slot #5: override
[26858.517937] bone_capemgr bone_capemgr: Using override eeprom data at slot 5 
[26858.517986] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,jc_gpio_test'
[26924.230357] bone_capemgr bone_capemgr: part_number 'jc_gpio_test', version 'N/A'

そこから「0000」というバージョン番号が気に入らなかったのかと推測し、「00A0」に変更して再コンパイルしたら動きました。

これは、プロセスの自動化に役立つように作成した Makefile です。

%.install: %-00A0.dtbo
    cp -f $< /lib/firmware
    echo $* > /sys/devices/platform/bone_capemgr/slots
%-00A0.dtbo: %.dts
    dtc -O dtb -o $@ -b 0 -@ $<

make jc_gpio_test.installファイル.dts名がjc_gpio_test.dts.


結局のところ、私の推測はおそらく間違っていました。おそらく修正された変更は、ファイルに-00A0パーツを追加することでした。dtboどうやらスロットローダーには「dash-versionnumber」が必要です。

于 2017-07-12T01:44:49.490 に答える