All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids
Date: Mon, 10 Sep 2012 14:09:21 +0200	[thread overview]
Message-ID: <504DD871.7040301@denx.de> (raw)
In-Reply-To: <504A434E.9020001@freescale.com>

On 07/09/2012 20:56, Scott Wood wrote:

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).
>>
>> It seems to me that the values returned by this flash cannot be
>> interpreted in nand_get_flash_type().
>>
>> The values returned from a READ-ID command with address 0x00 are:
>>
>> 	0x2C 0x48 0x04 0x4A 0xA5,
>>
>> I can really get these values from the flash, so the MXC controller gets
>> the correct data.
>>
>> However, the code in nand_base.c (lines from 2718, so not-Samsung case)
>> parses the answer setting the NAND as a 16-bit device, but this is
>> really a 8bit device. I do not know the meaning of the answer, it is not
>> described in the datasheet.
> 
> Does the datasheet say anything about what the ID data is supposed to
> look like and how to interpret it?  I tried to download it and Micron
> shoved an NDA in my face.

I find no description in the datasheet.

> 
> What kind of chip is this?  Is the datasheet publicly available?
> 
> These threads seem relevant:
> http://patchwork.ozlabs.org/patch/60042/
> http://old.nabble.com/-U-Boot--Add-new-NAND-flash-td29858370.html

It is the same case,  as I can see, with the same chip.

> 
> Does the chip support ONFI?

The chip supports ONFI, but it seems the i.MX driver does not. Quite as
described in http://patchwork.ozlabs.org/patch/60042/. READ-ID is always
sent with address 0, I do not know if we can convince the driver to send
the address.

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
=====================================================================

  reply	other threads:[~2012-09-10 12:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-06  8:04 [U-Boot] [NEXT PATCH v1 0/7] In this patchset, a new i.MX35 board is added implementing Stefano Babic
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 1/7] ARM: Fix start.S when used with SPL in arm1136 Stefano Babic
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids Stefano Babic
2012-09-06 23:19   ` Scott Wood
2012-09-07  9:12     ` Stefano Babic
2012-09-07 15:23       ` Stefano Babic
2012-09-07 18:56         ` Scott Wood
2012-09-10 12:09           ` Stefano Babic [this message]
2012-09-10 23:18             ` Scott Wood
2012-10-01  7:02               ` Stefano Babic
2012-09-23 19:01             ` Eric Bénard
2012-09-24  8:29               ` Stefano Babic
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 3/7] MX35: add LOW_LEVEL_SRAM_STACK to use SPL_FRAMEWORK Stefano Babic
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 4/7] MX35: Add soc_boot_mode and soc_boot_device to MX35 Stefano Babic
2012-09-23 19:25   ` Eric Bénard
2012-09-24  8:35     ` Stefano Babic
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 5/7] SPL: Added MLO for mx35 SOC to SPL Makefile Stefano Babic
2012-09-06 17:49   ` Tom Rini
2012-09-06 19:59     ` Stefano Babic
2012-09-06 20:48       ` Tom Rini
2012-09-06 21:57         ` stefano babic
2012-09-10 12:27           ` Thomas Petazzoni
2012-09-10 12:44             ` Stefano Babic
2012-09-10 12:54               ` Tom Rini
2012-09-06  8:04 ` [U-Boot] [NEXT PATCH v1 6/7] ARM: Add MLO target to arm1136 Stefano Babic
2012-09-06  8:05 ` [U-Boot] [NEXT PATCH v1 7/7] MX35: add support for woodburn board Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=504DD871.7040301@denx.de \
    --to=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.