0002278: Fix NAND read/write commands in case of bad blocks

ID	Project	Category	View Status	Date Submitted	Last Update

0002278	UBoot	NAND-FMD	public	2014-06-26 14:00	2014-07-10 17:02

Reporter	Keller	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	resolved	Resolution	fixed
Product Version	fsvybrid-V1.2
Target Version	fsvybrid-V2.0	Fixed in Version	fsvybrid-V2.0

Summary	0002278: Fix NAND read/write commands in case of bad blocks
Description	If 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 Reproduce	Mark 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 Information	There 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

View Issue Details

Activities