This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

workaround: am3517 NAND (x8) write errors in Linux

Other Parts Discussed in Thread: AM3517, AM3359

Hi!

We have a custom board with am3517 and Samsung k9f2g x8 NAND. Using Linux 2.6.37 from http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git -- OMAPPSP_04.02.00.07 branch.

When writing flash (jffs2 and ubi) we were getting errors of this sort (for jffs2) -- "Write of X bytes at Y failed. returned -5, retlen 0 Not marking the space at Y as dirty because the flash driver returned retlen zero"

Seeing other posts related to this we wanted to share our findings. We have found that for some reason the flash read/write/erase operations can take a lot of time to finish in polled mode.

Increasing the timeout for omap_wait(...) in omap2 nand driver removes all problems (it seems).

--- a/drivers/mtd/nand/omap2.c

+++ b/drivers/mtd/nand/omap2.c

@@ -924,11 +924,11 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip)

                                                        mtd);

        unsigned long timeo = jiffies;

        int status = NAND_STATUS_FAIL, state = this->state;

-

+       //HACK:

        if (state == FL_ERASING)

-               timeo += (HZ * 400) / 1000;

+               timeo += (HZ * 4000) / 1000;

        else

-               timeo += (HZ * 20) / 1000;

+               timeo += (HZ * 1000) / 1000;

 

This is a hack however as the above timeouts are silly to be honest (the above timeouts are just some big enough numbers, as samsung spec says that 5/10/500us should be enough for r/w/e).

Seeing how the omap_wait code is written the performance of the flash is still pretty good as it will only have the complete timeout if an error actually occur (we belive).

Enableing DMA prefetch also works, however when flash load is high errors can still occur. We belive this is because of fallback to polled mode operations if DMA is busy.

We are currently using DMA prefetch with the above change to omap_wait, which feels pretty stable.

This is what we have found as of yet. It would be nice to get some comments on wheter this might be a problem with the NAND timings set in x-loader. We have not noticed any problems with flash in u-boot though, so this seems unlikely(?).

Another note is that we cannot use subpage writes with UBI and must manually turn these off in kernel to get ubi to work. When subpage is off ubi seems to work well.