Hello, I am testing a custom board with 66AK2E05 and a 4K-page NAND chip, Micron MT29F4G08ABBFAH4, with 4K pages, 256 OOB bytes per page and 256KiB PEB.
In order to adapt the software, I have done the following, starting from the K2E-EVM source:
U-boot:
- Enabled CONFIG_SYS_NAND_PAGE_4K instead of CONFIG_SYS_NAND_PAGE_2K in the config header
- changed 2048 to 4096 in args_ubi environment variable
Linux Kernel:
- Commented out all "ti,cs-*" values in the .dts file to keep the settings configured by U-boot, in case the timings are too tight for the new NAND
The result is that I can program the NAND from U-boot, but in Linux if I try to do ubiattach -m 4 (the ubifs partition) I get a kernel error. This happers both after burning the ubi image from u-boot, and also formating the mtd partition using ubiformat:
[ 96.019096] ubi0: attaching mtd4 [ 96.026619] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry [ 96.041697] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry [ 96.057546] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry [ 96.071115] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes [ 96.081221] CPU: 0 PID: 574 Comm: ubiattach Tainted: G O 4.19.59-g5f8c1c6121 #1 [ 96.089853] Hardware name: Keystone [ 96.093346] Backtrace: [ 96.095805] [<c020ca30>] (dump_backtrace) from [<c020cd68>] (show_stack+0x18/0x1c) [ 96.103394] r7:c1004c48 r6:60000013 r5:00000000 r4:c104555c [ 96.109070] [<c020cd50>] (show_stack) from [<c09d5a9c>] (dump_stack+0x90/0xa4) [ 96.116311] [<c09d5a0c>] (dump_stack) from [<c071f248>] (ubi_io_read+0x1bc/0x340) [ 96.123812] r7:c1004c48 r6:00000040 r5:ffffffb6 r4:db710000 [ 96.129486] [<c071f08c>] (ubi_io_read) from [<c071f5f0>] (ubi_io_read_ec_hdr+0x4c/0x204) [ 96.137597] r10:00000000 r9:00000040 r8:db7a5d80 r7:00000000 r6:db710000 r5:db711000 [ 96.145444] r4:00000000 [ 96.147984] [<c071f5a4>] (ubi_io_read_ec_hdr) from [<c07244f0>] (ubi_attach+0x1d8/0x1518) [ 96.156181] r10:db711000 r9:00000000 r8:db7a5d80 r7:db710000 r6:db712000 r5:dc344f80 [ 96.164028] r4:00000000
Moreover, trying to read the NAND shows ECC errors in every block, eg.:
root@myboard:~# nanddump -l 0x4000 /dev/mtd4 > /dev/null ECC failed: 64 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 4 Block size 262144, page size 4096, OOB size 256 Dumping data starting at 0x00000000 and ending at 0x00004000... ECC: 8 uncorrectable bitflip(s) at offset 0x00000000 ECC: 8 uncorrectable bitflip(s) at offset 0x00001000 ECC: 8 uncorrectable bitflip(s) at offset 0x00002000 ECC: 8 uncorrectable bitflip(s) at offset 0x00003000
Also, U-boot reports OOB size as 128B, though I assume this is not critical since it needs 80 bytes for the ECC. Do I need to modify the ECC layout to take into account the larger OOB? This cannot be responsible for ubiattach crashing after ubiformat, so there must be something wrong (too) in the Linux code.
I suspect that the timing may also need relaxing, however I have not found a clear way to calculate the ns value required in the .dts (U-boot and Linux) based on the NAND specs. The interval names used in .dts are not clearly related to the NAND specs, am I missing some Application Note or other documentation on the subject?
Is there any TI experience / guidance with this or other similar NAND chips?
Any help appreciated.