09-04-2020 05:46 PM - edited 09-08-2020 09:07 AM
Now we are using NAND device MT29F4G08ABADAWP, which was successfully handled as follows by previous Linux kernel 4.14.x version in Xilinx Linux github.
[ 0.231159] nand: Micron MT29F4G08ABADAWP
[ 0.231658] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 0.232666] nand ff100000.nand: On-Die ECC selected
[ 0.233293] nand: WARNING: nand: the ECC used on your system is too weak compared to the one required by the NAND chip
[ 0.235287] Bad block table found at page 262080, version 0x01
[ 0.237143] Bad block table found at page 262016, version 0x01
[ 0.238438] 9 cmdlinepart partitions found on MTD device nand
[ 0.239161] Creating 9 MTD partitions on "nand":
Would you let me know the situation of NAND drivers (ARASAN driver + MICRON driver) inside of kernel version 5.4.x ? Have you ever hear that It might take physical damage on this NAND device? Up to now, 3 boards were completely gone after testing Linux kernel 5.4.x. We cannot erase any block on the micron NAND devices on those boards now. Even getting back to the old kernel 4.14.x, the same result we had now. We couldn't erase any block.
Looking into kernel drivers inside of Linux kernel 5.4.x, the driver calls API "set_feature" to change attributes of micron NAND, then it would be required? Was it able to be the source of such an issue to permanently change the behavior of NAND flash memory? It was only applied only at run-time ?
Any experience/workaround/idea for this?
Thanks in advance.
09-15-2020 04:21 PM - edited 09-15-2020 04:23 PM
Dear Xilinx buddies.
I checked up this issue in more detail, and I now figure out an exact problem is Arasan NAND driver. Please if anybody can handle this issue, I would like to humbly ask him to share with me his idea.
NAND operation still works good, but "INTSTS register" of ARASAN NAND driver doesn't work since "XCMPL" (Transaction Complete) bit wasn't cleared after the completion of Page Program/Erase jobs. The NAND looks something wrong. When I commented out a part of code to check up the XCMPL bit of the STATUS register (just make it work in blind way after long delay) , everything is fine. I wonder whether I can check-in this treatment could be safe in real field....