From: Huang Shijie <b32955@freescale.com>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: baruch@tkos.co.il, koen.beel.barco@gmail.com,
Wolfram Sang <w.sang@pengutronix.de>,
linux-mtd@lists.infradead.org, Artem.Bityutskiy@intel.com,
shijie8@gmail.com, linux-arm-kernel@lists.infradead.org,
LW@karo-electronics.de
Subject: Re: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Sat, 31 Dec 2011 11:31:33 +0800 [thread overview]
Message-ID: <4EFE8215.8030301@freescale.com> (raw)
In-Reply-To: <201112310415.02867.marek.vasut@gmail.com>
hi,
>> Hi,
>>
>>> On Fri, Dec 30, 2011 at 04:27:26PM +0800, Huang Shijie wrote:
>>>> In MX28, if we do not reset the BCH module. The BCH module may
>>>> becomes unstable when the board reboots for several thousands times.
>>> Do you have more details when and why this happens? What happens on MX23
>>> then?
>> In one customer's 3G router which uses the MX28:
>> [0] NAND boot mode, mount the UBIFS in the NAND partition.
>> [1] We used the gpmi_reset_block(r->bch_regs, true) to init the BCH module.
>> [2] The board will automatically reboot again after it booted by NAND
>> boot mode.
>> [3] After reboot more then thousands times(cost nearly one day), the BCH
>> mode became UNSTABLE,
>> the data read out was not right, so the system could not mount the UBIFS.
>>
>> After we use gpmi_reset_block(r->bch_regs, false) to init the BCH
>> module, the bug never happens.
>>
>>
>>
>> The gpmi_reset_block() was coded to avoid the NAND boot bug in MX23. So
>> MX23 does not have the bug.
>>
>>>> Signed-off-by: Huang Shijie<b32955@freescale.com>
>>> Is this Bug 2847 from the errata? Should be mentioned in the commit
>>> message and
>> Yes, this is the bug 2847 from the mx23's errata.
>>
>> I will add some comments to it.
>>
>> Best Regards
>> Huang Shijie
>>
>>> comments of the patch if so.
>>>
>>> Regards,
>>>
>>> Wolfram
> Ah, so you confirmed it's a problem with the silicon. Good
>
yes, the bug in mx23 is really a hardware bug.
BR
Huang Shijie
WARNING: multiple messages have this Message-ID (diff)
From: b32955@freescale.com (Huang Shijie)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Sat, 31 Dec 2011 11:31:33 +0800 [thread overview]
Message-ID: <4EFE8215.8030301@freescale.com> (raw)
In-Reply-To: <201112310415.02867.marek.vasut@gmail.com>
hi,
>> Hi,
>>
>>> On Fri, Dec 30, 2011 at 04:27:26PM +0800, Huang Shijie wrote:
>>>> In MX28, if we do not reset the BCH module. The BCH module may
>>>> becomes unstable when the board reboots for several thousands times.
>>> Do you have more details when and why this happens? What happens on MX23
>>> then?
>> In one customer's 3G router which uses the MX28:
>> [0] NAND boot mode, mount the UBIFS in the NAND partition.
>> [1] We used the gpmi_reset_block(r->bch_regs, true) to init the BCH module.
>> [2] The board will automatically reboot again after it booted by NAND
>> boot mode.
>> [3] After reboot more then thousands times(cost nearly one day), the BCH
>> mode became UNSTABLE,
>> the data read out was not right, so the system could not mount the UBIFS.
>>
>> After we use gpmi_reset_block(r->bch_regs, false) to init the BCH
>> module, the bug never happens.
>>
>>
>>
>> The gpmi_reset_block() was coded to avoid the NAND boot bug in MX23. So
>> MX23 does not have the bug.
>>
>>>> Signed-off-by: Huang Shijie<b32955@freescale.com>
>>> Is this Bug 2847 from the errata? Should be mentioned in the commit
>>> message and
>> Yes, this is the bug 2847 from the mx23's errata.
>>
>> I will add some comments to it.
>>
>> Best Regards
>> Huang Shijie
>>
>>> comments of the patch if so.
>>>
>>> Regards,
>>>
>>> Wolfram
> Ah, so you confirmed it's a problem with the silicon. Good
>
yes, the bug in mx23 is really a hardware bug.
BR
Huang Shijie
next prev parent reply other threads:[~2011-12-31 3:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-30 8:27 [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23 Huang Shijie
2011-12-30 8:27 ` Huang Shijie
2011-12-30 14:01 ` Marek Vasut
2011-12-30 14:01 ` Marek Vasut
2011-12-30 14:36 ` Wolfram Sang
2011-12-30 14:36 ` Wolfram Sang
2011-12-31 2:23 ` Huang Shijie
2011-12-31 2:23 ` Huang Shijie
2011-12-31 3:15 ` Marek Vasut
2011-12-31 3:15 ` Marek Vasut
2011-12-31 3:31 ` Huang Shijie [this message]
2011-12-31 3:31 ` Huang Shijie
2011-12-31 4:45 ` Marek Vasut
2011-12-31 4:45 ` Marek Vasut
2011-12-31 15:43 ` Wolfram Sang
2011-12-31 15:43 ` Wolfram Sang
2012-01-01 15:23 ` Huang Shijie
2012-01-01 15:23 ` Huang Shijie
2012-01-01 22:33 ` Wolfram Sang
2012-01-01 22:33 ` Wolfram Sang
2012-01-03 2:30 ` Huang Shijie
2012-01-03 2:30 ` Huang Shijie
2012-01-03 11:11 ` Wolfram Sang
2012-01-03 11:11 ` Wolfram Sang
2012-01-04 2:43 ` Huang Shijie
2012-01-04 2:43 ` Huang Shijie
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=4EFE8215.8030301@freescale.com \
--to=b32955@freescale.com \
--cc=Artem.Bityutskiy@intel.com \
--cc=LW@karo-electronics.de \
--cc=baruch@tkos.co.il \
--cc=koen.beel.barco@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=shijie8@gmail.com \
--cc=w.sang@pengutronix.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.