diff mbox

How to write to nand with an image containing oob data, including ECC?

Message ID 4D92566F.7040209@silka.with-linux.com
State New, archived
Headers show

Commit Message

Kelly Anderson March 29, 2011, 10 p.m. UTC 
On 03/29/11 09:42, Artem Bityutskiy wrote:
> On Tue, 2011-03-29 at 17:30 +0200, Ricard Wanderlof wrote:
>> Hi,
>>
>> In order to test an ECC algorithm (BCH in this case, as I recently posted
>> about), i want to write an image to a nand flash which contains bit
>> errors.
>>
>> What I want to do, and I seem to remember doing this in the past, is to
>> dump the whole image, change a single bit, and write it back, including
>> the oob.
>>
>> So what I'm doing is
>>
>> $ nandwrite -o -n /dev/mtd3 /tmp/mtd3-badimage
>>
>> where /tmp/mtd3-badimage contains an image including all oobs for all
>> pages.
>>
>> However, this fails saying
>>
>> Writing data to block 0 at offset 0x0
>> libmtd: error!: cannot write 2048 bytes to mtd3 (eraseblock 0, offset 0)
>>           error 22 (Invalid argument)
>> nandwrite: error!: /dev/mtd3: MTD write failure
>>              error 22 (Invalid argument)
>> Data was only partially written due to error
>> : Invalid argument
>>
>> Using just -o doesn't work because it seems nandwrite writes the oob, but
>> then since it doesn't write the main page in raw mode, the ecc gets
>> overwritten. Strangely enough, the ECC doesn't seem to match the data
>> written, as I get uncorrectable errors when reading back (not just with
>> BCH, but also with the standard mtd built-in algorithm). Perhaps the oob
>> gets written twice, once with my data and once more with the calculated
>> ecc?
>>
>> Is this a known bug, or are the some other options I should be using?
> Check this bug-report, probably it is about the same. Not sure, I did
> not have time to look at this:
>
> http://lists.infradead.org/pipermail/linux-mtd/2011-March/034505.html
>
> would be great if someone just sent a fix :-)
>
OK, I'll be nice.

When I sent the original bug report I was dog tired.  Now with a good 
nights sleep I've got the energy to write a fix.

Not sure if this is technically correct, or if it handles corner cases 
adequately.  In any case, it does work.  As far as 16 goes, I selected 
it based on the code that calls do_oob_op and it looked to be the 
largest clmpos that was valid.

Comments

Ricard Wanderlof March 30, 2011, 7:33 a.m. UTC | #1 
On Wed, 30 Mar 2011, Kelly Anderson wrote:

>>> $ nandwrite -o -n /dev/mtd3 /tmp/mtd3-badimage
>>>
>>> where /tmp/mtd3-badimage contains an image including all oobs for all
>>> pages.
>>>
>>> However, this fails saying
>>>
>>> Writing data to block 0 at offset 0x0
>>> libmtd: error!: cannot write 2048 bytes to mtd3 (eraseblock 0, offset 0)
>>>           error 22 (Invalid argument)
>>> nandwrite: error!: /dev/mtd3: MTD write failure
>>>              error 22 (Invalid argument)
>>> Data was only partially written due to error
>>> : Invalid argument
>>>
>>>
>>> Is this a known bug, or are the some other options I should be using?
>> Check this bug-report, probably it is about the same. Not sure, I did
>> not have time to look at this:
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2011-March/034505.html
>>
>> would be great if someone just sent a fix :-)
>>
> OK, I'll be nice.
>
> When I sent the original bug report I was dog tired.  Now with a good
> nights sleep I've got the energy to write a fix.
> ...

Artem, my case seems to be a completely different problem. I tried 
applying Kelly's patch and it didn't make a difference in my case. Makes 
sense, as the error messages in the bug report were entirely different 
from what I was getting.

(That's not to say Kelly's patch doesn't work or do what it's supposed to 
do, it just didn't seem to be related to the problem I've been having).

But I am I right in understanding that nandwrite should perform as I 
expect it to when I say -o and -n to it? I.e. the -o means there's oob 
data in the image, and -n means don't write any ECC, so the image I'm 
supplying should be written exactly as it looks to the flash, including 
the oob?

If it is in fact the case I might have a go at fixing it eventually. Need 
to find some other solution right now though (like patching the kernel to 
force errors on write or something like that).

/Ricard
diff mbox

Patch

--- ./lib/libmtd.c.orig    2011-03-29 15:24:13.000000000 -0600
+++ ./lib/libmtd.c    2011-03-29 15:42:47.000000000 -0600
@@ -1085,6 +1085,7 @@  int do_oob_op(libmtd_t desc, const struc
      unsigned long long max_offs;
      const char *cmd64_str, *cmd_str;
      struct libmtd *lib = (struct libmtd *)desc;
+    uint64_t clmpos = (start % mtd->min_io_size);

      if (cmd64 ==  MEMREADOOB64) {
          cmd64_str = "MEMREADOOB64";
@@ -1102,10 +1103,10 @@  int do_oob_op(libmtd_t desc, const struc
          errno = EINVAL;
          return -1;
      }
-    if (start % mtd->min_io_size) {
-        errmsg("unaligned address %llu, mtd%d page size is %d",
+    if ( clmpos > 16 ) {
+        errmsg("address %llu, mtd%d page size is %d, clmpos=%llu",
                 (unsigned long long)start, mtd->mtd_num,
-               mtd->min_io_size);
+               mtd->min_io_size, clmpos);
          errno = EINVAL;
          return -1;
      }