[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