View Issue Details

IDProjectCategoryView StatusLast Update
0002278UBootNAND-FMDpublic2014-07-10 17:02
ReporterKeller Assigned To 
Status resolvedResolutionfixed 
Product Versionfsvybrid-V1.2 
Target Versionfsvybrid-V2.0Fixed in Versionfsvybrid-V2.0 
Summary0002278: Fix NAND read/write commands in case of bad blocks
DescriptionIf NAND data of a partition is accessed with "nand read" or "nand write" without giving the size, the size is automatically taken from the partition size. This will work if there is no bad block in this region.

However if there are any bad blocks, these blocks will be skipped. But nonetheless the given number of bytes (=original partition size) are read or written, resulting in an access of the first block(s) of the *next* partition. This may be fatal if writing (destroying the data at the beginning of the next partition). And a read access may be aborted with an error, if the next block is not holding any valid data and produces non-correctable ECC errors.

Add a way to prevent this from happening.
Steps To ReproduceMark a block as bad within the Kernel partition

  nand markbad Kernel

Then download and store a Linux image:

  tftp . uImage
  nand erase.part Kernel
  nand write . Kernel

As the Kernel partition is 4MB, this call will store 4MB of data. But as the bad block at the beginning of the Kernel partition is skipped, 4MB will not fit into the Kernel partition anymore. So the call will also overwrite the first block of the next partition, usually TargetFS. This is fatal!

BTW you can unmark the bad block again with

  nand scrub Kernel 20000
Additional InformationThere are other issues with the nand command. For example the size for read.oob is not computed correctly, so we can not read as much data as would be possible in one go.
Forum Link


There are no notes attached to this issue.