0006647: mxs_nand_fus.c: 0-bits in empty pages are not handled correctly

ID	Project	Category	View Status	Date Submitted	Last Update

0006647	UBoot	NAND-FMD	public	2025-03-07 16:59	2025-03-07 17:04

Reporter	Keller	Assigned To
Priority	low	Severity	minor	Reproducibility	always
Status	new	Resolution	open
Product Version	fsimx6sx-V2.1
Target Version	fsimx-next

Summary	0006647: mxs_nand_fus.c: 0-bits in empty pages are not handled correctly
Description	Similar to the linux problem that showed "Corrupt empty space" in UBIFS, also U-Boot has problems handling empty pages in NAND that contain 0-bits. However here it does not lead to any problems unless a boot file like the kernel image or device tree is loaded from a UBIFS volume instead of from their MTD partitions.
Steps To Reproduce	The problem is difficult to reproduce. It took many months to get two boards from a customer that showed the error. Basically loading an empty page in raw mode, changing a bit to 0 and writing the page back in raw mode should trigger the bad behaviour when reading the page. - When reading the (manipulated) page in normal mode, the 0-bit should be visible. - When reading the page with a fixed driver, the 0-bit should be gone. Only reading the page in raw mode should reveal the 0-bit again.
Additional Information	The problem is in driver mxs_nand_fus.c. When reading data from a NAND flash page, the error correction is done by the ECC engine of the SoC, called BCH. When done, the BCH engine returns a status code. If there were any bit errors, then they are corrected and the status is the number of corrected errors, or zero if there were none. The resulting payload data is always correct, unless there were so many errors that the ECC could not handle them anymore. In this case the status is "uncorrectable". A third status "erased" is returned if the payload data and ECC consists of 1-bits only. This is the case after a page is erased and completely empty. In rare cases, it may happen that an empty page also has a few flipped bits, i.e. 0-bits. Such a page would be read as "uncorrectable", even though it is typically no problem to write data to this page nonetheless. For that, the BCH engine has the option to allow for a small number of 0-bits in a page and still return status "erased". The mxs_nand_fus.c driver makes use of this option. However it assumed that the read payload data is also corrected by the BCH engine in this case, i.e. that all read bytes are 0xff if the status is "erased", even if there were 0-bits in the page itself. Recent analysis has shown that this assumption was wrong. The resulting payload data still contains the 0-bits if there are any, no correction is done.

Forum Link

View Issue Details

Relationships

Activities