From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/4] mtd/nand: Fixup for support ONFI detect
Date: Mon, 5 Dec 2011 13:20:35 -0600 [thread overview]
Message-ID: <4EDD1983.9070205@freescale.com> (raw)
In-Reply-To: <3F453DDFF675A64A89321A1F352810216B0393@039-SN1MPN1-005.039d.mgd.msft.net>
On 12/03/2011 03:11 AM, Liu Shengzhou-B36685 wrote:
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: 2011?12?3? 2:32
>> To: Liu Shengzhou-B36685
>> Cc: u-boot at lists.denx.de; Gala Kumar-B11780
>> Subject: Re: [PATCH 2/4] mtd/nand: Fixup for support ONFI detect
>>
>> On 12/02/2011 03:17 AM, Shengzhou Liu wrote:
>>> There was a bug logically in the order of nand_flash_detect_onfi
>>> and checking nand_flash_ids. We should get NAND devices related
>>> informations first by ONFI method instead of querying nand_flash_ids
>> table,
>>> if ONFI fails, then query nand_flash_ids table.
>>
>> ONFI issues should be taken care of with the patchset to sync NAND with
>> Linux that was recently posted. It has some minor issues, which
>> hopefully will be addressed by the next merge window.
>>
>> I disagree that we should check ONFI first -- this is not what Linux
>> does. U-Boot's problem is that it aborts before ever checking ONFI, if
>> the device is not found in the table (and the Linux code suggests that
>> ONFI devices won't be found in the table).
>>
>> -Scott
>
> Currently in Linux, ONFI is detected first, if ONFI fails, then detect nand_flash_ids table.
How do you get that impression from this code:?
for (; type->name != NULL; type++)
if (*dev_id == type->id)
break;
chip->onfi_version = 0;
if (!type->name || !type->pagesize) {
/* Check is chip is ONFI compliant */
ret = nand_flash_detect_onfi(mtd, chip, &busw);
if (ret)
goto ident_done;
}
nand_flash_detect_onfi() is called only if there is no match found in
the ID table.
> But in u-boot, it first detects nand_flash_ids table, if not found in the table, it aborts, so ONFI never works.
Right, the problem is that it aborts, not that it checks the table first.
> I think we should still check ONFI first to accord to what Linux
> does, because there many new NAND chips which not listed in the
> nand_flash_ids table before known, if check ONFI first, it can
> automatically find related info without manual intervention.
The assumption in the Linux code appears to be that ONFI chips will
never be in the ID table (or possibly that if they are, we don't need
the ONFI data).
-Scott
next prev parent reply other threads:[~2011-12-05 19:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 9:17 [U-Boot] [PATCH 1/4] mtd/nand : Add function board_nand_init_tail() for some special NAND controllers Shengzhou Liu
2011-12-02 9:17 ` [U-Boot] [PATCH 2/4] mtd/nand: Fixup for support ONFI detect Shengzhou Liu
2011-12-02 9:17 ` [U-Boot] [PATCH 3/4] mtd/nand: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection Shengzhou Liu
2011-12-02 9:17 ` [U-Boot] [PATCH 4/4] mtd/nand: Add ONFI support for FSL NAND controller Shengzhou Liu
2011-12-02 18:45 ` Scott Wood
[not found] ` <3F453DDFF675A64A89321A1F352810216B03B9@039-SN1MPN1-005.039d.mgd.msft.net>
2011-12-05 19:17 ` Scott Wood
2011-12-02 18:32 ` [U-Boot] [PATCH 2/4] mtd/nand: Fixup for support ONFI detect Scott Wood
[not found] ` <3F453DDFF675A64A89321A1F352810216B0393@039-SN1MPN1-005.039d.mgd.msft.net>
2011-12-05 19:20 ` Scott Wood [this message]
2011-12-04 9:04 ` [U-Boot] [PATCH 1/4] mtd/nand : Add function board_nand_init_tail() for some special NAND controllers Igor Grinberg
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=4EDD1983.9070205@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox