JFFS2 doesn't use OOB on I.MX53

[marianodo]

Hi,

I'm using Connect Core IMX53 board with Kernel version 2.6.35.14 and Yocto 1.4 OS.

I have a random problem when writing operations are done over the Nand Flash: for instance when I insert rows into the database (the file grows) or when I copy new files to the jffs2 partition. Sometimes I got an input/output error and after that I won't be able to recovery the file neither if I try to remove or if a try to copy a new file which override the one who has problem.

Below you can see the logs:

When I insert "ls" command, the terminal throw:

'./res' input/output error   ("res" is the folders name)

And if I check the Kernel log:

jffs2_scan_inode_node(): CRC failed on node at 0x0df497c0: Read 0xffffffff, calculated 0x33b7fc9f
JFFS2 error: (1) jffs2_build_inode_pass1: child dir "res" (ino #9334) of dir ino #9333 appears to be a hard link

JFFS2 warning: (973) jffs2_get_inode_nodes: Eep. No valid nodes for ino #9334.
JFFS2 warning: (973) jffs2_do_read_inode_internal: no data nodes found for ino #9334
iget() failed for ino #9334
JFFS2 notice: (746) check_node_data: wrong data CRC in data node at 0x0df47474: read 0xfbf9abb7, calculated 0xbf64ad10.
JFFS2 warning: (1016) jffs2_get_inode_nodes: Eep. No valid nodes for ino #9334.
JFFS2 warning: (1016) jffs2_do_read_inode_internal: no data nodes found for ino #9334

Also I checked in U-boot if exist any bad blocks and it doesn't.

I was researching how a Nand flash works and I found that it has an Out-of-Band (OOB) area that contains an Error-Correcting-Code (ECC) algorithm. This ECC is used to check and fix any possible writing error.

So, when I was checking if that feature is enabled in my board I found in the kernel log the message:

user.warn kernel: Memory policy: ECC disabled, Data cache writeback

user.info kernel: JFFS2 doesn't use OOB.

I want to know if my hypothesis is correct and how can i enable and use the ECC and OOB?

Thanks

[TomE]

> user.info kernel: JFFS2 doesn't use OOB.

This is all very complicated.

The NFC Controller in the i.MX53 doesn't support JFFS2. Not without a lot of patches and work.

JFFS2 requires access to the OOB area in the NAND chip to write "this block is erased" markers. It has to be able to do that independent of the data in the block.

The NFC Controller in the i.MX53 may be able to separately handle the data and the OOB, but there's no driver code to do that, and if there was you'd probably have to do the ECC in software rather than letting the hardware do it. The Hardware ECC sums all 512 bytes of the data, PLUS the first 8 bytes of the OOB, giving a checksum which it then writes into the last 8 bytes of the OOB. So if you were able to change the erase marker in the OOB it would corrupt the ECC. So this can't be used.

So Freescale added the following patch to the system to stop this from happening. That patch is the source of your "JFFS2 doesn't use OOB" message. It means "the JFFS2 driver has been patched to be able to work without the erase marker, and the underlying platform requested it not be used":

http://git.tqc.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=commitdiff;h=93c3823f2fdb889ad9a56fc4bb9...

It is the last patch on fs/jffs2/fs.c in this tree:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/fs/jffs2/fs.c?h=imx_2.6.35_maintain

Fairly obviously, everything that reads and writes your JFFS2 partition has to be patched to behave the same way. That means that if your Bootstrap is meant to be able to read and write JFFS2, then it has to have the same patches!

If you're simply constructing pre-packaged JFFS2 partitions and writing them to Flash as-is, then you may not need this. If you're booting the kernel "some other way" and then initialising the JFFS2 partitions from Linux you should be OK. But watch out for this.

Separately (but related), the NAND Chip Manufacturer marks Manufacturer Bad Blocks by guaranteeing a certain byte in bad pages will be written with a non-erased value. The Manufacturer assumes the pages in the chip are used as 2048 bytes of data followed by 64 bytes of OOB. The first (or fifth or all) byte in the OOB is the marker.

The NFC controller treats the 2048+64 bytes in a page as four blocks of 512, interleaved with 16 bytes of OOB.

So the NFC's treatment of the pages means the Manufacturer's marker in in the last data area, and can get overwritten if you're not careful!

One of the patches that Freescale applies to Linux 2.6.35 swaps two bytes in the page on read and write to preserve that marker. This means you can re-scan for the marker at any time. The alternative is having to be REALLY careful in production and converting the Manufacturere's BBT into the "custom BBT" (written to the last blocks) only ONCE during production. If you do it a second time you lose the BBT information, and more likely find thousands of "fake bad blocks".

If your Bootstrap is going to read or write the NFC at all then it needs to know that Linux is doing the same thing.

Here's someone asking that question back in 2013 and not getting a single answer:

http://u-boot.10912.n7.nabble.com/NAND-BBI-swap-on-iMX53-td167668.html

But the above does give the reference to the Freescale document which you should read to get the details on this:

https://community.freescale.com/servlet/JiveServlet/download/329191-260869/AN_MX_NAND_BAD_BLOCK.pdf

The "check_node_data: wrong data CRC" message you're getting have nothing to do with the NFC's ECC correction. JFFS2 has its own CRC scheme, which is applied to all the blocks in its journalling system. So what you really need is a JFFS2 equivalent of "fsck" to run over the file system. There is no such utility. Some posts say JFFS2 doesn't need it and fixes all errors itself.

http://lists.openmoko.org/pipermail/community/2010-May/062095.html

http://www.infradead.org/pipermail/linux-mtd/2004-February/009260.html

https://lwn.net/Articles/467206/

I'd suggest you regenerate the partition from scratch. Reformat it and load the data again. See if that makes the problem go away. And then decide if that is a solution you can safely ship to customers.

I've tried to add debugging and to understand these things, but when JFFS2 goes wrong it is not very helpful. You can turn massive amounts of JFFS2 debugging on which then take a very long time to print without helping you to understand the problems or fix them.

If you do get a specific version of Linux patched to work on the i.MX53, then you're stuck on that version. You can't move forward to a different (newer) kernel without working out how to re-apply all the patches that made it work. And they won't reapply as the underlying code got changed, so you have to port the patches.

The best answer to these problems is to ditch JFFS2 completely and use UBIFS-on-UBI instead. That's what we were told to do when we had problems. Just don't use JFFS2 on this chip.

Tom

[marianodo]

Hello Tom,

I deleted all partition and then created again, but the error still happening. Also I debbuged the filesystem as you said, its slow and I couldn't get any helpful information. Further, I wrote in another forum and someone told me that I had to migrate to UBIFS. I researched that Filesystem and I concluded that UBISF is best thant JFFS2 for my application. 

So that was the solution for my problem.

Thanks for help me!

[igorpadykov]

Hi Mariano

I wrote :

"max. supported options: 4KB + 218 Bytes (16-bit ECC)."

so 128 Bytes also supported.

>* Do you think that the problem could be the page size?

yes

Best regards
igor

[igorpadykov]

Hi Mariano

one can check if that nand could be supported by i.MX53 NAND Flash Controller (NFC),

max. supported options: 4KB + 218 Bytes (16-bit ECC).

Check if it is supported by Linux, refer to attached Add new_NAND support.pdf file,

use mfg tools (attached part MFGTool ucl_profile_MX53ARD-NAND(JFFS2).txt showing

used commands for nand programming).

Programmers (Flash, etc.) (3)
IMX_MFG_TOOL (REV 1.6.2.048)
http://www.nxp.com/products/power-management/pmics/pmics-for-i.mx-processors/i.mx53-quick-start-boar...    

may be useful link

https://community.nxp.com/thread/429125 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[marianodo]

Hi igorpadykov.

I will check if support that option. Do thing that the problem could be the page size?

Thanks for the answer

Best regards

[marianodo]

Igor

* Do you think that the problem could be the page size?

Also, when you write

"supported options: 4KB + 218 Bytes (16-bit ECC)."

You want to say 128 Bytes instead of 218 Bytes?

Best regards

Mariano