broken NAND on whole series of mini2440 ?

We bought around 50 pieces of mini2440 boards and later we discovered that
more than 20 of them have problems with uploading winCE image or
write/read_back to/from NAND memory.

First, we thought it was only 64bit win7 usb driver problem, but after
trying also from winXP, situation was the same. Same kind of errors and
only some of the boards (not all of them).

What surprises me is really high number of (new!) boards unable to be
flashed properly. I somehow suspect bad quality of NAND memory in whole
latest production series because it didn't happen before in last two years
with same type of board.  

Anyone meet something similar ?

regards,
Borut

Same problem here i bought around 500 pieces/ year and last 3 years and
last 6 months 
were terrible.

Borut, i just bought 2 mini2440 from china, both seems fine. 
is the problem happen using SD card installation or USB download?

I am using USB dowload ..  didn't try SD card yet.. could you suggest any
tutorial how to do it ?

I bought 5 mini2440 1GB with P35 LCD, where if we start the system with SD
card inserted, the touch screen is hanging up. Is any body facing this
issue or only my boards. It was not with other Boards with X35 and W35 LCD.
Any body suggest the solutions for it.

If your boards were 1G Flash this might be the 1G Flash issue. We changed
our Flash chip last year, which initially was not very well supported in
the BSP. We fixed this issue and you can try our latest image files from
our FTP site.

Hello ,
    All guys , can you please tell me what series flash of your board  ?
And did you use the newest images ?And did you use superboot.bin or
supervivi.bin ? It is the best to tell me your flash series .

Hi,
I have some problems with new NAND Flash. On the older Mini2440, that I
have is K9K8G08U0B, and on the newest board is K9K8G08U0E. Is the change,
that @bloggcerat told? I found the datasheet with the differences (B-series
is the same as D in times)
http://www.phytec.de/fileadmin/user_upload/pictures/Support/LPN-134e_1.pdf.
Please give mi some advice about the software changes. Could you upload the
new sources for Linux kernel to Mini2440 board? @bloggecart told that,
"latest image files are on our FTP site", but I have did not found it for
Mini2440, could you check it up?

Thanks for any new information about the problem.

Andy

Hello andy,
     If  your board's flash is K9K8G08U0E , you have to use newest zimages
, beacuse friendlyarm modified the BSP . And the old zimages does not
support newest flash board , and you can not use supervivi for your board ,
it does not support .

Hi,
thanks for answer. Could you share the links, where can I download the
binary files of kernel and u-boot? I will be happy, if you can share the
source codes too.

Many thanks, Andy

Hi Andy,

   The problem is that you can only write a page in the K9K8G08U0E memory
once. Check the K9K8G08U0E datasheet, the parameter NOP1 (Number of Partial
Program Cycles) . The old memory, K9K8G08U0B, is NOP4.
    When you try to save the enviroment address in the first page of the
first block (this procedure behavior seems to be default in the u-boot
code), this page is corrupted and the board don't boot anymore.

   FIRST ACTION - Create a patch to u-boot to set the environment address
hard-coded. Check below a patch that I apply:

->index d9b47f0..e5ffc94 100644
--- a/include/configs/mini2440.h
+++ b/include/configs/mini2440.h
@@ -236,12 +236,21 @@
 #define CFG_MAX_FLASH_SECT  512  /* 512 * 4096 sectors, or 32 * 64k blocks
*/
 #define CONFIG_FLASH_SHOW_PROGRESS  1
 
 /*
  * u-boot environmnet
  */
 #ifndef CONFIG_MINI2440_NOR_ENV
 #define  CFG_ENV_IS_IN_NAND  1
-#define CFG_ENV_OFFSET_OOB  1  // dont define for CFG_ENV_IS_IN_FLASH
+//#define CFG_ENV_OFFSET_OOB  1  /* this version will use fix env offset
*/
+#define CFG_ENV_OFFSET     0x40000
+

Second Action -> In Kernel, disable SUB-PAGE in nand modules. If you will
use JFFS2, check a paper from micron. Search in google - tn2975 enable on
die ecc nand jffs2

Oliver thank you for your advice.

Of course, If I will move the ENV out from OOB, memory won't be
"unexcpected modified". But the same problem is for writing the kernel and
OS image. Images are jffs2 type, that needs to be write over the OOB.
U-boot for this type of memory can't write to OOB correctly.