Looks like a workaround to upper layer MTD issues.
Yep, I did some work on launching mtd on olinuxino, but I still have many questions regarding how NFC works.So, Qiang, threewater:1) How hardware ECC works in combo with MTD tools that use OOB? For example, I have 8192+448 NAND, in the standard (sunxi_nand block emulation) driver my chip, for some reason, marked as 8192+32 (0x2000+0x20). If different OOB size is needed for each type of chip, we will need to modify drivers/mtd/nand/nand_base.c (also in 3.4 kernel standard MTD driver cant decide right for chips with big OOB sizes like 448 or 640. if you have changes to nand_*.c or mtd includes, please, share them). Why driver doesnt care about blank pages ECC checking and everything, even pages with no errors go through the HWECC? I copied this check from Samsung's ECC driver: https://github.com/rzk/linux-sunxi/blob/048177f49950706978bb110387807b0103a42949/drivers/mtd/nand/sunxi-nand/nfc.c#L844
2) How ECC modes correlate with NAND ECC support. For example, my NAND chip has 100bit/2048byte ECC defined in datasheet. What ECC mode should I use for Allwinners NFC?
3) Why random is completely disabled in your driver? (https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L1046) Shouldn't it be enabled all the time for MLC NANDs?
4) What does this line mean https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L400 ? And also, driver needs to get rid of many magic numbers like this one. This should be defined somewhere with understandable naming.
5) If I have OOB less that 1024, but read_size is set to 1024, will NFC read only needed OOB size? I met a condition in my tests when I had OOB data overlapping with normal data, dont quite remember how I did it, but it was something related to read_size.
6) Why driver doesn't care about -1 chip select? Check comment at https://github.com/rzk/linux-sunxi/blob/048177f49950706978bb110387807b0103a42949/drivers/mtd/nand/sunxi-nand/nfc.c#L416
7) Right now driver works very bad with badblock table and checking. I have confirmed that last 4 blocks of my NAND are bad (wrong data after reboot is stored there), but neither system badblock check, badblock table of ubifs detect that these blocks are bad. Standard Allwinner's driver has different block quantity for my NAND chip set, it is 950 instead of full 1024 (maybe they faced same issue). Any ideas and can this be connected to NFC or could this be a particular NAND chip problem?
--
with to many Bad eraseblock messages.
I've managed to used in the same board (cubieboard) previously without an issue.
Any help will appreciated.
I have encountered exactly the same problem as you. After applying the driver, I cannot read or write due to "Bad eraseblock xx" error. I am writing to ask you whether you have solved the problem. If the answer is yes, would you please tell me the solution.
Thank you very much. Best regards.