6

Linux で組み込みデバイスの以前の ROM ダンプをフラッシュするのに苦労しています。以前のダンプに oob データが含まれています。で書き込んでnandwrite -n -N -o /dev/mtd0 backup.bin、再度ROMダンプをとります。

古い ROM ダンプと新しい ROM ダンプを比較すると、説明のつかない状況が見られます。空のブロック (0xFF で埋められている) の oob の最後の 24 バイト (ecc バイト) も 0xFF である必要がありますが、新しい ROM のものはダンプは 0x00 で埋められ、後で書き込みエラーが発生します。

oob は次のようになります。

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

しかし、次の場合nandwrite:

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF 00000000 00000000
00000000 00000000 00000000 00000000

誰でも理由がわかりますか？

コードにハックを追加して、nandwrite書き込む内容が の場合に NAND への書き込みをスキップすると、うまくいきました0xFF。では、空のページを NAND に書き込もうとすると問題が発生するのでしょうか?

追加した：

現在、ブートローダー イメージの書き込み時にもこの問題が発生しています。画像はページ位置合わせされていないため、nandwriteでパディングされてい0xFFます。ただし0xFF、ecc バイトのみを含むページの場合は、0x00上記のようにまだ汚染されています。私のハックは私の問題を完全には解決していないようです。誰でも助けることができますか？おそらく、カーネル 2.6.35 のバグでしょうか?

これは私のハックです：

int i;
int needwrite=0;
for (i = 0 ; i < len ; ++i){
    if(((uint8_t*)data)[i]!=0xff){
        needwrite=1;
        break;
    }
}
if(!needwrite)
    return 0;
4

4 に答える 4

2

申し訳ありませんが、Alvinですが、特定のビットがいつ良好から限界に、または限界から不良に移行するかがわからないため、バックアップは実際には「その特定のフラッシュでのみ機能する」わけではありません。ある状態で読み取り、まったく同じ状態で書き込もうとすると、特定の日に、特定のバックアップで失敗する可能性があります。

NANDデバイスのデータを安全にバックアップする唯一の方法は、ECCをオンにすることです。良好なデータを取得するために、ECC補正を使用してデバイスから読み取ります。次に、ECCをオンにして正常なデータをNANDに書き戻し、以前に読み取ったときから限界または不良になっているビットを、新しいECC値を使用して修正できるようにします。

于 2013-03-16T22:12:30.943 に答える
0

私の埋め込みの世界では、最初flash_eraseにすべてをブラストし、次にnandwrite -pデータ以外のページの残りの部分を0xFFで埋めるために使用します。

Usage: nandwrite [OPTION] MTD_DEVICE [INPUTFILE|-]
Writes to the specified MTD device.

  -m, --markbad           Mark blocks bad if write fails
  -N, --noskipbad         Write without bad block skipping
  -o, --oob               Image contains oob data
  -O, --onlyoob           Image contains oob data and only write the oob part
  -r, --raw               Image contains the raw oob data dumped by nanddump
  -s addr, --start=addr   Set start address (default is 0)
  -p, --pad               Pad to page size
  -b, --blockalign=1|2|4  Set multiple of eraseblocks to align to
  -q, --quiet             Don't display progress messages
      --help              Display this help and exit
      --version           Output version information and exit
于 2013-03-09T05:48:38.887 に答える
0

これはあなたへの警告だからです。確実に動作しません。

ブロック (1) の位置 0 にエラーがある状況を考えてみましょう。Nand フラッシュ デバイスの「コントローラ」は、このエラーを修正するためにエラー修正コードを配置します。

ECC を使用してブロック 1 からデータをコピーしますが、データを新しい Nand-flash デバイスに書き込むと、データのクローンが作成されます。その新しい nand-flash デバイスの位置 1 にエラーがある場合、位置 1 が不良であるため、書き戻すデータは次の読み取りで間違っています。しかし、ECC は位置 1 にエラーを示さないため、システムはそれが正しいと判断します。

ハード/ソフト エラーの位置が同一ではないため、1 つの nand-flash を別の nand-flash に直接確実に複製することはできません。

確実に行う唯一の方法は、データを読み取り、システムの ECC アルゴリズムを使用してエラーを修正することです。データを新しいデバイスに書き込み、システム アルゴリズムを使用してビット エラーを修正します。

デバイスは同じだと思うかもしれませんが、結果はビット エラー マップの不一致によるデータ/プログラムの破損です。

Alvin のコメントに応えて:

私はまったく同じ NAND のクローンを作成していると確信しています。つまり、その特定のチップのバックアップを作成し、それをその特定のチップに書き戻しています。同じだと思うのは私ではありませんが、最初から最後まで1チップしかありません。非常に奇妙ですが、一部の人は自分のデバイスで動作したと述べていますが、私のデバイスでは動作しませんでした。ドライバーにバグがある可能性はありますか? – アルビン ウォン 8 月 5 日 5:16

申し訳ありませんが、不可能です (本当に..本当に..本当に幸運で、欠陥が 0 のチップを手に入れた場合を除きます)。

各 Nand-Flash チップには独自の欠陥ビットのセットがあり、それらは一意です。ユーザーがこれを回避する方法は、不良ビットが CRC の能力を超えた場合に不良ブロックをマスクするファイル システムを生成することです。nand チップを別のデバイスにコピーすると、CRC マップがマスター チップと一致します。デバイスの 1:1 クローンを作成すると、一部のデータ ビットが書き込み後に反転し (不良セル)、クローンを実行しているため、これらのビットが反転したことを CRC で考慮しません (あなたは逐語的なコピーを行っています）。

一部の人にとって「機能する」という事実は、私が車を運転できるのと同じように、それが正しいことを意味するものではありませんが、必要なときにのみブレーキが機能しないことがわかります. さらに悪いことに、ネット上でいわゆる「専門家」の多くが、製造元から提供された欠陥マップを実際に消去し、欠陥マップを保存する前にデバイスを「複製」したり、「チップ消去」を実行したりします。

これは、eBay から出てくる「危険な」nand-flash USB スティックの多くで起こることです。実際には、「欠陥マップ」が消去されたチップです。その結果、コンテンツを保存しようとするまでは、良いデバイスのように見えます。 .

于 2012-08-05T03:30:41.320 に答える
0

私のハックnandwriteは、書き込まれるページ全体が完全に空 (つまり、いっぱい0xFF) の場合、プログラムは書き込みをスキップするというチェックインを追加してflash_eraseいます (以前に行われたように)。

追加の利点nandwriteは、空のページをスキップするため、プロセス全体が高速になることです。ほら！

追加した：

私のハックは実際には問題を解決しなかったことが判明しました...

再度追加：（実際の解決策）

問題は、実際には PXA310 がハードウェア ECC ビットを0x00空白ページで埋めるため、ソフトウェアが空のページを書き込むと、ビットが取得され0x00ます。の引数ですでに ECC を無効にしているはずなので、これは奇妙ですnandwrite。幸いなことに、空のページの書き込みをスキップすると、ROM ダンプの再書き込みの問題を防ぐことができます。

詳細については、私のブログ投稿を参照してください。

linux-mtd リストに送信されたパッチは、実際にその事実について言及されています。

于 2012-09-28T14:51:46.050 に答える