[U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids

Stefano Babic sbabic at denx.de
Fri Sep 7 11:12:54 CEST 2012


On 07/09/2012 01:19, Scott Wood wrote:
> On 09/06/2012 03:04 AM, Stefano Babic wrote:
>> Signed-off-by: Stefano Babic <sbabic at denx.de>
>> ---

Hi Scott,

>>  drivers/mtd/nand/nand_ids.c |    2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
>> index 3953549..fe75686 100644
>> --- a/drivers/mtd/nand/nand_ids.c
>> +++ b/drivers/mtd/nand/nand_ids.c
>> @@ -131,6 +131,8 @@ const struct nand_flash_dev nand_flash_ids[] = {
>>  	/* 128 Gigabit */
>>  	{"NAND 16GiB 1,8V 8-bit",	0x1A, 0, 16384, 0, LP_OPTIONS},
>>  	{"NAND 16GiB 3,3V 8-bit",	0x3A, 0, 16384, 0, LP_OPTIONS},
>> +	{"NAND 16GiB 3,3V 8-bit",	0x48, 4096, 16384, 0x100000,
>> +		LP_OPTIONS},
>>  	{"NAND 16GiB 1,8V 16-bit",	0x2A, 0, 16384, 0, LP_OPTIONS16},
>>  	{"NAND 16GiB 3,3V 16-bit",	0x4A, 0, 16384, 0, LP_OPTIONS16},
>>  
>>
> 
> Why does this NAND chip need things specified that are zeroes for other
> chips?

At least on this board with MX35, the chip cannot be recognized.
Manufacturer ID and device ID are read flawlessly, but then u-boot fails
to get the correct geometry. Setting explicitely the values, I can then
read / write into the NAND without any problem. It can be more a problem
related to the specific MXC NAND driver (mxc_nand.c).

Regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================


More information about the U-Boot mailing list