From: Zhou Wang <wangzhou.bry@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk,
liguozhu@hisilicon.com, haojian.zhuang@gmail.com,
wangzhou1@hisilicon.com, robh+dt@kernel.org,
linux-mtd@lists.infradead.org, xuwei5@hisilicon.com,
galak@codeaurora.org, caizhiyong@huawei.com,
yubingxu@hisilicon.com, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
Date: Wed, 17 Dec 2014 13:06:37 +0800 [thread overview]
Message-ID: <54910F5D.4090705@gmail.com> (raw)
In-Reply-To: <20141217010358.GM9759@ld-irv-0074>
On 2014年12月17日 09:03, Brian Norris wrote:
> On Thu, Dec 11, 2014 at 08:02:27PM +0800, Zhou Wang wrote:
>> On 2014年11月30日 17:08, Brian Norris wrote:
>>> Have you tested on the MTD test modules (drivers/mtd/tests/*)? This is
>>> important, as we seem to regularly get UBIFS bug reports from users
>>> whose drivers have not even passed some of the simple tests.
>>>
>>> Also, it might be worth testing out the UBI tests found in the mtd-utils
>>> package.
>>
>> I have tested this NAND controller driver on the MTD test modules
>> (drivers/mtd/tests/*). All tests passed except mtd_nandbiterrs.ko.
>>
>> Here is the test log for mtd_nandbiterrs:
>> /home # insmod mtd_nandbiterrs.ko dev=2 page_offset=1 seed=110 mode=0
>> [ 100.484995]
>> [ 100.490082] ==================================================
>> [ 100.509657] mtd_nandbiterrs: MTD device: 2
>> [ 100.523413] mtd_nandbiterrs: MTD device size 8388608,
>> eraseblock=131072, page=2048, oob=64
>> [ 100.551134] mtd_nandbiterrs: Device uses 2 subpages of 1024 bytes
>> [ 100.571585] mtd_nandbiterrs: Using page=1, offset=2048, eraseblock=0
>> [ 104.431136] mtd_nandbiterrs: incremental biterrors test
>> [ 104.448872] mtd_nandbiterrs: write_page
>> [ 104.463193] mtd_nandbiterrs: rewrite page
>> [ 104.477620] mtd_nandbiterrs: read_page
>> [ 104.490898] mtd_nandbiterrs: verify_page
>> [ 104.504338] mtd_nandbiterrs: Successfully corrected 0 bit errors
>> per subpage
>> [ 104.527985] mtd_nandbiterrs: Inserted biterror @ 0/5
>> [ 104.544673] mtd_nandbiterrs: Inserted biterror @ 1024/2
>> [ 104.562197] mtd_nandbiterrs: rewrite page
>> [ 104.576766] mtd_nandbiterrs: read_page
>> [ 104.590052] mtd_nandbiterrs: verify_page
>> [ 104.603252] mtd_nandbiterrs: Error: page offset 0, expected 23, got 03
>> [ 104.625203] mtd_nandbiterrs: Error: page offset 1024, expected 06, got 02
>> [ 104.648056] mtd_nandbiterrs: ECC failure, read data is incorrect
>> despite read success
>> insmod: can't insert 'mtd_nandbiterrs.ko': Input/output error
>>
>> The reason for above failure is that:
>> In ECC mode, when rewriting page data to NAND flash, the NAND
>> controller will also produce ECC code and write them to NAND flash
>> as well. So when we read data from NAND flash, there is no need to
>> correct the error bit. We read what we write to the flash.
>>
>> In mtd_nandbiterrs test, We call nand_write_page_raw indeed to perform
>> rewrite operation. My question is that: in this NAND controller hardware
>> design, it is hard to implement hardware specific write_page_raw to
>> write page data without producing ECC code, will this bring some bad
>> effects somewhere? It will be very nice if you and anyone can give
>> me some advice.
>
> As of now, read_page_raw()/write_page_raw() are not required for any
> normal operation. They are useful for debugging and testing though, with
> tests like this one.
>
> In the future, we might use read_page_raw() for implementing (optional)
> software-based detection of blank/erased pages that have bitflips in
> them -- i.e., all 0xff but with a few bitflips. See:
>
> http://lists.infradead.org/pipermail/linux-mtd/2014-December/056749.html
> http://article.gmane.org/gmane.linux.drivers.mtd/52183/
>
> Brian
>
Got it, thanks for your explanation, Brian. I will resend the new
version of patchset based on v3.19-rc1 later.
Regards,
Zhou
WARNING: multiple messages have this Message-ID (diff)
From: Zhou Wang <wangzhou.bry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
caizhiyong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
yubingxu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org
Subject: Re: [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc
Date: Wed, 17 Dec 2014 13:06:37 +0800 [thread overview]
Message-ID: <54910F5D.4090705@gmail.com> (raw)
In-Reply-To: <20141217010358.GM9759@ld-irv-0074>
On 2014年12月17日 09:03, Brian Norris wrote:
> On Thu, Dec 11, 2014 at 08:02:27PM +0800, Zhou Wang wrote:
>> On 2014年11月30日 17:08, Brian Norris wrote:
>>> Have you tested on the MTD test modules (drivers/mtd/tests/*)? This is
>>> important, as we seem to regularly get UBIFS bug reports from users
>>> whose drivers have not even passed some of the simple tests.
>>>
>>> Also, it might be worth testing out the UBI tests found in the mtd-utils
>>> package.
>>
>> I have tested this NAND controller driver on the MTD test modules
>> (drivers/mtd/tests/*). All tests passed except mtd_nandbiterrs.ko.
>>
>> Here is the test log for mtd_nandbiterrs:
>> /home # insmod mtd_nandbiterrs.ko dev=2 page_offset=1 seed=110 mode=0
>> [ 100.484995]
>> [ 100.490082] ==================================================
>> [ 100.509657] mtd_nandbiterrs: MTD device: 2
>> [ 100.523413] mtd_nandbiterrs: MTD device size 8388608,
>> eraseblock=131072, page=2048, oob=64
>> [ 100.551134] mtd_nandbiterrs: Device uses 2 subpages of 1024 bytes
>> [ 100.571585] mtd_nandbiterrs: Using page=1, offset=2048, eraseblock=0
>> [ 104.431136] mtd_nandbiterrs: incremental biterrors test
>> [ 104.448872] mtd_nandbiterrs: write_page
>> [ 104.463193] mtd_nandbiterrs: rewrite page
>> [ 104.477620] mtd_nandbiterrs: read_page
>> [ 104.490898] mtd_nandbiterrs: verify_page
>> [ 104.504338] mtd_nandbiterrs: Successfully corrected 0 bit errors
>> per subpage
>> [ 104.527985] mtd_nandbiterrs: Inserted biterror @ 0/5
>> [ 104.544673] mtd_nandbiterrs: Inserted biterror @ 1024/2
>> [ 104.562197] mtd_nandbiterrs: rewrite page
>> [ 104.576766] mtd_nandbiterrs: read_page
>> [ 104.590052] mtd_nandbiterrs: verify_page
>> [ 104.603252] mtd_nandbiterrs: Error: page offset 0, expected 23, got 03
>> [ 104.625203] mtd_nandbiterrs: Error: page offset 1024, expected 06, got 02
>> [ 104.648056] mtd_nandbiterrs: ECC failure, read data is incorrect
>> despite read success
>> insmod: can't insert 'mtd_nandbiterrs.ko': Input/output error
>>
>> The reason for above failure is that:
>> In ECC mode, when rewriting page data to NAND flash, the NAND
>> controller will also produce ECC code and write them to NAND flash
>> as well. So when we read data from NAND flash, there is no need to
>> correct the error bit. We read what we write to the flash.
>>
>> In mtd_nandbiterrs test, We call nand_write_page_raw indeed to perform
>> rewrite operation. My question is that: in this NAND controller hardware
>> design, it is hard to implement hardware specific write_page_raw to
>> write page data without producing ECC code, will this bring some bad
>> effects somewhere? It will be very nice if you and anyone can give
>> me some advice.
>
> As of now, read_page_raw()/write_page_raw() are not required for any
> normal operation. They are useful for debugging and testing though, with
> tests like this one.
>
> In the future, we might use read_page_raw() for implementing (optional)
> software-based detection of blank/erased pages that have bitflips in
> them -- i.e., all 0xff but with a few bitflips. See:
>
> http://lists.infradead.org/pipermail/linux-mtd/2014-December/056749.html
> http://article.gmane.org/gmane.linux.drivers.mtd/52183/
>
> Brian
>
Got it, thanks for your explanation, Brian. I will resend the new
version of patchset based on v3.19-rc1 later.
Regards,
Zhou
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-12-17 5:06 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 12:46 [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc Zhou Wang
2014-11-04 12:46 ` Zhou Wang
2014-11-04 12:46 ` Zhou Wang
2014-11-04 12:47 ` [PATCH v4 1/2] mtd: hisilicon: add a new NAND controller driver for " Zhou Wang
2014-11-04 12:47 ` Zhou Wang
2014-11-30 9:35 ` Brian Norris
2014-11-30 9:35 ` Brian Norris
2014-11-30 9:35 ` Brian Norris
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-12-01 18:14 ` Brian Norris
2014-12-01 18:14 ` Brian Norris
2014-12-01 18:14 ` Brian Norris
2014-12-01 9:25 ` Brian Norris
2014-12-01 9:25 ` Brian Norris
2014-12-01 9:25 ` Brian Norris
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-11-04 12:47 ` [PATCH v4 2/2] mtd: hisilicon: add device tree binding documentation Zhou Wang
2014-11-04 12:47 ` Zhou Wang
2014-11-30 8:56 ` Brian Norris
2014-11-30 8:56 ` Brian Norris
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-12-01 13:08 ` Zhou Wang
2014-11-30 9:01 ` Brian Norris
2014-11-30 9:01 ` Brian Norris
2014-11-30 9:01 ` Brian Norris
2014-12-01 13:07 ` Zhou Wang
2014-12-01 13:07 ` Zhou Wang
2014-12-01 13:07 ` Zhou Wang
2014-11-06 3:05 ` [PATCH v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc Haojian Zhuang
2014-11-06 3:05 ` Haojian Zhuang
2014-11-06 3:05 ` Haojian Zhuang
2014-11-26 6:35 ` Haojian Zhuang
2014-11-26 6:35 ` Haojian Zhuang
2014-11-26 6:35 ` Haojian Zhuang
2014-11-30 9:08 ` Brian Norris
2014-11-30 9:08 ` Brian Norris
2014-12-01 13:06 ` Zhou Wang
2014-12-01 13:06 ` Zhou Wang
2014-12-01 13:06 ` Zhou Wang
2014-12-11 12:02 ` Zhou Wang
2014-12-11 12:02 ` Zhou Wang
2014-12-17 1:03 ` Brian Norris
2014-12-17 1:03 ` Brian Norris
2014-12-17 5:06 ` Zhou Wang [this message]
2014-12-17 5:06 ` Zhou Wang
2014-12-17 6:23 ` Brian Norris
2014-12-17 6:23 ` Brian Norris
2014-12-17 11:05 ` Zhou Wang
2014-12-17 11:05 ` Zhou Wang
2015-01-13 4:17 ` Brian Norris
2015-01-13 4:17 ` Brian Norris
2015-01-22 3:27 ` Zhou Wang
2015-01-22 3:27 ` Zhou Wang
2015-01-22 8:45 ` Brian Norris
2015-01-22 8:45 ` Brian Norris
2015-01-25 8:19 ` Zhou Wang
2015-01-25 8:19 ` Zhou Wang
2015-02-06 1:33 ` Brian Norris
2015-02-06 1:33 ` 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=54910F5D.4090705@gmail.com \
--to=wangzhou.bry@gmail.com \
--cc=caizhiyong@huawei.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=haojian.zhuang@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=liguozhu@hisilicon.com \
--cc=linux-mtd@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=wangzhou1@hisilicon.com \
--cc=xuwei5@hisilicon.com \
--cc=yubingxu@hisilicon.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.