製品を jffs2 ファイル システムから ubifs に移行しています。
以前の jffs2 設計には、3 つの mtd パーティション (2 つの ro と 1 つの rw) が含まれています。
ubifs への移行 - 作成する必要があります:
基本的に、 ubifs に移動するときにパーティションをボリュームに置き換える必要があるかどうかを尋ねていますか? （そうすれば、ubiレイヤーがフラッシュ全体を管理するという私の理解）
ありがとう、ラン
オプションが存在し、ここに利点があります...
1 つの mtd パーティションと 3 つのボリューム
UBIレイヤーがボリュームを管理します。これは、信頼性の低いフラッシュを信頼性の高いメモリに変換するフラッシュ仮想化レイヤーです。UBI レイヤーはウェア レベリングを行います。読み取り専用データであっても、時々データを書き直すことは有益です。これにより、フローティングゲートなどが再充電され、データがより長く読み取り可能になります。読み取り/書き込みデータの場合、寿命にとって非常に有益です。UBI ウェア レベリングは、すべてのボリュームで行われます。これにより、ファイル システムが処理できる消去/書き込みサイクルが大幅に増加します。
3 つの mtd パーティション、それぞれ 1 つのボリューム
これは通常あまり望ましくありませんが、利点があり、一部のユーザーには適している可能性があります。主に個別のパーティションを持つことで、単一のボリュームをマウントする信頼性が向上します。単一の MTD パーティションに何かが発生すると、フラッシュ全体が使用できなくなる可能性があります。個別の MTD パーティションを持つことで、読み取り書き込みファイルシステムに障害が発生したときに、読み取り専用の MTD/UBI/UbiFS システムを使用できる場合があります。
これは実際には 3 番目のオプションにとってより有益です。
ファイルシステムが混在する複数の MTD。
CramFS、RomFS は、デバイス ブロックの信頼性がメーカーによって保証されている一部のフラッシュ デバイスに配置することができます。これは、システムが最低限機能するために必要なすべてのブート ファイル システムである可能性があります。これらのパーティションを操作するためのツールは (UBI/UbiFS と比較して) 非常にシンプルで、最小限のコード スペースで実装できます。一部のシステムには、小さなオンチップ SRAM を備えた大きな DDR があります。ローダー/フラッシュには、コードスペースが制限されている場合があります。
そうは言っても、最近 (過去 2 年間) mtd-utilsには UBI 解析コードが含まれています。これは、フラッシャー、リカバリ コードなどに移植する必要がある場合があります。リカバリ コードは、UBI/UbiFS パーティションのマウント/フェイルセーフ リカバリを行う、接続されたinitrdパーティションにある場合があります。
u-bootには、UBI/UbiFS コードを管理および操作するためのコードが含まれており、多くのプラットフォームで 2 フェーズ ブート (内部 SRAM から実行、DDR を構成してから移行) を使用して、ブート ローダーに豊富な機能を持たせます。 u-boot自体は、別のデバイス上にあるか、上記のように別の MTD にある必要があります。
2 番目のオプション3 つの mtd パーティション、それぞれ 1 つのボリュームは、おそらく最も可能性が低く、望ましくありません。1 つ目は、システム/フラッシュの寿命を優先します。後者は、より高い信頼性/回復のシンプルさを提供します。最善の方法は、パーティション上のデータと、データを回復するために利用できる Linux 以外のリソースによって異なります。幸せな媒体は、できる限り多くの NAND フラッシュ スペースを UBI に与え、論理的なパーティショニングが必要な場合はボリュームを使用することです。
通常、なぜボリュームを使用してすべてのデータをまとめるのか疑問に思いますが、これもデータの性質に依存します。