All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [NEXT PATCH v1 2/7] NAND: added NAND type to nand_ids
Date: Fri, 7 Sep 2012 13:56:14 -0500	[thread overview]
Message-ID: <504A434E.9020001@freescale.com> (raw)
In-Reply-To: <504A118D.8090808@denx.de>

On 09/07/2012 10:23 AM, Stefano Babic wrote:
> On 07/09/2012 11:12, Stefano Babic wrote:
>> 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@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).
> 
> 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.

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

Does the chip support ONFI?

-Scott

  reply	other threads:[~2012-09-07 18:56 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 [this message]
2012-09-10 12:09           ` Stefano Babic
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=504A434E.9020001@freescale.com \
    --to=scottwood@freescale.com \
    --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.