お久しぶりじゃないどらびさんです．
先日の投稿に引き続きでpolarfire周りの進捗になります．
一番よくわかってなかったところなので備忘録的に書いてます．
ビットストリームとデバイスツリーをとにかく何とかしたい話
linuxからのビットストリームとデバイスツリーオーバーレイの設定方法に関して
beagleboardの指示に従っていると↓のシェルスクリプトを使えと書かれています．
例えばこれとかに．
ですが，Yoctoでディストリビューションをビルドする場合，完全にすべて自前で用意する場合はさておき，microchip公式のリポジトリでYoctoのレシピが公開されており，そこでBVFが2024/9~正式にサポートに入っているのでこれを使うのが楽だと思います．(正確には思ってました…)
というわけで私はそれをお借りしているわけですが，そうするとBVFのFWよりも使われているカーネルのverが新しいことに起因して，上述のshのやり方とはビットストリームやデバイスツリーオーバーレイのアップデート方法が変更になっています．
そのため，このシェルスクリプトをそのまま使う事は出来ないという事で下記リンクを参考に最新のやり方に沿って行く必要があります．が，コレやろうと思うと事前準備が大変そうなので自分は最終的に諦めました．
(最初後半だけ読んでて，なぜか上手くいかんとか思って再度ページ読み直したら前半の設定もすごく大事だったという．ちゃんと上から読めやって話ですがワードでググってページ内も検索かけて読んだりするとこういう罠にはまったりすることあるよね？え，ない…？)
通常のデバイスツリー更新のやり方(起動中のみ)
というわけで普通にデバイスツリーを更新することにしました．今まではspi経由で書きこむ前提だったので.spiという拡張子のファイルたちを生成していたのですが，今度は.dtbo形式(コンパイルされたデバイスツリーのファイル形式)で生成しなきゃなので，コンパイル前の.dtsoファイルを拾ってきてBVFに入れて，dtc(デバイスツリー用のコンパイラ)でセルフコンパイルしました．
一応後の手順は下記を参考にしています．
で，結果としては依然として思っていた通りにデバイスツリーオーバーレイは反映されてませんでした．
まあコンパイル時からアドレス被ってる的なwarning出放題だったので至極当然な様な気もします．
ただ，自分が知っている確認手段では何がどうなっているのかよくわからん状態だったので，とりあえずfabric側のLSRAMがに割り当てた最初のアドレスにdevmem2でリードしてみたら0x00と返事がきました．ストールせずに値が出てきたのは初めてなので，一旦進捗したと言っていいでしょう?
(※なおそこに書きこもうとしたらストールしました．進捗とはなんと儚い夢なのでしょう．)
冗談はさておき，原因追及が必要です．少なくとも今回うまくいった要因もうまくいかなかった部分も十中八九デバイスツリーのソースが正しくないことに起因していると思います．
もっと言うとそもそもメインのデバイスツリーに出鱈目なアドレスが書かれ放題なのを何とかしないとどうにもならないような気がしています．というわけで，またしてもYoctoのビルドに戻ってくることになるわけですね．
Yoctoでのデバイスツリー修正方法
Yoctoに関しては正直素人なので，直し方等々が正しいかはいったん置いておくとして，2024/11/27現在，自分が最低限uioとu-dma-bufを扱えるようにするために何を変更しているかを備忘録的に書き記しておきます．
正直このリポジトリに対して正しく編集をかけるとしたらどこをどうするのかさっぱりなのですが，とりあえずやっていきます．少なくとも今回は「一旦動確させたい」が目標であってこのリポジトリに対してプルリクを投げたりするわけでもないので，Yoctoのポリシーは見なかったことにして汚していきますｗ
devicetreeの編集
まず，公式が出している以下のyoctoレシピ，beaglev-fireに対応したとは言うものの実際にビルドしてみるとどうやらデバイスツリーが変な気がします．
オーバーレイかけようにもアドレスが被っていると多分うまく適用されないんでしょうね．(詳しくは知らない)
というわけでまずはデバイスツリーを書き換えに行きます．
<meta-polarfire-soc-yocto-bspのインストール先>/build/tmp-glibc/work-shared/beaglev-fire/kernel-source/arch/riscv/boot/dts/microchip
以下に，
- mpfs.dtsi
- mpfs-beaglev-fire-fabric.dtsi
- mpfs-beaglev-fire.dts
がありますので，この3つを編集します．(今回，関連ある部分としてはmpfs-beaglev-fire-fabric.dtsiだけ編集しました．spidevだけついでにmpfs.dtsi側に足しましたが，そっちはこちらを参照にして後からでも弄れます．core-minimal-devでbitbakeしなければですが…)
ここは各々のビットストリームなどによって変わる部分なのであくまで参考程度に…
(参考として中身載せる)
とりあえずこれで書き換える部分についてはOKなはずです．
ただしこれだけだと反映されないので，レイヤーを作って編集したdtsiを置いて適用させます．
(※結局色々とやり直したりで，最終的には追加レシピすら作らず，一旦カーネルだけbitbakeして(MACHINE=beaglev-fire bitbake mpfs-linux) ,その後上記のデバイスツリーファイルらを所望のものに書き換えるなりしてからディストリビューションのbitbakeを走らせ直すという作戦でイメージ作ってます．どうせmenuconfigいじらないとで先にカーネルだけbitbakeする(-c menuconfigオプション)ならとりあえず一旦レシピなくてもええやん．という思想です．非常に良くないと思うので動確まで終わって諸々仕様が固まったらレシピはちゃんと用意しようかと．)
u-dma-bufの追加
まずもってu-dma-bufとは？という話ですが，DMA(Direct Memory Access)をlinux上で使用するためのデバイスドライバになります．もうこれ以上の説明はする気ないので下記リンクを参照のこと．
本当にたまたまなのですが，こちらのデバイスドライバの作者とXで相互フォローでした(なぜこんなすごい人が私をフォローしてくれてたのかは本当に謎)
というわけでこうなって
3日後くらいにRISCVでコンパイルできるようになってて
更に気づいたらmicrochip謹製のYocto linuxに独自のスクリプトと悪魔合体したu-dma-bufが発掘されました．やはり原作者がいると話の進みが段違いですね．私一人だったら間違いなく挫折してた．
で，原作者のikwzmさんはこのままpolarfireで最新のu-dma-bufの動確等を進めるべく今(2024/12/16時点)も開発/調査を続けていらっしゃるのですが，私はこれが本筋ではないので，という事で一旦microchip謹製のu-dma-bufもどき？を使っていくことにしました．というわけで，menuconfigさえすればu-dma-bufは入っている状態になります．カーネルコンフィグ周りは次の章でまとめて書いてあるのでここでは割愛します．
主に備忘録を兼ねているので，途中まで奮闘していた「本家u-dma-bufを入れる独自レシピ作成」に関しても少しだけ書いておきます．
独自レシピで最新のu-dma-bufを入れたかった
下記を参考に追加のレシピ，bbappendファイルをまず作成します．
が，microchip独自のu-dma-bufが邪魔してどうしてもこちらを入れることができませんでした．
polarfire用のカーネル，mpfs-linuxを準備しているレシピで参照してくるリポジトリを独自のものに変更して，そこでカーネルのソースからdrivers/dma-bufを削除したものを指定した上で上記のレシピを適用させれば行けそう．
ただ今回のメインではないので一旦サスペンド．もっとYoctoを深く理解できるようになったらやりたいところではある．
カーネルコンフィグの変更
下記リンクにはcleanなどしてカーネルコンフィグも初期状態に戻ってしまうのをdiffconfigによって回避できると書いてあるのですが，
一度やろうとしてうまくいかなかったので，もうやりながら変更点メモ書いていきます．
(※そのあと上手くfragment.cfg生成できました．めでたし．)
というわけで以下変更点．
Device Drivers —>
staging_driver —> [] → [y]
(※u-dma-bufの説明に従って設定していくとstaging driverの下にKconfigができるが，この時点ではKconfigは適用されていないので，staging_driverをyにしても項目は出てこない．でもこの後手動でu-dma-bufの項目は[m]に設定するので，staging_driverのみ[y]にしておく．)
Device Drivers —>
DMA Engine support —> [y] → []
Device Drivers —>
DMABUF options →[y]
Device Drivers —>
Userspace I/O drivers —>
Userspace I/O platform driver with generic IRW handling [y] → [m]
Users;ace ;latform driver with generic irq and dynamic memo [y] → [m]
Generic driver for Microchip Fabric DMA controller [y] → []
(microchip謹製u-dma-bufの設定をモジュールにした方が良い理由の参考↓)
一旦区切り
歯切れが悪いですが今回はこの辺で終わりにしておきます．
進めながら書いていたのですが見返したらまあまあなボリュームで，これ以上増やすとわからなくなりそう…
次のもすぐ書きます．しばらくは備忘録的な記事が続くかと思いますがご容赦ください．
コメント