[U-Boot] [RFC PATCH] Add support for Micron MT29F8G08 8Gb NAND flash MID: 0x2c, DID: 0x38

[micro1183 <micro1183@gmail.com>]

On 12/11/2013 06:22 PM, Scott Wood wrote:
> On Wed, 2013-12-11 at 12:02 +0100, micro1183 wrote:
>> Microns MT29F8G08 8GBit flash is not identified correctly.
>> Manufacturer ID is 0x2c, device ID is 0x38
>>
>> Signed-off-by: Lothar Felten <lothar.felten@gmail.com>
>> CC:  scottwood at freescale.com
>>
>> ---
>>  drivers/mtd/nand/nand_ids.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
>> index f3f0cb6..a43d0e8 100644
>> --- a/drivers/mtd/nand/nand_ids.c
>> +++ b/drivers/mtd/nand/nand_ids.c
>> @@ -108,6 +108,7 @@ const struct nand_flash_dev nand_flash_ids[] = {
>>         /* 8 Gigabit */
>>         {"NAND 1GiB 1,8V 8-bit",        0xA3, 0, 1024, 0, LP_OPTIONS},
>>         {"NAND 1GiB 3,3V 8-bit",        0xD3, 0, 1024, 0, LP_OPTIONS},
>> +       {"NAND 1GiB 3,3V 8-bit",        0x38, 0, 1024, 0, LP_OPTIONS},
>>         {"NAND 1GiB 1,8V 16-bit",       0xB3, 0, 1024, 0, LP_OPTIONS16},
>>         {"NAND 1GiB 3,3V 16-bit",       0xC3, 0, 1024, 0, LP_OPTIONS16},
>>
> 
> Is this an ONFI flash?  If so, use that instead of the ID table.
> 
> -Scott
> 

Hi Scott,

yes it's an ONFI flash, but the OOB size is 224 bytes, which results in
a data abort (see below).
Apparently the supported ONFI detected OOB sizes are 8,16,64 and 128 bytes.
I lack a nand_oob_224 struct but I don't know what the default positions
would be.

Would the following layout be ok?
.eccbytes = 208,
.eccpos = {2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
	18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
	34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
	50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65,
	66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81,
	82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
	98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111,
112, 113,
	114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127,
128, 129,
	130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143,
144, 145,
	146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159,
160, 161,
	162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175,
176, 177,
	178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191,
192, 193,
	194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207,
208, 209},
	.oobfree = {
		{.offset = 210,
		 .length = 14 } }

(basically skip first two bytes, 208 bytes data, 14 bytes free)

The cause for the data abort is the following access in
nand_scan_tail(struct mtd_info *mtd) as chip->layout has not been set:

/*
 * The number of bytes available for a client to place data into
 * the out of band area.
 */
chip->ecc.layout->oobavail = 0;

If the proposed layout is ok, I'll make a patch.

the data abort:

U-Boot 2014.01-rc1-00027-g78a75bc-dirty (Dec 11 2013 - 21:03:57)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  data abort

    MAYBE you should read doc/README.arm-unaligned-accesses

pc : [<8f7720f8>]	   lr : [<8f75f654>]
sp : 8f630ef0  ip : 00000820	 fp : 80849989
r10: 00000002  r9 : 8f630f28	 r8 : 4030cdcc
r7 : 4030cb7c  r6 : 00000002	 r5 : 8ffbb000  r4 : 8ffbb0b0
r3 : 00000000  r2 : 00000000	 r1 : 8f79f57c  r0 : 8f631040
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

-- Lo