From: Florian Fainelli <ffainelli@freebox.fr>
To: Huang Shijie <b32955@freescale.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Matthieu Castet <matthieu.castet@parrot.com>
Subject: Re: [PATCH] mtd: fix the wrong check condition
Date: Thu, 16 Feb 2012 12:04:52 +0100 [thread overview]
Message-ID: <4F3CE2D4.4070506@freebox.fr> (raw)
In-Reply-To: <4F3C7433.5030306@freescale.com>
Hi,
On 02/16/12 04:12, Huang Shijie wrote:
> Hi,
>> (Add Florian and Matthieu)
>>
>> On 2/15/2012 2:33 AM, Huang Shijie wrote:
>>> If we use `||` check condition, many NAND chips which are not
>>> ONFI nands have to do the ONFI detection.
>>
>> Running the ONFI detection on non-ONFI NAND should not, ideally, be a
>> problem. They should fail one or both tests included in the routine:
>> the 'O N F I' string check or the CRC calculation.
> NO.
Can you please post the dump of the ONFI page as read by your
controller? Is the CRC check passing? The ONFI crc function is made so
that a page full of zeroes or 0xff won't generate a respectively 0 or ff
checksum, so we should catch this during the CRC check.
>
> I have Hynix nand in my hand: H27UBG8T2A (page size :8192, oob:448).
> It is not an ONFI nand. See the datasheet in the attachment.
> But it accidentally can pass the ONFI detection, and get the result :
> page size 4192, oob:96. This is a wrong result.
I have already seen a Hynix chip answering to the READID command too,
and this was highly confusing our bootloader, however, I suppose that we
should be able to circumvent this issue anyway.
>
>
>
>
>>
>>> Use `&&` here to detect the ONFI NAND when we can not find any type
>>> in the nand_flash_ids.
>>
>> There are many chips whose ID might be in the NAND table but for which
>> it is preferable (or even required) to check by ONFI for one reason or
>> another. For instance, some ONFI chips might use odd-sized OOB that
>> isn't in the ID decoding algorithm.
>>
> This nand is 32Gb, but we can not parse it out from the id.
> I ever want to add a new database which use the all the 8/6 bytes id as
> key.
> It seems it's time to change it now.
You have said that already, but we have yet to see patches for this, I
guess if you can post your database patch that will be easier to comment on.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: ffainelli@freebox.fr (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mtd: fix the wrong check condition
Date: Thu, 16 Feb 2012 12:04:52 +0100 [thread overview]
Message-ID: <4F3CE2D4.4070506@freebox.fr> (raw)
In-Reply-To: <4F3C7433.5030306@freescale.com>
Hi,
On 02/16/12 04:12, Huang Shijie wrote:
> Hi,
>> (Add Florian and Matthieu)
>>
>> On 2/15/2012 2:33 AM, Huang Shijie wrote:
>>> If we use `||` check condition, many NAND chips which are not
>>> ONFI nands have to do the ONFI detection.
>>
>> Running the ONFI detection on non-ONFI NAND should not, ideally, be a
>> problem. They should fail one or both tests included in the routine:
>> the 'O N F I' string check or the CRC calculation.
> NO.
Can you please post the dump of the ONFI page as read by your
controller? Is the CRC check passing? The ONFI crc function is made so
that a page full of zeroes or 0xff won't generate a respectively 0 or ff
checksum, so we should catch this during the CRC check.
>
> I have Hynix nand in my hand: H27UBG8T2A (page size :8192, oob:448).
> It is not an ONFI nand. See the datasheet in the attachment.
> But it accidentally can pass the ONFI detection, and get the result :
> page size 4192, oob:96. This is a wrong result.
I have already seen a Hynix chip answering to the READID command too,
and this was highly confusing our bootloader, however, I suppose that we
should be able to circumvent this issue anyway.
>
>
>
>
>>
>>> Use `&&` here to detect the ONFI NAND when we can not find any type
>>> in the nand_flash_ids.
>>
>> There are many chips whose ID might be in the NAND table but for which
>> it is preferable (or even required) to check by ONFI for one reason or
>> another. For instance, some ONFI chips might use odd-sized OOB that
>> isn't in the ID decoding algorithm.
>>
> This nand is 32Gb, but we can not parse it out from the id.
> I ever want to add a new database which use the all the 8/6 bytes id as
> key.
> It seems it's time to change it now.
You have said that already, but we have yet to see patches for this, I
guess if you can post your database patch that will be easier to comment on.
--
Florian
next prev parent reply other threads:[~2012-02-16 11:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-15 10:33 [PATCH] mtd: fix the wrong check condition Huang Shijie
2012-02-15 10:33 ` Huang Shijie
2012-02-16 2:59 ` Brian Norris
2012-02-16 2:59 ` Brian Norris
2012-02-16 3:12 ` Huang Shijie
2012-02-16 11:04 ` Florian Fainelli [this message]
2012-02-16 11:04 ` Florian Fainelli
2012-02-17 3:07 ` Huang Shijie
2012-02-17 3:07 ` Huang Shijie
2012-02-17 8:50 ` Florian Fainelli
2012-02-17 8:50 ` Florian Fainelli
2012-02-18 5:43 ` Brian Norris
2012-02-18 5:43 ` Brian Norris
2012-02-16 3:15 ` Huang Shijie
2012-02-16 3:15 ` Huang Shijie
2012-02-16 8:32 ` Brian Norris
2012-02-16 8:32 ` Brian Norris
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=4F3CE2D4.4070506@freebox.fr \
--to=ffainelli@freebox.fr \
--cc=b32955@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=matthieu.castet@parrot.com \
/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.