[PATCH|RFC] beagle: make nand ecc command based
menon.nishanth at gmail.com
Wed Aug 18 06:03:15 EDT 2010
On 08/18/2010 01:42 AM, Sascha Hauer wrote:
> On Tue, Aug 17, 2010 at 05:40:09AM -0500, Nishanth Menon wrote:
>> On 08/17/2010 03:55 AM, Michael Grzeschik wrote:
>>> Signed-off-by: Michael Grzeschik<m.grzeschik at pengutronix.de>
>>> This will only work once and bring the nand chip into a undefined state
>>> after a second call. Any ideas for doing this save?
>> looking at the gpmc logic, it does a reset in gpmc_cs_config by
>> disabling and re-enabling it -> so my guess is:
>> a) in the selection of ecc logic
>> b) reset of statemachines in mtd layers
>> c) nand chip not being reset from it's previous state (resetting the
>> controller does not mean nand chip is reset) (if i recollect sometime
>> back mtd used to do a 0xff and reset)..
>> personally, IMHO using s/w ecc has not much benefit other than being
>> "legacy enabled"
> It really seems odd to me that the omap internal ROM code expects hw
> ecc while xloader and kernel expect hw ecc. This way we always need
> two different ecc algorithms in place which is really inconvenient and
> hard for users to get it right.
I agree, but there has been a lot of history behind how this came to
happen. there is still discussion in linux-omap in getting kernel's mtd
driver to sanely handle the ecc strategy selectable by the board.
More information about the barebox