私は最近の Linux カーネルを、Freescale の i.MX28 EVK キットや Karo TX28 ボードなどの既存の古いハードウェアに移植しています。ファイル システム内の NAND FLASH の一部 (NAND 内の「userfs パーティション」) を使用したいと考えています。
最初のステップは、ubiattach /dev/ubi_ctrl -m 6 を使用することです。この操作はボリューム テーブルの検索を試み、NAND チップを読み取り、いくつかの gpmi_read_page 操作を実行します。これにより、start_dma_without_bch_irq (gpmi-nand.c) で DMA タイムアウトが発生します。奇妙なことに、最初のいくつかの read_page 操作は成功します。その後、タイムアウトが発生します。
第一印象はタイミングの問題でした。NAND のタイミングを変更しても、観察された動作は変わりませんでした。主に GPMI、GPIO、割り込みコレクターのレジスタの値に焦点を当てた多くのデバッグでは、何も明らかになりませんでした。
i.MX28 EVKボードのNANDチップの制御ラインに測定接続をいくつか取得できました。Saleae（模造）ロジックアナライザを使用して、正しいトランザクションの数（20、40などの範囲）を確認できます。次に、読み取りが設定され、NANDが準備完了を通知し、GPMIにデータの読み取りが要求され、GPMIはNANDからデータをクロック出力しますが、失敗するチップ イネーブル ライン (ロー アクティブ) を設定します。GPMI は内部的に正しく動作していないようです。読み取り操作の終了を通知する ISR が入力されていません (2 番目のチップ イネーブル ラインを使用して通知しましたが、デバッグ出力でも同じことが示されています)。そのため、タイムアウトが発生します。GPMI が内部的に「混乱」しているようです。
タイムアウト後もチップ イネーブル ラインのピン マルチプレクサが正しいことを確認しました。デバッグ出力から判断すると、Karo TX 28 でも同じことが起きています (ピンの測定は行われず、接続できませんでした)。
i.MX23 の問題に関する古いメールを見たことがあります。GPMI を 2 回 (U-boot と Linux カーネル) リセットすると、GPMI がハングアップします。この修正を試しても状況は変わりませんでした。この問題は Linux カーネル 5.0.8 と 4.20.7 で発生しています。私の判断では、NAND は U-Boot から使用すると正常に動作します。U-Boot が使用するのと同じタイミング設定を試しましたが、うまくいきませんでした。
また、Karo ボードでは Samsung NAND が使用され、i.MX28 EVK では Spansion の部品が使用されていることにも注意してください。したがって、これは特定の NAND チップとは関係ないようです。また、NAND パーティションが U-boot の Linux ブート コマンド ラインから接続された場合も同じことが観察されることに注意してください。
問題は、根本的な原因と可能な修正を見つけるために何をすべきかということです。
答え1
まず、デバッグをたくさん行いました。解決策は見つかりませんでした。その後、動作している古い Linux バージョンがあることに気付きました (何年も前に別の会社が準備したものです)。これは、ハードウェアの問題ではないことを証明しています。また、2 つの異なるハードウェア ボードで同じ問題が発生するという事実は、ハードウェアの問題ではないことを示しています。ある時点で、古い動作ソリューションにできるだけ近い古い Linux バージョンを試してみることにしました。これにより、独自のビルドを使用してカーネル 3.16.68 が正常に動作していることが示されました。5.1.5 および 4.20.7 のビルドでは、NAND FLASH の問題が見られます。さらに実験を行ったところ、最後に動作していたカーネルは 4.16.18 であり、4.17.1 以降で問題が発生していることがわかりました。その途中で、Freescale GPMI 周辺機器の NAND FLASH サポートが再構築されたようです。これは、新しいプロセッサ/SOC に対応するために Freescale によって行われたものだと思います。古いハードウェアのサポートが壊れているようです。Freescale がこのことを認識しているかどうかはわかりません。フリースケールが古い i.MX28 をサポートしなくなったという兆候があります。とにかく、違いを分析する時が来ました。決定的な違いは、追加された GPMI 周辺機器のクロック周波数を適応させる関数呼び出しのようです。何らかの理由で、この 1 つの呼び出しをコメント アウトした後、GPMI 周辺機器は NAND FLASH で正しく動作するようです。このコードは、ファイル "drivers/mtd/nand/raw/gpminand/gpmi-lib.c"、関数 "gpmi_nfc_apply_timings" にあります。"clk_set_rate" の呼び出しをコメント アウトするだけです。少なくとも私の場合はこれでうまくいきました。後で、プロセッサが i.MX28 の場合にのみ呼び出しを回避して、それ以降のチップで動作するようにした方がよいことに気付きました。
clk_set_rate が正確に何を行うのか、またすべてのプロセッサで動作させるためにどのように呼び出す必要があるのかを分析しませんでした。他のハードウェアを持っていないので、それを確認することはできません。