v2015.2.1というやや特殊なOSがArm9_cotex7で動作しています。argを受け取ります。次にこれをHardに出力します。linuxAddr);これによりHard側のLEDが点灯、意図通りに動作した感じです。この後全くのHangUp状態になりました。Stackなどシステム領域を壊したのではないかと疑っています。FPGAで構成されるHardはBASEADDRESS=0x43c00000への出力を要求しています。long));により=0x80958000を取得しています。__raw_writeそのものの欠陥も考えられます。(val));}ごく単純な内容のもののようです。arg;で置き換えてみました。Mapを調べてみました。[vectors]これでみると0x80958000付近が使われているようにも見えません。Hardが要求する固定のAddressにLinuxが対応できるとは限りません。RegisterをFPGAで構成されるHardに設け転写するというものです。Linux側だけでで対処可能な方法、あるいは判断の誤りを指摘していただければ幸いです。更新順1質問文からの引用FPGAで構成されるHardはBASEADDRESS=0x43c00000への出力を要求しています。long));により=0x80958000を取得しています。物理アドレスが0x43c00000で、仮想アドレスが0x80958000になっているようですので、仮想アドレスにwriteすればよさそうです(メモリマップドI/O)。Mapを調べてみました。879は一例です:...これでみると0x80958000付近が使われているようにも見えません。このマップはユーザ空間のプロセスのものですので、見るなら/proc/iomemの方じゃないかと思います。/proc/iomemに表示されるには、ドライバ側でioremapの前にrequest_mem_region()を呼んでI/Oメモリ領域を予約しておく必要があると思います。参考http://stackoverflow.com/questions/18580469/content-of-proc-iomem例えばドライバ初期化時にrequest_mem_region()を呼んで、終了時にrelease_mem_region()を呼べばいいいのかな。あとwriteする前にioremap_nocache()等を呼び、writeした後にiounmap()を呼べばいいのかなと思います。質問文からの引用_raw_writeそのものの欠陥も考えられます。定義を調べたところ...関係あるかどうかわかりませんが、I/Oに__raw_writel()を使っているのはなぜだろう?と思いました。見るのはiowrite32()だと思いますが、単純にそれを使ってはいけないのだろうか?と思いました。__raw_writel()は最も低レベル用のような気がしますが、あえて低レベルのものを使う理由が気になっただけで、特に深い理由はありませんが、何となく気になったというレベルの話です。この辺はハングアップとはあまり関係なさそうな気もします...また細かい話になりますが、arch/arm/include/asm/io.hを見ると、__raw_xxx()系の上位に当たるものとして、3種類のものが定義されていますね。念のため__raw_writel()に対応するものを抜き出してみます。})__iowmb()でメモリバリア対応。cpu_to_le32()でプロセッサネイティブなフォーマットからリトルエンディアンに変換。})__iowmb()でメモリバリア対応。cpu_to_le32()でプロセッサネイティブなフォーマットからリトルエンディアンに変換。})__iowmb()でメモリバリア対応。cpu_to_be32()でプロセッサネイティブなフォーマットからビッグエンディアンに変換。__raw_writel()について逆にいうと__raw_writel()はメモリバリア対応なしで、プロセッサネイティブなフォーマットでそのままwriteアクセスする、ということになると思います。それで良ければ問題なさそうな気がします。質問文からの引用Hardが要求する固定のAddressにLinuxが対応できるとは限りません。RegisterをFPGAで構成されるHardに設け転写するというものです。この質問の意味はよく理解できていませんが、gammodlerさんがやっているように固定の(物理)アドレスをプログラムにハードコードし、ioremap()等で仮想アドレスにマップすれば、FPGA側のレジスタにアクセスできるはずと思います。Treeを使う方法があるんじゃないかと思います。これは違う話になってしまいますが、参考になりそうなチュートリアルがあったのでURLを挙げておきます。(0)0blunder3様もうどなたからも回答いただけないものとあきらめかけておりました。本当に感謝いたしております。XilinxおよびPetalinux環境で参考事例をさがし、iowrite32()の方がBetterに思えたのでこれに変更しております。CPU:PowerPCでしたがそれで問題なかったので惰性でそのまま使用しておりました。PowePCはBigEndian、ARMはLittleEndian、しかしこれは影響しないと思います。iowrite32()でもHangUpの状況は変わりませんが、比較的単純なこのモジュールで無限ループにトラップされることはありうるのか検討してみました。);の条件になると無限Loopはありうるようにも見えます。BASEADDRESS=43c00000はHard側の開発ツールであるVivadoが割り当てたもので妥当性を欠くとは考えにくいです。関係筋に問い合わせて結果を報告いたします。ご意見があればお聞かせください。(0)0原因はHardにあることは間違いないと判断、AXIバスの基本をもう一度見直しました。PSからPLにデータアドレスを送ると、PLから読み出されたデータとRVALIDが返ってくる。PSからPLにデータアドレスと書き込みデータを送ると、PLからBVALIDが返ってくる。PLがRVALIDやBVALIDを返さず、無応答だと、PSはハングアップする。なるので、(もし私の勘違いでなければ)ハングアップの件はPL側の問題の可能性もあるのではないかと思います。Instructablesがヒントになりました。Shakeの仕様が明確に把握できていませんでした。それに代わりこの部分に関する基本モジュールが自動生成されるようになっております。accessできるRegister数で改善希望があるのと組み込むprocessが複雑でBuildが不成功に終わったなどの理由で別の方法に走ってしまいました。これが混乱のもとでした。初心者はやはり基本に忠実であるべきでした。基本モジュールを何とかInstallしてOUT/INPとも成功しました。روانشناسیAXIはIntel系、PowerPCなどと比較、かなりHardのケアが必要です。それも今回認識しました。今回の質問は結果的にHardが原因でしたがblunder3様の懇切なResにより解決に至りました。これで3回お世話になったことになります。本当にありがとうございました。今後もよろしくお願いいたします。原因はHardにあることは間違いないと判断、AXIバスの基本をもう一度見直しました。PSからPLにデータアドレスを送ると、PLから読み出されたデータとRVALIDが返ってくる。PSからPLにデータアドレスと書き込みデータを送ると、PLからBVALIDが返ってくる。PLがRVALIDやBVALIDを返さず、無応答だと、PSはハングアップする。なるので、(もし私の勘違いでなければ)ハングアップの件はPL側の問題の可能性もあるのではないかと思います。Shakeの仕様が明確に把握できていませんでした。それに代わりこの部分に関する基本モジュールが自動生成されるようになっております。accessできるRegister数で改善希望があるのと組み込むprocessが複雑でBuildが不成功に終わったなどの理由で別の方法に走ってしまいました。これが混乱のもとでした。初心者はやはり基本に忠実であるべきでした。基本モジュールを何とかInstallしてOUT/INPとも成功しました。AXIはIntel系、PowerPCなどと比較、かなりHardのケアが必要です。それも今回認識しました。今回の質問は結果的にHardが原因でしたがblunder3様の懇切なResにより解決に至りました。これで3回お世話になったことになります。本当にありがとうございました。今後もよろしくお願いいたします。再三のコメントありがとうございます。私はPL側の可能性に直行してしまいましたが、今回検索していただいたコメントではドライバー側の問題を指摘しています。主にはアクセスするアドレスを問題視しているようです。それからメモリアクセスが全く不成功に終わっているような印象を受けましが部分的な成功はあるらしい、ということは最初の1回は成功することが多い私のケースもこれに該当する可能性もあると思いました。そこでPL側を検討する前にドライバ、主には初期化部分を見直してみようと思います。Xilinxは初期化のためのTemplateを開示してくれています。従来PowerPCのケースでの成功例があるのでそれで良しとして必ずしもTemplateに従っていません。rc;}mydev_probeはここで登録されているようです。callが有効になるようにmydev_probeのトリガーもprocess側からかけるものなのかもしれません。この辺りが分かりません。mydev_init(void)のなかで呼んでしまえば済むことではあると思いますが。結果については報告いたします。今後もご支援いただければ幸いです。(0)0writeするとハングアップする件ですが、たしかにハード側に起因するかもしれないです。XILINKのフォーラムで同じような問題が取り上げられているようです。私はこの話題に詳しくないので、的外れのことを言っているかもしれませんが、上のXILINKのフォーラムのやり取りからリンクされている下の議論を見て思ったことです。PSからPLにデータアドレスを送ると、PLから読み出されたデータとRVALIDが返ってくる。PSからPLにデータアドレスと書き込みデータを送ると、PLからBVALIDが返ってくる。PLがRVALIDやBVALIDを返さず、無応答だと、PSはハングアップする。なるので、(もし私の勘違いでなければ)ハングアップの件はPL側の問題の可能性もあるのではないかと思います。(2)gammodlerさんの3個目の投稿(2016/02/12)へのレスです。00:30ハングアップに関する自分の認識について追記しました。11:450ハングアップの原因はよくわかりませんが、デバイスドライバは他のドライバのソースを参考にしつつ、一般的なやり方に従って書けばよさそうな気がします。ところでネットで見ると「digilentのチュートリアル」が評判が良さそうです。私はやった訳ではないですが、見た感じでたぶん参考になりそうだと思ったので挙げておきます。やってみた記事中の「オフィシャルドキュメント」(pdf)へのリンクは残念なことに切れていますが、「ドラフト版」のリンク(下記)の方は現時点でアクセスできます。Steps」をクリックするとチュートリアル全体が表示されます。「Next」をクリックすると1ステップずつ進みます。myled.c」のところにデバイスドライバのソース(myled.c)へのリンクがあります。これを落として中身を読むと参考になると思います。request_mem_region()、ioremap()、iounmap()、release_mem_region()、iowrite32()の使い方のイメージがつかめます。Treeに追加しています。I/Oメモリ領域の物理アドレスやサイズはその際にdtsファイル内に書き込んでいます。Treeを使用していますが、gammodlerさんがやっているように物理アドレスをハードコードしても(テスト目的なら)別に構わないとは思います。追記ちなみに無限ループの話ですが、特に心配する必要はないと思います。addr)に置き換わります。addr)を呼び出しメモリマップドI/Oを行ないます。(0x10000)より大なら、outl(val,port)を呼び出しPIOを行ないます。(0x0ffff)でマスクします。(0x10000)を足していることが前提になっているのではないかと思います(あまり自信ありませんが)。その他の場合は、bad_io_access()を呼び出します。iowrite32()がこういう風になっているのはたぶん移植性とか汎用性のためと思います(違うかもしれません)。前述のようにARMの場合はwritel()もoutl()も最終的には最下位の_raw_write()を呼び出します(いずれにせよメモリマップドI/Oです)。do-whileループを使っていますが、これはC言語のマクロで複数の文を一つのグループにまとめるための常套手段であり、while(0)なので、実際はループはしていません。なんでこんなことをするかというと、理由は下のページあたりを参照してください。https://www.jpcert.or.jp/sc-rules/c-pre10-c.htmlという訳で無限ループについて心配する必要はないと思います。(9)無限ループの件について追記しました。11:03lib/iomap.cの引用部分にbad_io_accessも含めました。解決に苦慮するなか懇切な解説を頂き本当に感謝いたしております。紹介していただいた平易なドキュメントも参考にさせていただきます。Driver側から見て無限Loop要因はないことを指摘していただきこれを前提に検討を進めているのですが、実はHard側に要因がありうるのではないかと考えました。if;によりwriteRegにLatchしております。PortのRegisterであった場合、書き込みAと読み出しB二つPortを備えています。Counterを更新できません。完全なHangUp状態となります。これを思いついたのは過去にこのような事例に遭遇、原因究明に苦労した記憶があるからです。解決策は最初からHard上でBをfloating状態にしておくことです。DiscreteならともかくFPGA内ではどうすればいいのかわかりません。Portを意識して使用していません。Lampが点灯します。Hard上でオッシロであたったところ絶えず変化しているはずのwritAddr,writeBusがLevelになってしまっているのが観測されました。上記の推測に矛盾しません。conceptに基づく通常とは異なるBus、myIPにアクセスしていないときは変化がないのは正常なのかもしれません。以上論点がHard寄りになってしまいました。上記の推論が正しいならソフト側から追求しても正解に至れません。ご意見を伺えれば幸いです。(0)ウォッチこの質問への回答やコメントをメールでお知らせします。