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